включить опцию 125 что это

Настройка модема HUAWEI HG8245A (H)

В одно прекрасное время в линейке модемов появилась недорогая качественная современная модель, благодаря наличию двух антенн обеспечивающая качество сигнала по всему жилищу (и как показывает практика) и за его пределами. Рассмотрим, как настроить модем HUAWEI HG8245A или HG8245H.

Подключение

Прежде всего модем нужно подключить к ПК. Это делается с помощью провода, идущего в комплекте с устройством. Один из концов подключается в порт LAN (это порт, через который идёт соединение с локальной сетью). Вторым подключаемся к компьютеру (ноутбуку).

После подключения в адресной строке запущенного браузера (любого, который есть в наличии) нужно ввести 192.168.100.1 (это IP-адрес данных модемов по умолчанию). Рекомендуются браузеры — Internet Explorer, Yandex, Firefox.

В ответ появится окно с запросом логина и пароля:

Возможные варианты для логина/пароля:

С логином «telecomadmin» возможны значения для пароля:

Или комбинация логин/пароль —root/admin (для изменения настроек только сети Wi-Fi).

Если такое окно не появляется проверяем другие данные в настройках сетевой карты:

После сверки и набора логина с паролем попадаем в меню отладки функций оптического терминала, начинаем настраивать.

Настройка

Включает в себя перемещение и установку данных по нескольким складкам (страничкам):

Вкладка WAN

Настройка модема HUAWEI HG8245A начинается с перемещения на страницу «WAN».

На ней должно быть отмечено:

Страница LAN

Настройка Wi-Fi

Настройка Wi-Fi для нашего Байфлаймодема производится из вкладки WLAN. В ней:

Устанавливаем галочку в верхней части возле «Enable WLAN»;

Дальше правее от неё нажимается «NEW»;

Поле «SSID Name» должно содержать название сети Wi-Fi;

Рядом с «Enable SSID», «Broadcast SSID» и «Enable WMM» ставятся галочки;

Значение «Number of Associated…» говорит околичестве одновременно подключенных девайсов;

Оставшиеся поля должны соответствовать картинке;

Нажатие кнопки «Apply» сохранит введённые настройки:

Ознакомившись с нашей статьёй, вы уже поняли, что настройка модема Byfly Huawei HG8245H не представляет особой сложности.

Настраивайте, оставляйте комментарии о своих успехах, делитесь ими с друзьями.

Источник

[Конспект админа] Как подружиться с DHCP и не бояться APIPA

Сервис, выдающий IP-адреса устройствам в локальной сети, кажется одним из самых простых и всем знакомых. Тем не менее у моих младших коллег до сих пор временами всплывают вопросы вроде «компьютер что-то получает какой-то странный адрес», а появление второго DHCP-сервера в одном сетевом сегменте вызывает некоторый трепет или проблемы в работе сети.

Чтобы у прочитавших этот материал такие вопросы не возникали, мне хотелось бы собрать в кучу основную информацию про работу механизмов выдачи адресов IP, особенности и примеры настройки отказоустойчивых и защищенных конфигураций. Да и возможно матерым специалистам будет интересно освежить нейронные связи.

Немного теории и решения интересных и не очень практических задач — под катом.

В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).

Zeroconf или зачем нам вообще какой-то DHCP

В принципе, специально для функционирования небольших сетей был создан стек технологий под названием Zeroconf. Он позволяет обойтись без каких-либо централизованных сервисов и серверов, включая, но не ограничиваясь выдачей IP-адресов. Им закрываются (ну, или почти закрываются) следующие вопросы:

Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.

Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP, который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.

При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и поставить ему значение 0.

Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.

DHCP и его прародители

Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.

Схема работы RARP протокола.

И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

Важным отличием от устаревших протоколов является возможность временной выдачи адреса (lease) и передачи большого количества разной информации клиенту. Достигается это за счет менее тривиальной процедуры получения адреса. Если в старых протоколах схема была простая, вида запрос-ответ, то теперь схема следующая:

Схема общения клиента с сервером пересылки и сервером.

Подробнее про схему взаимодействия сервера и клиента и про структуру запросов и ответов можно почитать, например, в материале «Структура, формат и назначение DHCP пакетов».

На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».

С разными реализациями DHCP-сервера сталкивались многие, даже при настройке домашней сети. Действительно, сейчас сервер есть:

Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC, я же разберу несколько интересных примеров.

Удивительные опции DHCP

В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *—dhcp-option-force. MikroTik и Windows такого не умеют.

Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi». Настройка MikroTik под спойлером.

Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.

Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation. Пример настройки DHCP:

Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.

Предположим, нам нужно добавить клиентам маршрут вида dst-address=10.0.0.0/24 gateway=192.168.88.2, а основным шлюзом будет 192.168.88.1. Приведем это все в HEX:

Соберем все это счастье в одну строку и получим настройку:

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Добавим сети надежности и безопасности

Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.

Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.

В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:

Настройка в других коммутаторах происходит аналогичным образом.

Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.

Помимо защиты от злых хакеров эта функция избавит от головной боли, когда в сети появляется другой DHCP-сервер — например, когда SOHO-роутер, используемый как свич с точкой доступа, сбрасывает свои настройки. К сожалению, в сетях, где встречается SOHO-оборудование, не всегда бывает грамотная структура кабельной сети с управляемыми маршрутизаторами. Но это уже другой вопрос.

Красивая коммутационная — залог здоровья.

К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPS\IDS.

Если говорить не только о защите сети, но и о надежности, то не лишним будет упомянуть и про возможности отказоустойчивого DHCP. Действительно, при своей простоте DHCP часто бывает одним из ключевых сервисов, и при выходе его из строя работа организации может быть парализована. Но если просто установить два сервера с идентичными настройками, то ни к чему, кроме конфликта IP-адресов, это не приведет.

Казалось бы, можно поделить область выдачи между двумя серверами, и пусть один выдает одну половину адресов, а второй — другую. Вот только парализованная половина инфраструктуры немногим лучше, чем целая.

Разберем более практичные варианты.

В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7. »

Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.

Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.

Расскажите, а вам приходилось сталкиваться с проказами DHCP?

Источник

Configure Option 125 on a Server to Allow Dynamic Host Configuration Protocol (DHCP) Auto Image Updates on a Switch

Available Languages

Download Options

Objective

Scenario:

Managing multiple or stacked switches in the network could be very challenging to maintain, especially if you have to add a new switch to the network, apply new configuration settings, or update each switch to its latest image version. You would want to find a way to allow the switches to automatically update their own images.

If you have enabled and configured the Dynamic Host Configuration Protocol (DHCP) Auto Configuration and Auto Image Update features to automatically update the firmware and configurations on a switch that is connected to a server which serves as a DHCP server. However, after configuring DHCP-based auto update, the switch did not download and apply the latest image.

Solution:

Enabling the DHCP image upgrade features to download both a new image and a new configuration file to one or more switches in the network is very helpful in making sure that each new switch added to the network receives the same image and configuration. These features function properly only when the DHCP server is configured to assign the host IP address dynamically. By default, the switch is enabled as a DHCP client when the Auto Configuration feature is enabled. If Image Auto Update is enabled, the flash image is downloaded and updated. If the new configuration is downloaded to a switch that already has a configuration, the downloaded configuration is appended to the configuration file stored on the switch.

Auto image download is done using an indirect image file. The indirect Image file is a text file that contains the path to the actual image file which is uploaded on a TFTP or SCP server. To provide the indirect image file name, Option 125 needs to be configured with the following parameters on the DHCP server:

This article provides instructions on how to configure Option 125 on the server to relay DHCP addresses correctly and make auto image update work on the switch.

Note: Before you proceed, you can verify if you have correctly configured the DHCP Image Upgrade Settings on your switch. For step-by-step instructions, click here.

Applicable Devices

Configure Option 125

Add Option 125 in your Server

Important: Make sure that there is an active DHCP server running in your Linux or Windows server.

Note: In this scenario, Windows Server 2012 R2 is used.

Step 1. Click Start > Server Manager.

Step 2. Right-click on the server name then click DHCP Manager.

Note: In this example, CISCOSBSERVER is the server name.

Step 3. Click the collapse button of the server name, and then click the collapse button of IPv4 to show available options.

Note: Option 125 works on IPv4 addressing only. If you want to configure DHCP Auto Image Upgrade settings on IPv6 address scope, configure Option 60 instead.

Step 4. Right-click on IPv4, and then click Set Predefined Options.

Step 5. Click DHCP Standard Options in the Option class drop-down list.

Step 6. Scroll down the Option name drop-down list to search for the option that starts with 125.

Note: By default, Option 125 is not available. If you have pre-configured Option 125, you can skip to Configure Option 125 Settings Through Netsh.

Step 7. If verified that Option 125 is not on the list, click Add.

Step 8. Enter the option name in the Name field.

Note: In this example, AutoUpdate 125 is used.

Step 9. Click Encapsulated from the Data type drop-down list.

Step 10. Enter 125 in the Code field. This code refers to the Option number indicator found at the beginning of the Option name as shown in Step 6.

Note: This code is used to create the Option 125.

Step 11. Enter the option description in the Description field and then, click OK.

Note: Cisco SMB Switch Option 125 is used as an example.

Step 12. Click OK in the Predefined Options and Values window.

Step 13. (Optional) To verify the newly added option, choose Scope Options > Configure Options under the IP version that you have configured.

The Option 125 should now show in the list of Scope Options.

Configure Option 125 Settings Through Netsh

The proposed configuration method here uses netsh for configuring Option 125. This will allow you to run several netsh DHCP commands in the command prompt to modify the network configuration settings.

Step 1. Click Start then enter cmd in the Search box.

Step 2. Once the Command Prompt logo appears, click to launch.

Step 3. Change your current directory to Drive C:\ by entering the following:

Note: In this example, C:\Users\Administrator is the current directory. This may vary depending on the user name and directory on your computer.

Step 4. Access the netsh command-line utility by entering the following:

Step 5. Change to the DHCP context by entering the following:

Step 6. Shift from DHCP context to the server by entering the following:

Step 7. Enter the command scope and IP address to shift from the server context to the specified DHCP scope address and then press the Enter key. The prompt should display that current scope context has been changed.

Note: In this example, the scope used is 192.168.1.0.

Step 8. Enter the command set optionvalue 125 ENCAPSULATED and the Option 125 code. After pressing Enter on your keyboard, the prompt below should display that the command has been successfully completed.

Note: In this example, 000000090805066161e2747874 is the code number used.

Option 125 Code Interpretation:

You should now have configured the Option 125 settings through netsh.

Verify Option 125 in DHCP Server

Step 1. Click Start > Server Manager.

Step 2. Right-click on the server name then click DHCP Manager.

Note: In this example, CISCOSBSERVER is the server name.

Step 3. Click the collapse button of the server name to show available IP versions.

Step 4. Click the collapse button of the IP version, then click Scope Options.

Note: In this example, IPv4 is chosen.

Step 5. Right-click on the configured Option 125, then click Properties.

The configured Option 125 Scope Options page should display the Data, Binary, and ASCII codes in the Data entry area.

The Option 125 has now been successfully configured on your Windows Server.

Источник