ЙЪ-ЪБ ИТПОЙЮЕУЛПК НПЪЗПЧПК ОЕДПУФБФПЮОПУФЙ ЬФПЗП РТПЧБКДЕТБ, С УФБМ ЙУЛБФШ УЕВЕ ОПЧЩК ЛБОБМ Ч йОФЕТОЕФ. йН УФБМ ччж гфл . лБЪБМПУШ ВЩ, ОЙЛБЛЙИ УМПЦОПУФЕК У РПДЛМАЮЕОЙЕН РП ADSL ОЕ ЧПЪОЙЛМП, ОП... оП гфл ЙУРПМШЪХЕФ (ЛБЛ Й ПЮЕОШ НОПЗЙЕ РТПЧБКДЕТЩ) БЧФПТЙЪБГЙА РП РТПФПЛПМХ PPPoE, ЧЩДБЧБС ДЙОБНЙЮЕУЛЙК IP-БДТЕУ, ЛПФПТЩК НЕОСЕФУС ЛБЦДЩК УЕБОУ УЧСЪЙ. рПЛБ НБЫЙОБ ТБВПФБЕФ Ч ЛБЮЕУФЧЕ ЛМЙЕОФБ, ЬФП ОЕ ЧЩЪЩЧБЕФ ПУПВЩИ РТПВМЕН, ОП ЛПЗДБ НОЕ РПОБДПВЙМПУШ ЪБРХУФЙФШ ОБ УЧПЕН ЛПНРШАФЕТЕ УЕТЧЕТ, ЧУФБМБ РТПВМЕНБ: Б ЛБЛ ПВТБЭБФШУС ЙЪ ЧОЕЫОЕК УЕФЙ Л НБЫЙОЕ, БДТЕУ ЛПФПТПК РПУФПСООП НЕОСЕФУС?
рПОСФОП, ЮФП ОЕПВИПДЙНП ЛБЛ-ФП ХУФБОПЧЙФШ УППФЧЕФУФЧЙЕ НЕЦДХ ОЕЛЙН ДПНЕООЩН ЙНЕОЕН Й IP-БДТЕУПН, РТЙЮЕН УППФЧЕФУФЧЙЕ ЬФП ОБДП ДЙОБНЙЮЕУЛЙ НЕОСФШ, ЮФПВЩ ПОП ТЕБМШОП ТБВПФБМП. рПЙУЛБЧ Ч уЕФЙ, С ДПУФБФПЮОП ВЩУФТП ОБЫЕМ ОЕУЛПМШЛП УЕТЧЙУПЧ ДЙОБНЙЮЕУЛПЗП DNS (DDNS, Dynamic DNS).
лБЛ ЬФП ТБВПФБЕФ?
дЙОБНЙЮЕУЛЙК DNS ЬФП ФЕИОПМПЗЙС, РПЪЧПМСАЭБС ЙОЖПТНБГЙЙ ОБ DNS-УЕТЧЕТЕ ПВОПЧМСФШУС Ч ТЕБМШОПН ЧТЕНЕОЙ Й (РП ЦЕМБОЙА) Ч БЧФПНБФЙЮЕУЛПН ТЕЦЙНЕ. пОБ РТЙНЕОСЕФУС ДМС ОБЪОБЮЕОЙС РПУФПСООПЗП ДПНЕООПЗП ЙНЕОЙ ЛПНРШАФЕТХ У ЙЪНЕОСЕНЩН IP-БДТЕУПН. ьФП НПЦЕФ ВЩФШ IP-БДТЕУ, РПМХЮЕООЩК РП DHCP ЙМЙ РП IPCP Ч УПЕДЙОЕОЙСИ PPP, PPPoE Й ЙН РПДПВОЩИ (ОБРТЙНЕТ, РТЙ ХДБМЈООПН ДПУФХРЕ ЮЕТЕЪ НПДЕН). дТХЗЙЕ НБЫЙОЩ Ч йОФЕТОЕФЕ НПЗХФ ХУФБОБЧМЙЧБФШ УПЕДЙОЕОЙЕ У ЬФПК НБЫЙОПК РП ДПНЕООПНХ ЙНЕОЙ Й ДБЦЕ ОЕ ЪОБФШ, ЮФП IP-БДТЕУ ЙЪНЕОЙМУС.
чТЕНС ХУФБТЕЧБОЙС БДТЕУБ (TTL) ДМС ДЙОБНЙЮЕУЛПК ЪБРЙУЙ ДЕМБЕФУС ПЮЕОШ НБМЕОШЛЙН (ОЕ ВПМЕЕ ДЧХИ-ФТЈИ НЙОХФ), ЙОБЮЕ ДТХЗЙЕ DNS-УЕТЧЕТЩ РПНЕУФСФ ЕЈ Ч УЧПК ЛЬЫ, Б ЛПЗДБ ПОБ ЙЪНЕОЙФУС, ЙИ ЛМЙЕОФЩ ДПМЗП ВХДХФ РПМХЮБФШ ХУФБТЕЧЫХА ЙОЖПТНБГЙА.
фБЛЙН ПВТБЪПН, УИЕНБФЙЮОП, РТПГЕУУ ЧЩЗМСДЙФ ФБЛ:
- тЕЗЙУФТЙТХЕНУС Х РТПЧБКДЕТБ ДЙОБНЙЮЕУЛПЗП DNS, ЧЩВЙТБЕН ЙНС ДМС УЧПЕК УЙУФЕНЩ Й ЪБРЙУЩЧБЕН ЕЗП Ч ЖПТНХ ОБ УБКФЕ.
- лПОЖЙЗХТЙТХЕН УЧПК ЛПНРШАФЕТ ФБЛ, ЮФПВЩ ПО ПВОПЧМСМ ДБООЩЕ ОБ УЕТЧЕТЕ РТПЧБКДЕТБ ДЙОБНЙЮЕУЛПЗП DNS.
- фЕРЕТШ ЙЪЧОЕ Л ОБЫЕК НБЫЙОЕ НПЦОП ПВТБЭБФШУС РП ЪБДБООПНХ ДПНЕООПНХ ЙНЕОЙ, РТЙЮЕН ОЕЧБЦОП, ЛБЛПК ТЕБМШОЩК IP-БДТЕУ ЙУРПМШЪХЕФУС УЕКЮБУ.
юФП ОХЦОП УДЕМБФШ?
дМС ОБЮБМБ ОБДП ПРТЕДЕМЙФШУС, ЛБЛ НЩ ВХДЕН ЙОЖПТНЙТПЧБФШ УЕТЧЕТ ПВ ЙЪНЕОЕОЙЙ IP. еУМЙ Х чБУ ADSL, Й ЧЩ ОЕ РПУЛХРЙМЙУШ ЛХРЙФШ НПДЕН, УРПУПВОЩК ТБВПФБФШ Ч ЛБЮЕУФЧЕ ТПХФЕТБ, ФП РПЮФЙ ОБЧЕТОСЛБ ПО УБН ХНЕЕФ ПВОПЧМСФШ УППФЧЕФУФЧХАЭЙЕ ДБООЩЕ ВЕЪ ЧУСЛПЗП ЧНЕЫБФЕМШУФЧБ УП УФПТПОЩ ЛПНРШАФЕТБ. рПДТПВОП ОБ РТЙНЕТБИ ЬФП РПЛБЪБОП ЪДЕУШ .
еУМЙ ЦЕ чЩ РПДЛМАЮЕОЩ Л уЕФЙ ЙОЩН УРПУПВПН, РТЙДЕФУС ХУФБОПЧЙФШ ОБ УЧПЕН ЛПНРШАФЕТЕ РТПЗТБННХ-ЛМЙЕОФ ДМС ПВОПЧМЕОЙС ДБООЩИ Й ОБУФТПЙФШ ЕЕ. рТПЗТБННЩ ФБЛЙЕ НПЦОП УЛБЮБФШ У УБКФПЧ УППФЧЕФУФЧХАЭЙИ РТПЧБКДЕТПЧ ДЙОБНЙЮЕУЛПЗП DNS, ФБН ПВЩЮОП ВЩЧБАФ ЧЕТУЙЙ ДМС ТБЪОЩИ пу, ФБЛ ЮФП ЪБДЕКУФЧПЧБФШ ФБЛХА УИЕНХ РПД Linux ЙМЙ FreeBSD ПВЩЮОП ФТХДБ ОЕ УПУФБЧМСЕФ.
рТПЧБКДЕТЩ ДЙОБНЙЮЕУЛПЗП DNS
фБЛЙИ РТПЧБКДЕТПЧ УХЭЕУФЧХЕФ ОЕНБМП. оБЙВПМЕЕ ЙЪЧЕУФОЩ ЙЪ ОЙИ:
лБЦДЩК РТПЧБКДЕТ РТЕДПУФБЧМСЕФ УЧПЙ ХУМХЗЙ РМБФОП. оП ЮБУФШ ХУМХЗ ВЕУРМБФОБ. ьФП ПВЩЮОП ПЮЕОШ НБМЕОШЛБС ЮБУФШ, ЧПЪНПЦОПУФЙ ДЙОБНЙЮЕУЛПЗП DNS НОПЗП ЫЙТЕ, ОП ОБН ЕЕ ИЧБФЙФ. уПЧЕФХА ЧОЙНБФЕМШОП ПЪОБЛПНЙФШУС У УППФЧЕФУФЧХАЭЙНЙ УБКФБНЙ, ОБВПТ ВЕУРМБФОЩИ ХУМХЗ Х ЧУЕИ УЧПК, ЧПЪНПЦОП, чБУ ЪБЙОФЕТЕУХАФ ЛБЛЙЕ-ФП ДПРПМОЙФЕМШОЩЕ ЧПЪНПЦОПУФЙ.
рТЙНЕТ ТЕЗЙУФТБГЙЙ
йФБЛ, ТБУУНПФТЙН ТЕЗЙУФТБГЙА ДПНЕООПЗП ЙНЕОЙ (ДМС РТЙНЕТБ, ОБ УЕТЧЙУЕ DynDNS).
ыБЗ 1. уПЪДБОЙЕ БЛЛБХОФБ.
зПФПЧП! фЕРЕТШ ЧЩВТБООПЕ чБНЙ ДПНЕООПЕ ЙНС ВХДЕФ ЧУЕЗДБ ПДОПЪОБЮОП ЧЕУФЙ ОБ чБЫ IP-БДТЕУ, ВЕЪПФОПУЙФЕМШОП ФПЗП, ЛБЛПК ЬФП БДТЕУ! б ЕУМЙ РТПЭЕ, ФП чБЫЕ ЙНС ФЕРЕТШ ЪБНЕОСЕФ чБЫ IP.
Динамический DNS ‒ это технология, которая применяется для назначения постоянного доменного имени компьютеру с изменяемым IP-адресом. Другие машины в Интернете могут устанавливать соединение с этой машиной по доменному имени и даже не знать, что IP-адрес изменился.
О сервере и сервисе
Сервис всегда будет предоставляться бесплатно
Для пользователей сети Домолинк трафик бесплатный!
Основные принципы
Обычно, серверы имеют статические IP-адреса. Для определения этого IP-адреса по имени делается запрос к DNS -серверу. При этом, обычно делается запрос к ближайшему DNS -серверу, обычно, серверу вашего интернет-провайдера. Всю остальную работу по разрешению имени в адрес делает этот DNS -сервер.
Если в его локальном кэше уже имеется информация об этом имени, он не делает дальнейших запросов, просто возвращает IP-адрес (и другие данные) из кэша. Так может быть, если кто-то до вас уже запрашивал эту информацию у этого DNS -сервера. Сервер помнит данные какое-то время, которое называется временем жизни (TTL, time to live) записи, а потом «забывает».
Если же актуальной информации нет (сервер не является авторизованным для данной зоны, а последний запрос об этом имени был сделан более, чем TTL назад, и сервер уже «забыл» что ему ответили), наш ближайший DNS -сервер ищет авторизованный за запрошенную зону, и спрашивает адрес у него.
В типичных случаях для записей указывается большое значение TTL - 4 часа, 24 часа и даже неделю, ведь эта информация почти никогда не меняется. Таким образом достигается снижение нагрузки на авторизованные серверы, поскольку обращения к ним происходят реже. Взамен, если мы изменяем адрес, придётся подождать: весь мир начнёт запрашивать адрес только через 4 часа, 24 часа, неделю соответственно - или что у нас там указано.
Для динамических хостов это неприемлемо - если у вас только что изменился адрес, все должны сразу же получать актуальную информацию, и поэтому, используются маленькие значения TTL. В нашей системе используется значение 10 минут, и это означает, что после смены адреса в зоне пройдёт не более 10 минут, прежде чем весь мир будет обращаться уже по новому адресу.
Каталог
Как попасть в каталог
Для добавления своего ресурса в этот каталог необходимо в настройках Динамического DNS напротив поля Описание поставить галочку и заполнить описание.
Настройка
Интерфейс панели управления
Посредством переключателя вы можете выбрать базовый тип добавляемой вами записи: A или NS.
Записи типа A
Это обычная запись, в которой указывается ваш IP-адрес. Он изменяется при динамическом обновлении.
При этом, вы можете дополнительно создать MX-запись для своего хоста, в которой указывается доменное имя сервера, который обслуживает почту для вашего домена. При этом в зону добавляется запись name..exchanger.host.name . Если вы не добавите MX-запись, предполагается, что почтовый сервер находится по тому же адресу, что указан в A-записи.
Ещё вы можете добавить в зону Wildcard-запись. Это может потребоваться, чтобы работало не только имя name..name..name..other.subdomain.name.. При этом в зону добавляется запись *.name.сайт. CNAME name.сайт. , так называемая Wildcard-запись.
Записи типа NS
Такие записи предназначены для продвинутых пользователей, которые способны самостоятельно настроить DNS -сервер, и которым записей A, MX и Wildcard CNAME недостаточно. Выбирая тип NS, вы настраиваете перенаправление всех запросов о зоне name..
Если вы не уверены, что способны правильно настроить DNS -сервер, не выбирайте этот тип! Если вы всё-таки выбрали, знайте, что в родительскую зону добавляется две записи вида name..name..name.сайт A <ваш-ip-адрес> , причём эта A-запись изменяется при динамическом обновлении.
На своём DNS -сервере вам следует:
создать зону name.сайт ,
в SOA-записи указать ответственным сервером ns.name.сайт ,
добавить NS-запись name.сайт. NS ns.name.сайт. (других записей NS делать не нужно),
добавить A-запись ns.name.сайт. 600 A ваш-внешний-ip-адрес, которая тоже должна динамически обновляться при смене вашего внешнего адреса (600 - это TTL записи, равный 10 минутам = 600 секунд).
Редактирование
В режиме редактирования хоста вы видите ссылку для обновления только этого хоста, а также форму, совершенно аналогичную второй форме на главной странице панели. Здесь вы можете изменить адрес MX, добавить или убрать Wildcard и задать ip-адрес, отличный от того, с которого вы обращаетесь.
Добавление записи
Для того, чтобы добавить запись, нужно:
В поле Имя записи ввести желаемое имя.
С помощью переключателя установить тип записи - А или NS. Скорее всего, вам потребуется запись типа A с включенной Wildcard.
Если вам нужно добавить запись с конкретным IP-адресом, то установите флажок Указать другой IP-адрес , в котором можно ввести любой корректный адрес в форме dotted quad notation (четыре числа, разделённые точками). Если вы этого не выберете, будет указан ваш текущий IP-адрес (с которого вы обращаетесь к системе).
4. Нажмите кнопку Добавить . Запись добавится и появится в списке.
Проверка
Для того, чтобы проверить, что запись в зону добавилась, нужно выполнить следующие действия:
Заходим в «Пуск» ⇒ «Программы» ⇒ «Стандартные» ⇒ «Командная строка»
В открывшемся окне (это консоль Windows) вводим команду nslookup ваше_имя.сайт.
Перед вами предстанет отчет программы. Две верхние строчки рассказывают нам о DNS -сервере - если вы пользователь Домолинк, это скорее всего будет ns.vsi.ru, 80.82.32.9. Далее идет информация о вашей записи: после слова Name будет указано имя, а после слова Address - IP-адрес.
Updater - Автоматическое обновление DNS
Установка
Необходимо запустить файл updater.exe
В появляющихся окнах надо поочередно нажать кнопки Далее - Установить - Закрыть
Программа установится в папку C:\Program Files\updater\
В меню Пуск появится ярлык Динамический DNS для запуска программы.
В Linux ярлык для запуска попадает прямиком в меню Интернет .
Использование и настройка
Щелкните правой кнопкой мыши по значку программы в трее и выбирите пункт Настроить
В зависимости от того, каким образом вы собираетесь аутентифицироваться, выберите пункт По логину с паролем или По ключу , после чего заполните соответствующие поля.
Опционально, если есть желание обновлять только отдельную запись, то можно указать полное доменное имя этой записи в строке Отдельный хост , предварительно установив галочку в напротив этого поля.
По окончанию настройки жмем кнопку в нижнем правом углу окна.
Окно настроек закроется и программа перечитает эти настройки.
Теперь нажимаем на значок программы правой клавишей мыши и в контекстном меню выбираем пункт Включить автообновление .
После этого программа автоматически будет выполнять обновление с интервалом в 20 минут . Если вам не подходит такой вариант, вы можете выключить автообновление или даже не включать его вовсе. А выполнять данную операцию только когда вам потребуется, с помощью пункта контекстного меню Обновить вручную .
Обновление ДНС с использованием стандартных средств ОС
Для того, чтобы указать новый IP-адрес для вашей записи (например, после разрыва связи), достаточно зайти по специальной ссылке. Конечно, вы можете делать это каждый раз вручную, но можно настроить и автоматическое обновление.
Для пользователей Windows
Для того, чтобы ваша запись автоматически обновлялась, нужно проделать следующие действия:
- (ссылка должна быть целиком заключена в двойные кавычки!)
Заходим в эту папку и создаем там файл ddns.bat следующего содержания: wget "ссылка_для_обновления" del update*
Открываем «Пуск» ⇒ «Программы» ⇒ «Стандартные» ⇒ «Служебные» ⇒ «Назначенные задания»
Нажимаем на надпись Добавить задание , потом далее .
Нажимаем Обзор и выбираем файл С:\ddns\ddns.bat
В появившемся окне вводим Название задания (любое на ваш выбор) и устанавливаем переключатель в положение ежедневно .
В следующем окошке указываем время, в которое будет выполняться обновление.
Составление ссылки обновления DDNS
Обновление происходит посредством отправки на сервер DDNS соответствующего HTTP GET-запроса. Запрос состоит из пути до скрипта и параметров скрипта.
Параметры скрипта, относящиеся к системе обновления DDNS:
Для идентификации при обновлении везде нужно использовать либо связку имя-пароль, либо ключ пользователя-владельца.
Можно указать хост, который обновляется. Если хост не указан, будут обновлены все хосты данного пользователя.
Можно указать ip-адрес, который будет назначен соответствующим A-записям ($host для записи типа A, либо ns.$host для записи типа NS). Если адрес не указан, будет использован IP-адрес, с которого пришёл запрос на обновление.
Примеры запросов:
Обновить хост elve.сайт текущим адресом, при условии, что этот хост принадлежит пользователю с соответствующим ключем
Указать для хоста elve..168.168.2, если этот хост принадлежит пользователю elve
Обратите внимание, что такая ссылка генерируется автоматически в панели управления Динамическим DNS . При этом, ссылка для обновления всех хостов находится на основной странице панели, а ссылка для обновления конкретного хоста - на странице редактирования этого хоста.
Что такое DNS?
DNS расшифровывается как Domain Name System или Domain Name Service. Вы указали имя, а DNS подставляет ip адрес ресурса, на котором размещен сайт. Название в данном случае именно имя хоста или IP адрес. Без DNS вы должны были бы помнить IP адрес каждого сайта, который хотите посетить. Сегодня в Интернете более 300 миллионов веб-сайтов, помнить IP адрес необходимого сайта совершенно невозможно.
Что такое динамический IP?
Как сделать статический ip адрес из динамического?
Нет необходимости покупать статический IP. Используйте наш бесплатный Dynamic DNS для сопоставления динамического адреса или длинного URL с Вашим ресурсом, чтобы легко запомнить имя хоста. Удаленный мониторинг Вашего дома через веб-камеру на любом порту или запуск собственного сервера у Вас дома с динамическим IP адресом - все это доступно с сервисом DnsIP . В случае выделения провайдером динамического IP такой сервис, как Dynamic DNS, становится необходимым.
При регистрации на нашем сервисе Вы получаете доменное имя. Специальный клиент, который необходимо скачать, устанавливается на пользовательский компьютер. Этот клиент периодически отправляет информацию DNS-серверу, сообщая о своём IP адресе. Сервер службы DynDNS сохраняет последний IP пользователя и при обращении к пользовательскому доменному имени, полученному при регистрации, перенаправляет запрос на этот IP.
Приватная сеть.
Обычные сервисы предлагают доменные имена лишь третьего уровня. Это может быть неудобно. При наличии внешнего динамического IP адреса наш инновационный проект позволяет получить доменное имя не только третьего, но и первого уровня. Установив специальное приложение на компьютерах, Вам станет доступна приватная сеть, в которой будет возможность обращаться к службам или программам по любому протоколу или порту. При этом никакой трафик не будет проходить через наш сервер. Вся информация будет передаваться между компьютерами напрямую.
Удаленный компьютер и удаленный рабочий стол.
С помощью DynDNS Secure сервис DnsIP позволяет организовать подключение к удаленному компьютеру через любые программы удаленного доступа, используя любой порт. При этом Вы напрямик связываетесь с удаленным компьютером, а наш сервис лишь сообщает Вашим программам необходимый IP адрес.
Мониторинг сети.
Используя наш сервис, Вам станет доступен мониторинг сети. Все подключенные пользователи (имена их компьютеров) будут отслеживаться только Вами. Вы будете проинформированы какой компьютер находится online, а какой вышел из сети.
Если какое-либо приложение на удаленном компьютере не отвечает и возникла необходимость безопасно перезагрузить удаленную машину, Вы сможете это сделать нажатием кнопки без использования командной строки и специальных настроек брандмауэра и даже в том случае, если удаленная сеть не имеет внешнего IP-адреса. Достаточно лишь наличие подключения к Интернету.
Автонажатие на кнопку бесплатного доступа при использовании Yota.
В случае, если Вы исользуете бесплатный доступ к интернету от провайдера "Yota", один раз в сутки соединение блокируется, и появляется окно в браузере c предложением продолжить на медленной скорости. Это крайне неудобно при использовании удаленного доступа к данному компьютеру. В этом случае достаточно установить нашу бесплатную программу , и она восстановит доступ к интернету в течение нескольких минут. Эта опция доступна без регистрации пользователя на нашем сайте. При этом программу необходимо только установить, никаких настроек делать не нужно.
В любой момент времени можно узнать IP-адрес Вашего ресурса.
К Вашим услугам страница http://dns-free.com/dns2ip.php?dns=xxxxxxx, где xxxxxxx - имя домена в системе DnsIP. Используйте её для организации ссылок на Ваш ресурс с использованием системы динамического днс. Либо добавьте в избранное, и одним щелчком мыши узнайте текущий ip Вашего ресурса. Или введите вручную в форме на той же
СЕРГЕЙ СУПРУНОВ, инженер электросвязи широкого ИТ-профиля. В свободное время изучает FreeBSD и Python и пытается осмыслить свою нелюбовь к KDE
Конфигурируем DHCP-серверы
и настраиваем динамические обновления DNS
Клиент, конечно, всегда прав. Но ровно настолько, насколько ему это позволено сервером.
Установка и настройка DHCP-сервера ISC
Наиболее популярной реализацией DHCP-сервера в UNIX-подобных системах является dhcpd-разработка Internet Systems Consortium (ISC). По умолчанию в состав FreeBSD этапрограмма не входит. Она довольно легко устанавливается из коллекции «Портов»:
# cd /usr/ports/net/isc-dhcp30-server/
# make install
Но, к сожалению, на момент подготовки статьи единственная версия, которую можно было без проблем установить – 3.0.7, – была сильно устаревшей (в марте 2009 года официально прекращена её поддержка).
В итоге было принято решение ставить ISC DHCP версии 4.1.0 из исходников (команда «./configure --help» после распаковки позволит просмотреть доступные опции конфигуратора; возможно, некоторые из них вы захотите использовать):
# fetch http://ftp.isc.org/isc/dhcp/dhcp-4.1.0.tar.gz
dhcp-4.1.0.tar.gz 100% of 1061 kB 174 kBps
# tar xzvf dhcp-4.1.0.tar.gz
# cd dhcp-4.1.0
# ./configure
# make
# make install
После установки придётся вручную подготовить сценарий автозапуска. За основу можно взять какой-нибудь из имеющихся в /usr/local/etc/rc.d или /etc/rc.d. Я здесь немного схитрил и воспользовался сценарием из порта isc-dhcp-30-server:
# cd /usr/ports/net/isc-dhcp30-server
# mkdir work
# make apply-slist
# cp work/isc-dhcpd /usr/local/etc/rc.d/
Поскольку имя демона и большинство ключей запуска совпадают, такая подмена не должна вызвать проблем.
Есть один важный момент – для работы DHCP-сервера ядро системы должно быть собрано с поддержкой псевдоустройства bpf (Berkeley packet filter; используется для получения «сырых» данных с интерфейса, в т.ч. широковещательных пакетов). В ядро GENERIC эта поддержка всегда включается, так что если вы не исключали её явно, то пересборка ядра потребоваться не должна.
Проверить, включено ли это устройство в ваше ядро, можно так:
$ grep bpf /usr/src/sys/`uname -p`/conf/`uname -i`
# The `bpf" device enables the Berkeley Packet Filter.
# Note that "bpf" is required for DHCP.
device bpf # Berkeley packet filter
Теперь добавим в /etc/rc.conf пару строк (правда, это будет работать лишь при условии, что обработка переменных предусмотрена сценарием автозапуска; в isc-dhcpd, который мы «выдрали» из портов, она предусмотрена):
dhcpd_enable="YES"
dhcpd_ifaces="nfe0"
Основные параметры задаются в файле /usr/local/etc/dhcpd.conf (файл-пример будет установлен во время инсталляции).
Рассмотрим пример не сложной, но вполне работоспособной конфигурации:
# Доменное имя. Имена хостов клиентов будут дополняться до FQHN
option domain-name "example.org";
# DNS-серверы, которые будут предлагаться клиентам.
# Можно использовать и IP-адреса оных
option domain-name-servers ns1.example.org, ns2.example.org;
# «Умолчальное» и максимальное времена аренды адреса в секундах
default-lease-time 3600;
max-lease-time 86400;
authoritative;
# Способ динамического обновления DNS.
# Подробнее поговорим позже, сейчас отключим
ddns-update-style none;
# Источник сообщений для записи логов через syslogd
log-facility local7;
# Объявление подсети
range 192.168.1.200 192.168.1.249;
Option routers 192.168.1.1;
В самом начале файла размещаются глобальные параметры, которые при необходимости могут быть переопределены далее, в отдельных «объявлениях» подсетей и диапазонов. Обычно здесь задаются имя домена, список DNS-серверов (если используются одни и те же для большинства обслуживаемых сетей), значения для времени аренды (по умолчанию максимальное, при необходимости можно задать минимальное).
Параметр authoritative позволяет объявить сервер авторитативным (ответственным) в обслуживаемой сети. Отличие авторитативного сервера от «обычного» заключается в том, что последний игнорирует любые запросы адресов, которые не описаны в его конфигурации, в то время как авторитативный сервер в ответ на такие запросы отсылает DHCPNAK. Благодаря такому поведению клиент, перемещённый из другой подсети, сможет быстрее получить новый адрес (в ответ на DHCPREQUEST с адресом из прежней подсети он сразу получит DHCPNAK и приступит к получению нового адреса; в противном случае DHCPDISCOVER будет отправлен лишь по истечении тайм-аута на ожидание ответа). В то же время «случайные» DHCP-серверы (например, ошибочно запущенные с настройками из файла-примера) с меньшей вероятностью смогут помешать работе сети, поскольку, будучи неавторитативными, будут просто игнорировать «чужие» запросы DHCPREQUEST.
Для ведения логов (а они никогда лишними не будут), помимо объявления источника (facility) в конфигурации dhcpd, вам нужно будет сделать ещё две вещи: создать файл протокола (например, командой «touch /var/log/dhcpd.log») и добавить строку в /etc/syslog.conf:
local7.* /var/log/dhcpd.log
После чего syslogd нужно перезапустить:
/etc/rc.d/syslogd restart
Ну и не забудьте настроить ротацию данного лог-файла в /etc/newsyslog.conf.
Вернёмся к конфигурации dhcpd. Всё самое интересное содержится в описании подсети subnet. В нашем примере всё элементарно – строкой range мы задаём диапазон адресов, которые dhcpd сможет «сдавать в аренду» клиентам, опция routers задаёт список маршрутов по умолчанию. Ещё одна обязательная для работы в сети настройка – адреса DNS‑серверов – будет получена из глобальной опции domain-name-servers.
Обратите внимание на то, что именно по описанию subnet авторитативный сервер будет различать «допустимые» и «недопустимые» адреса. Так, сервер, запущенный сприведённой выше конфигурацией, в ответ на запрос (DHCPREQUEST) адреса 192.168.0.22 будет возвращать DHCPNAK (поскольку запрошенный адрес в известную ему подсеть непопадает), но «промолчит» при запросе адреса 192.168.1.22 (т.к. этот адрес, хотя и не включён ни в один из диапазонов range, является правильным для данной подсети и вполне может обслуживаться вторым DHCP-сервером; об этом чуть подробнее поговорим через раздел).
Помимо диапазона адресов и шлюза в описании подсети можно задать огромное множество дополнительных опций. Полный список поддерживаемых опций можно найти всправке: man dhcp-options(5).
Если несколько подсетей доступны через один интерфейс, то их объявления subnet должны быть вложены в объявление shared-network:
shared-network rl0-net {Subnet 192.168.1.0 netmask 255.255.255.0 {
Range 192.168.1.100 192.168.1.199;
Option routers 192.168.1.1;
Subnet 192.168.2.0 netmask 255.255.255.0 {
Range 192.168.2.100 192.168.2.199;
Option routers 192.168.2.1;
Общие для всех подсетей опции можно вынести непосредственно в объявление shared-network – в этом случае они будут влиять на все объявления subnet.
Пулы и классы
Иногда возникает необходимость разделять клиенты по тому или иному признаку и выдавать им разные опции. Например, мы хотим клиентам, имя хоста которых начинается на«a» (например, «acer»), раздавать адреса из диапазона 10.0.0.10 – 10.0.0.19, а всем остальным – из 10.0.0.20 – 10.0.0.99. Для этого можно использовать объявление класса и два такназываемых пула:
class "a-clients" {Match if substring (option host-name, 0, 1) = "a";
subnet 10.0.0.0 netmask 255.255.255.0 {
Pool {
Allow members of "a-clients";
Range 10.0.0.10 10.0.0.19;
Pool {
Deny members of "a-clients";
Range 10.0.0.20 10.0.0.99;
То есть мы отнесли к классу a-clients клиентские машины согласно приведённому выражению, а затем создали два пула, в одном из которых разрешили обслуживание членов соответствующего класса, в другом, наоборот, запретили. Аналогично можно строить выражения по MAC-адресу (переменная hardware) и другим опциям. Подробнее о синтаксисе выражений, допустимых в конфигурации dhcpd, можно почитать на странице man dhcp-eval(5).
Помимо признака членства в определённом классе команды allow/deny поддерживают выражения unknown-clients (клиенты, не передавшие свои имена хостов), known-clients (соответственно передавшие) и all clients (любые клиенты). Подробности ищите в документации.
Фиксированные адреса
Иногда возникает необходимость более чётко контролировать получение адресов некоторыми хостами. Например, выход в Интернет требуется лишь некоторым компьютерам локальной сети, а на прокси-сервере доступ регулируется по IP-адресу. Можно «избранным» хостам назначать вручную адреса, не попадающие в интервал, обслуживаемый сервером. А можно воспользоваться механизмом назначения фиксированных адресов, который предоставляет dhcpd:
host acer {Hardware ethernet 00:1b:38:22:8c:17;
Fixed-address 10.161.193.177;
Если добавить этот фрагмент в конфигурационный файл (и не забыть перезапустить dhcpd), то данный хост будет всегда получать указанный IP-адрес. Идентификация хоста будет осуществляться по MAC-адресу. IP-адреса, закреплённые таким образом за определёнными хостами, не должны попадать ни в один из диапазонов range.
Если нужно описать несколько хостов, имеющих много одинаковых опций, их можно объединить в группу:
group {Общие опции...
Host acer { ...специфичные для хоста опции...}
Host fuji { ...специфичные для хоста опции...}
В этом случае общие опции выносятся в объявление группы, а индивидуальные остаются в объявлениях host.
Особенности использования нескольких DHCP-серверов
В сравнительно больших сетях по соображениям надёжности и балансировки нагрузки обычно используют несколько DHCP-серверов. Очевидно, что при этом необходимо избегать «перекрытия» адресного пространства, когда один и тот же IP-адрес может быть выдан различными серверами. В противном случае возможен конфликт – ведь если сервер «А» выдаст клиенту некоторый адрес, то сервер «Б» по-прежнему будет считать его свободным и может выдать его другому клиенту (клиент, перед тем как принять IP-адрес, должен спомощью ARP-запроса убедиться, что тот свободен; это несколько снижает вероятность конфликта, но всё же не исключает его полностью).
Классическая рекомендация, известная как «правило 80/20», звучит так: один сервер (основной) должен обслуживать 80% адресов пула, второй сервер (вспомогательный) – оставшиеся 20%. Это позволит сети «продержаться» некоторое время на одном вспомогательном сервере в случае проблем с основным, при условии, что не все клиенты начнут запрашивать адреса одновременно. Правда, применяя это правило в своей сети, желательно убедиться, что именно основной сервер является более быстрым – иначе вспомогательный сразу раздаст свой пул клиентам, и при возникновении нештатной ситуации ему просто нечего будет им предложить. (В настройках сервера ISC можно задать параметр min-secs, задающий задержку в секундах перед выдачей ответа клиенту. Её использование на вспомогательном сервере повысит шансы на то, что первым будет отвечать основной.)
Возникает вопрос – а не будут ли мешать друг другу два авторитативных DHCP-сервера? Если у них будет одинаковое объявление подсети (но разные, непересекающиеся интервалы адресов, описанные в range), то запрос адреса из такой подсети, даже не попадающий в обслуживаемый конкретным сервером диапазон, не будет рассматриваться как «чужой» – сервер просто ничего не будет отвечать, позволяя тем самым обработать этот запрос другому серверу. Если этот «другой сервер» недоступен, то клиент, не дождавшись ответа на DHCPREQUEST, отправит запрос DHCPDISCOVER и будет благополучно обслужен оставшимся в строю сервером.
Некоторые серверы (в частности, ISC), поддерживают так называемый механизм DHC-FAILOVER (подготовка соответствующего стандарта остановилась на документе http://tools.ietf.org/html/draft-ietf-dhc-failover-12), предоставляющий двум серверам возможность разделять общий пул IP-адресов, синхронизируя информацию о выданных адресах ипозволяя динамически подменять друг друга при необходимости.
Динамический DNS
Итак, задачу автоматического получения настроек компьютерами сети мы решили. Но остался ещё один вопрос – интеграция с DNS-сервером. Конечно, в большинстве сетей можно обойтись и без этого – доступ по имени обычно бывает нужен только на серверы, которые в свою очередь практически всегда настраиваются вручную, и потому статического DNS вполне достаточно. Но иногда всё же бывает удобно, когда каждый клиентский компьютер доступен в сети под своим именем (особенно если на постоянство IP‑адреса положиться нельзя), поэтому рассмотрим, как настроить динамическое обновление DNS-записей (предполагая, что в качестве DNS-сервера используется ISC BIND).
Прежде всего в настройках DNS-сервера нужно разрешить автоматические обновления:
# Объявляем ключ доступа (можно задавать и в каждой зоне, но так удобнее)key DHCP_KEY {
Algorithm hmac-md5;
# «Прямая» зона
zone "test.inr" {
Type master;
File "master/test.inr";
# «Обратная» зона
zone "0.0.10.in-addr.arpa" {
Type master;
Allow-update { key DHCP_KEY; };
File "master/0.0.10.in-addr.arpa";
То есть мы объявляем ключ DHCP_KEY (имя может быть любым) и затем указываем его как условие, при котором будет разрешено обновление зоны (в описании всех зон, которые должны автоматически обновляться). Для генерации ключа (в строке secret) можно воспользоваться утилитой mmencode:
$ echo "Super secret key" | mmencode
U3VwZXIgc2VjcmV0IGtleQo=
Неплохо справляется с задачей утилита md5:
$ echo "Super secret key" | md5
Хотя более «правильным» способом формирования ключа считается использование утилиты dhssec-keygen:
$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST test.inr
Ktest.inr.+157+41531
$ ls -l Ktest.inr.+157+41531.*
Rw------- 1 amsand amsand 52 11 авг19:08 Ktest.inr.+157+41531.key
Rw------- 1 amsand amsand 92 11 авг19:08 Ktest.inr.+157+41531.private
Здесь мы создаём «хостовый» ключ длиной 128 бит, используя алгоритм HMAC-MD5, с именем test.inr. В результате формируется два файла – ключ можно извлечь из любого.
Ну и для повышения безопасности (поскольку файл named.conf обычно доступен на чтение всем пользователям) оператор key выносят в отдельный файл, доступный на чтение только пользователю root, а в named.conf подключают его с помощью оператора include:
include "key.conf";
Вместо allow-update можно использовать более «мощную» секцию update-policy (дополнительно ограничим тип записей и поддомен):
zone "test.inr" {Type master;
Update-policy {
Grant DHCP_KEY subdomain test.inr A TXT;
File "master/test.inr";
Теперь осталось внести некоторые изменения в конфигурацию DHCP:
# Указываем метод обновления (существует ещё ad-hoc, но он не рекомендуется)ddns-update-style interim;
# Описываем тот же ключ (можно просто скопировать из named.conf – синтаксис тот же)
# Если оператор key вынесен в отдельный файл, можно, как и в named.conf, использовать оператор include:
### include "key.conf";
key DHCP_KEY {
Algorithm hmac-md5;
Secret "c20f9433f5f5ecf1f245a6112d7dd651";
# «Прямая» зона, которую нужно обновлять
zone test.inr {
Primary 10.0.0.220;
Key DHCP_KEY;
# «Обратная» зона, которую нужно обновлять
zone 0.0.10.in-addr.arpa {
Primary 10.0.0.220;
Key DHCP_KEY;
В параметре primary при описании зон указывается адрес первичного DNS-сервера, обслуживающего зону (т.е. того, на который следует отправлять обновления).
Теперь осталось убедиться, что пользователь, от имени которого выполняется процесс named (на FreeBSD это обычно bind), имеет право создавать файлы в каталоге /var/named/etc/namedb/master.
Если всё сделано правильно, то после того как клиент в следующий раз запросит адрес, в каталоге master появятся файлы, соответствующие файлам зон, с расширением jnl. Это – журналы обновлений, используемые сервером для восстановления соответствующей информации после перезагрузки. В них-то и будут храниться соответствующие ресурсные записи (в двоичном формате, поэтому их чтение ничего полезного вам не даст).
В случае проблем обращайтесь к лог-файлам. Ниже показаны два сообщения из /var/log/messages, с которыми приходится сталкиваться наиболее часто:
May 4 17:23:14 freetest dhcpd: if acer.example.org IN A rrset doesn"t exist add acer.example.org 300 IN A 10.0.0.180: timed out.
May 4 17:27:23 freetest named: master/test.inr.jnl: create: permission denied
Первая запись в данном случае вызвана нестыковкой доменных имён – в конфигурации DHCP был задан «умолчальный» домен example.org, который нашим DNS-сервером необслуживается. К сожалению, это не единственная причина возникновения тайм-аута – следует рассматривать также права доступа к соответствующим файлам, правила пакетных фильтров (если DHCP и DNS работают на разных машинах), правильность указания адреса DNS-сервера.
Вторая указывает на то, что процесс named не может создать jnl-файл в каталоге master. Очевидно, что проблема кроется в правах доступа – позаботьтесь, чтобы процесс named мог создавать файлы в каталоге master, и проблема исчезнет.
Как видите, DHCP – довольно мощный протокол, позволяющий автоматизировать весьма значительную часть процесса настройки сети. К сожалению, из-за некоторой «сырости» в плане стандартизации и определённых проблем безопасности о 100-процентной автоматизации пока говорить не приходится. Но это не мешает его использовать уже прямо сейчас.
Приложение
WIDE DHCP
Нужно сказать, что ISC DHCP – не единственный вариант. В коллекции портов можно найти ещё один DHCP-сервер – WIDE DHCP. Правда, этот проект трудно назвать «действующим» – текущая версия в «Портах» (1.4.0.6_2) практически не обновлялась с 2003 года, страничка проекта (http://www.sfc.wide.ad.jp/~tomy/dhcp/index-e.html) заброшена. Темнеменее с основной задачей он вполне справляется.
Установка из коллекции портов потребует дополнительной работы. Начало традиционно:
# cd /usr/ports/net-mgmt/wide-dhcp
# make install
В итоге в /usr/local/sbin появится файл dhcps, будет создан сценарий автозапуска, а также добавятся соответствующие man-страницы.
После этого нужно подправить сценарий автозапуска /usr/local/etc/rc.d/wide-dhcps.sh.sample (и переименовать его в wide-dhcps.sh). Мало того, что он в «старом» формате (т.е.неподготовлен для утилиты rcorder), так ещё и недоработан. Пришлось вручную ввести переменную PREFIX и добавить в строку запуска dhcps опции, определяющие местоположение конфигурационных файлов и баз данных. В этой же строке нужно указать интерфейсы, на которых dhcps должен работать.
Далее файлы dhcpdb.pool и dhcpdb.relay нужно будет создать вручную (по умолчанию в /etc, я изменил каталог на /usr/local/etc, как это принято во FreeBSD). Примеры можно найти в каталоге db_sample дистрибутива. Второй из них служит для указания маршрутизаторов, через которые доступны другие подсети, обслуживаемые этим DHCP-сервером, и в случае «линейной» структуры сети его можно оставить пустым (но сам файл должен существовать). Первый же – это основной конфигурационный файл. Приведу несложный пример:
# Создаём подсеть (сюда выносим общие параметры:
# маску, шлюз и широковещательный адрес)
subnet:snmk=255.255.255.0:rout=10.0.0.1:brda=10.0.0.255:
# (первое поле – просто идентификатор записи,
# а также подключается определённая выше конфигурация subnet)
ip198: :ipad=10.0.0.198:dfll=3600:maxl=7200:tblc=subnet:
ip199: :ipad=10.0.0.199:dfll=3600:maxl=7200:tblc=subnet:
Как видите, для каждого адреса пула нужно прописывать свою строку, но зато и каждому адресу можно выдать свои параметры. Используется тот же формат файла, что и для системных баз termcap, printcap и т.п.; список доступных параметров достаточно обширен (найти его можно на странице справки man dhcpdb.pool(5)).
После всех этих мучений сервер можно запускать, и он должен корректно функционировать. Правда, учитывая запутанный синтаксис конфигурации, я для себя не нашёл ни одной причины, почему эту реализацию можно было бы использовать вместо ISC. Но знать о её существовании в любом случае полезно.
Вопросы безопасности
К сожалению, безопасность протокола DHCP пока оставляет желать лучшего. Рабочими группами IETF предлагаются различные методы её повышения (например, аутентификация клиентов, см. RFC 3118), но они в большинстве своём ещё нигде не реализованы.
DHCP Relay
Как упоминалось в первой части статьи, в протоколе DHCP активно используются широковещательные запросы, которые практически всегда отбрасываются маршрутизаторами. Тоесть их распространение обычно ограничено одним сегментом локальной сети.
Однако зачастую оказывается нецелесообразно устанавливать отдельный DHCP-сервер в каждом сегменте. В этом случае на помощь приходит способность большинства маршрутизаторов работать в режиме DHCP Relay, «перебрасывая» запросы и ответы между отдельными подсетями. Принцип работы такого «прокси-сервера» заключается вследующем: получив на одном из обслуживаемых интерфейсов широковещательный DHCP-запрос, он перенаправляет его (уже обычным, одноадресным пакетом) определённым вего конфигурации DHCP-серверам. Полученный ответ транслируется широковещательным (при необходимости) пакетом в ту подсеть, откуда пришёл исходный запрос.
Большинство аппаратных маршрутизаторов функцию DHCP Relay поддерживают. Если же роль маршрутизатора между вашими подсетями выполняет FreeBSD или Linux, томожно установить либо программу dhcrelay, входящую в состав пакета ISC DHCP, либо отдельный сервер из коллекции портов – /usr/ports/net/dhcprelay. Настройка в обоих случаях сводится к запуску этой программы с опциями, определяющими список прослушиваемых интерфейсов и список DHCP-серверов, которым запрос нужно ретранслировать. Во FreeBSD в случае программы dhcprelay для её автозапуска достаточно включить в /etc/rc.conf три строки:
dhcprelay_enable="YES"
dhcprelay_server="10.0.0.220"
dhcprelay_ifaces="ed0
Кстати, функция DHCP Relay в некотором роде повышает управляемость сети, поскольку позволяет явно задать список DHCP-серверов, с которыми следует работать.
Утилита nsupdate
В дистрибутиве ISC BIND есть утилита, позволяющая отправлять динамические обновления DNS. Она может пригодиться как для поиска проблем (например, если при выдаче клиенту адреса сервером DHCP обновление зоны не происходит, но через nsupdate зоны обновляются нормально, становится очевидным, что следует разбираться с конфигурацией dhcpd), так и для обновления зон «вручную».
Рассмотрим типичный пример работы:
$ nsupdate -v
> server 10.0.0.220
> key DHCP_KEY
> update add new.test.inr 300 A 10.1.1.15
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
new.test.inr. 300 IN A 10.1.1.15
> send
> quit
То есть мы объявляем DNS-сервер и секретный ключ, после чего командой update add помещаем в «очередь» команду на добавление соответствующей записи (300 в данном примере – время жизни записи). Командой show можно просмотреть текущее состояние «очереди», send отправляет данный пакет серверу. Если всё прошло нормально (а поскольку никаких сообщений об ошибках не выведено, то так и должно быть), то, запросив у DNS-сервера адрес для new.test.inr, вы получите 10.1.1.15. (Да, этот адрес не является допустимым для нашей подсети, но в эти «тонкости» DNS-сервер не вдаётся – он просто делает свою работу.)
Помимо интерактивного режима работы nsupdate позволяет выполнять команды из файла, что может оказаться полезным для автоматического выполнения обновлений. Подробности ищите в справке man nsupdate(8).
- Страница официального сайта ISC DHCP – https://www.isc.org/software/dhcp .
- Колисниченко Д. Конфигурирование DHCP. //Системный администратор, №5, 2003 г. – С. 12-14 (http://www.algoint.ru/?MenuItem=tech_dhcp2).
- Иванов П. DHCP: искусство управления IP-адресами. – http://www.citforum.ru/internet/tifamily/dhcp.shtml .
- Bog BOS: Протокол BOOTP/DHCP – http://www.bog.pp.ru/work/bootp.html .
- RFC 2131. Dynamic Host Configuration Protocol – http://tools.ietf.org/html/rfc2131 .
- http://www.ietf.org/rfc/rfc2136.txt .
Из локальной сети домашнего роутера – можно обеспечить доступ не только к сети Интернет, но и к ресурсам самого роутера.
Речь может идти об FTP-сервере, где в качестве диска используется накопитель USB, и т. п. В то же время, есть возможность все эти ресурсы сделать доступными из «внешней» сети. Для чего, обычно используется сервис «динамического DNS». Мы рассмотрим, как настроить DDNS на роутере.
Локальная и «внешняя» сеть
Во-первых, постараемся объяснить, как используется DDNS. Из локальной сети сам роутер – доступен по одному и тому же адресу (например, 192.168.10.1). Во «внешней» сети, порту WAN назначается определенный IP-адрес, который в большинстве случаев – является изменяемым. Запоминать его бесполезно, так как значение могут поменять в любую минуту. Но есть возможность получить доступ к роутеру, не используя IP «в явном виде». Достаточно один раз зарегистрироваться в соответствующем сервисе, и настроить опцию DDNS в роутере.
После настройки DDNS, доступ к роутеру – осуществляется по доменному имени (которое, вдобавок, придумать может сам пользователь). Это удобно, но при условии, что все настроено правильно.
Как регистрироваться в сервисе DDNS?
Платные и бесплатные сервисы
Приводим список адресов сайтов, предоставляющих сервис DDNS:
- no-ip.com
- 3322.org
- dyndns.org
- dhs.org
- update.ods.org
- dyns.cx
Самый известный из них – это Dyndns. Все примеры настройки, как правило, приводятся «под него». Но данный сервис недавно стал платным. Так что, надо искать бесплатный сервис (из тех, которые поддерживаются в роутере).
Важно знать, что роутер определенной модели – может поддерживать работу только с некоторыми из DDNS-сервисов.
Рассмотрим пример для устройств TP-Link:
Вкладка «Dynamic DNS»
Как видим, в роутерах этой марки – можно использовать 1 из 3 разных сервисов (но не более). Их список – доступен на вкладке настройки DDNS. Что верно для роутеров разных моделей.
Регистрация в сервисе
Перед тем, как настраивать роутер, необходимо зарегистрироваться в DDNS-сервисе. Нужно получить доменное имя (сервис проверит его на уникальность), а только затем это имя – надо будет указывать в настройках.
Для прохождения регистрации потребуется е-мейл. Карточка нового пользователя – обычно содержит сведения: имя, фамилию, регион, е-мейл. Если требуется указать zip-код, можно оставить это поле пустым.
В результате, пользователь получит в свое распоряжение уникальное доменное имя. Например, такое: «1234router.no-ip.biz». Также, создается аккаунт для управления учетной картой (надо запомнить логин и пароль к нему).
Как настроить DDNS в роутере?
Вкладка параметров DDNS
Именно опцию DDNS в большинстве роутеров – настраивать проще всего. В web-интерфейсе должна быть вкладка, содержащая все требуемые параметры: доменное имя, логин с паролем, список сервисов.
Алгоритм настройки:
- Переходим на требуемую вкладку (обычно, «DDNS» или «Dynamic DNS» в разделе «Дополнительных настроек»)
- Выбираем сервис (тот, в котором регистрировались)
- Заполняем все пустые поля
- Если есть галочка «Enable» – устанавливаем ее, и обязательно сохраняем настройки:
Настройка DDNS в роутерах TP-Link
Подключать роутер к сервису DDNS – пользователь должен, открыв интерфейс и нажав кнопку «Login» (на рассмотренной выше вкладке). Подключение будет действовать до перезагрузки роутера.
Пример использования DDNS и известные проблемы
Допустим, все было выполнено правильно, и дополнительно, на роутере включен ftp-сервер. Тогда, из любой точки мира – этот сервер становится доступен по следующему адресу: ftp://1234router.no-ip.biz:80. Пример, конечно, является правильным, если было получено доменное имя «1234router.no-ip.biz».
Иногда бывает, что по доменному имени – роутер, все же, становится недоступен. В этом случае, достаточно зайти на сайт сервиса, открыть учетную запись (или указать доменное имя) – и в окне на странице появится IP роутера. Проблема в том, что через некоторое время этот IP может смениться.
Но, в принципе, такой метод тоже является актуальным: вместо «1234router…» указывается IP-адрес (который в действительности назначен порту WAN). Возможность увидеть значение IP – предоставляется любым из сервисов, причем, без каких-либо проблем.
Дополнительно, отметим главное отличие DDNS от 2IP.ru и подобного: узнать IP роутера с помощью DDNS – можно с любого устройства, подключенного к сети Интернет (из любой точки мира). Дальше, этот IP – используется для доступа к роутеру.
Пример настройки роутера D-Link под DynDSN
