Если вы знаете, что такое IP-адрес и DNS , но не знаете, что такое DynDNS или знаете, но не знаете чем она может быть полезна, то эта статья для вас. Если вы не знаете, что такое IP-адрес и DNS и уж тем более DynDNS , но интернет дома вы получаете по технологии ADSL (например, ОГО от Укртелеком ), то эта статья тоже может оказаться полезной.

Начну все же с IP-адресов и DNS . Каждый компьютер который подключен к сети интернет имеет числовое значение которое служит для его однозначной идентификации. Это числовое значение и называется IP-адрес . Пример - 92.113.177.223 . Нам, людям, запоминать такие цифры трудно. Поэтому умные люди придумали DNS :)

Система доменных имен (DNS - domain name system ) позволяет сопоставить доменное имя (удобное для нас людей) с IP-адресом (удобным и необходимым для машин). Благодаря DNS мы набираем в адресной строке браузера не труднозапоминаемые IP-адреса , а понятные нам названия: ya.ru , сайт и т.д. :)

Ситуация развивается таким образом, что IP-адресов на все компьютеры уже не хватает, поэтому появились такие условные понятия как статический IP-адрес и динамический IP-адрес . Не путайте понятия динамический IP адрес и ! Статическим принято называть IP-адрес который выдается вам (вашему компьютеру) в аренду на определенный срок (обычно по этому поводу заключается договор с провайдером) и вы гарантировано в течении этого срока сможете им пользоваться и он не будет изменятся. То есть выдал вам провайдер адрес 80.80.100.150 и в договоре указано, что он будет статическим , значит вы все время сможете пользоваться этим адресом и никто другой его не получит. Что такое динамический IP-адрес проще всего показать на примере того же подключения ОГО от Укртелекома . Когда вы подключаетесь к интернету, то ваше оборудование тоже получает IP-адрес , но он не является постоянным, так как при следующем подключении вы получите другой адрес, потом третий и т.д. Конечно это будут IP-адреса из определенного диапазона, но какой точно IP-адрес вы получите при следующем подключении заранее неизвестно.

В динамических IP-адресах нет ничего плохого, если вы не начинаете решать более интересные задачи чем просто доступ в Интернет с вашего компьютера. Например обратная задача - . Возьмем самый просто случай - доступ к компьютеру по протоколу RDP - подключение к удаленному рабочему столу нашей Windows XP . Что нам нужно чтобы подключится к нашему домашнему компьютеру с рабочего компьютера? Да особо ничего. Разрешить и настроить само подключение на домашнем компьютере и знать его IP-адрес . Но знать IP-адрес мы наверняка не можем, так как он - динамический и может быть каким угодно в тот момент когда мы захотим подключится к компьютеру. Классическая система доменных имен (DNS ) работает только со статическими IP-адресами. И привязать доменное имя к нашему IP-адресу мы не можем.

Вот здесь нам и пригодится DynDNS . Данный сервис позволяет отслеживать изменения нашего IP-адреса и следит за тем, чтобы наше доменное имя было связано с актуальным на данный момент IP-адресом нашего компьютера. Тогда нам нужно запомнить только доменное имя компьютера, а DynDNS уже позаботится, чтобы с этим именем всегда был связан актуальный на данный момент IP-адрес.

Как это работает на практике? Расскажу на своем примере. Существует сайт который предоставляет такой сервис. Он так и называется dyndns.com . Зарегистрировавшись на этом сайте я завел там доменное имя вида kuzmenko.dyndns.org . И дальше на своем ADSL-модеме в разделе DynDNS , прописал свои учетные данные. Все. Теперь я по доменному имени всегда (пока сбоев за полтора года не было) могу зайти на свой компьютер. Если нужно более подробное описание регистрации или настройки на модеме - пишите, дополню.

Написал более подробно о том . Главное запомните, что настраивать DynDNS клиент нужно только на одном устройстве в сети , и по возможности на том, которое получает внешний динамический IP адрес.

В наши дни почти совсем не осталось бесплатных сервисов DDNS, которые позволяют подменять ваш динамический IP адрес в интернете на статическое доменное имя третьего уровня и получать благодаря этому прямой удаленный доступ к роутеру из интернета. Поэтому многие производители сетевого оборудования внедряют для своих клиентов собственные, наподобие TP-Link ID. Думаю, большинству это ни о чем не говорит, поэтому будем разбираться на пальцах, как сделать статический ip адрес из динамического и тем самым настроить удаленный доступ к роутеру.

Вспомним, как работает ваш домашний роутер с активированной ? Вы задаете ему диапазон (пул) локальных IP адресов.

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

Также есть возможность сделать из динамического статический ip адрес, то есть постоянный, привязанный только к одному устройству — в настройках роутера или на самом компе, смартфоне, ТВ, IP-камере и т.д.

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

Почти точно так же работает и ваш провайдер. Ваш микрорайон, который подключен к оборудованию провайдера — это не что иное, как большая локальная сеть. Когда вы подключаетесь к интернету, ваш хост (компьютер или роутер) является частью одной большой локальной сети с множеством маршрутизаторов. На оборудовании провайдера стоит DHCP сервер, и каждый раз, когда ваш компьютер или роутер подключается к интернету, то он внутри этой большой сети получает свой IP адрес, который ему автоматически присваивается сетевым оборудованием. При этом данный адрес может быть трех типов:

1. Статический — когда за вашей квартирой закреплен белый внешний IP, который никогда не меняется. То есть он всегда постоянный и зайдя по нему вы напрямую из интернета, попадете на свой компьютер или роутер. Поскольку такие адреса очень редкие, за них нужно платить отдельные деньги сверх тарифа.
2. Динамический — тоже белый айпишник, но который периодически меняется. Например, после перезагрузки роутера или по определенному промежутку времени. Это более часто встречаемый случай и именно с ним будет работьать технология замены динамического IP на статический, которая называется DDNS.
3. Серый — это самый частый случай, когда на целый дом или микрорайон выдается один внешний IP адрес, принадлежащий роутеру провайдера, а он уже в свою очередь раздает свои внутренние адреса пользователям. В качестве примера могу привести различные модемы и роутеры от мобильных операторов — они выдают интернет именно по такой технологии, и с ней даже при наличии DDNS нам ловить вообще нечего — чтобы из интернета получить доступ к вашему роутеру или устройству, к нему подключенному, нужно устанавливать VPN соединение.

Подробнее об IP адресах и о том, как определить, серый у вас или белый, я уже писал в .

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

Что такое DDNS и для чего он нужен в роутере?

DDNS (или Динамический DNS, DynDNS) — это технология, благодаря которой можно отследить изменения внешнего IP адреса и преобразовть его в статическое доменное имя. Оно всегда будет одинаковым и доступно из интернета по одному и тому же веб-адресу. Поддержка DDNS сервисов в маршрутизаторе как раз позволяет сделать статический ip адрес из динамического и организовать удаленный доступ к роутеру и ресурсам внутри вашей локальной сети из интернета.

Что требуется для использования DDNS?

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

• Белый статический IP адрес в интернете, который может предоставить провайдер
• Сделать статический ip адрес из белого динамического с использованием сервиса DDNS
• Использовать облачные сервисы
• Работа по протоколу адресации TCP/IP v.6 — это дело ближайшего будущего, так как пока почти никто из провайдеров данный стандарт не поддерживает, поэтому пока о нем говорить смысла нет.

Основная «фишка» в использовании сервисов DDNS — прямой доступ к роутеру и ресурсам, которые на его базе созданы, например к , не только при подключении к нему по wifi, но и из любой точки планеты по Интернету. Но работает она только при наличии внешнего БЕЛОГО IP адреса (динамического или статического)

Как сделать статический IP адрес из динамического с помощью сервиса DDNS No-IP.Com

Самым доступным и при этом бесплатным вариантом является использование сервиса NO-IP. Для наглядности опишу порядок его работы.

1. Ваш локальный сетевой ресурс, допустим домашняя ip-камера, получает IP адрес от вашего роутера
2. На роутере настроен , позволяющий обращаться к IP камеры через IP роутера + порт
3. Ваш роутер получает белый IP от провайдера и с ним выходит в интернет. Этот адрес периодически меняется, т.к. он динамический.
4. Сервис DDNS отслеживает изменение вашего внешнего IP и подменяет его на один и тот же зарегистрированный вами домен 3 уровня
5. Вы с другого компьютера через интернет, например, с работы, заходите по этому доменному имени, или по доменному имени + порт роутера, на который настроена камера
6. И попадаете на интерфейс камеры для просмотра картинки

Для организации этой схемы идем на сайт no-ip.com и заводим аккаунт. Это сервис DynDNS, который превращает ваш внешний динамический IP адрес в домен 2 или 3 уровня. Кликаем на кнопку «Sign Up», вводим все свои данные и подтверждаем email при помощи письма, пришедшего на ящик.

Далее заходим в свой аккаунт, используя зарегистрированные логин и пароль, жмем кнопку «Add Host» и заполняем подчеркнутые на скрине параметры. Точнее все они будут стоять по умолчанию, кроме Hostname, который вам надо просто придумать и выбрать домен.

Также обратите внимание, что в настройке «Host Type» должно быть включено «Port 80 Redirect» и в поле ввода номера порта быть указан именно тот, на котором работает программа или сервис в локальной сети, к которому мы хотим обращаться по данному доменному имени.

Сохраняем настройки и заходим в админку роутера. Находим здесь раздел, в котором настраивается подключение к динамическому DNS (DDNS).

Динамический DDNS на роутере TP-Link

В роутерах TP-LINK есть возможность выбрать из нескольких популярных сервисов DDNS в одноименном разделе меню «Динамический DNS «.

Выберем из списка «NO-IP» и введем заведенный нами домен, а также укажем логин и пароль для авторизации на сайте no-ip.com. После чего ставим галочку на пункт «Включить DDNS» и применяем настройки для перезагрузки роутера. Вот и все, теперь при обращении по зарегистрированному веб-адресу мы попадем точно на тот сервис, который использует указанный нами в аккаунте DDNS сервиса порт.

В новых бюджетных моделях раздел «DDNS » спрятан в «Дополнительных настройках »

У более дорогих моделей все еще более интересно — совсем недавно TP-Link внедрил облачные технологии, с помощью которых можно заменить DDNS — теперь все настраивается еще проще. Идем во вкладку «Дополнительные настройки», раздел «Сеть — DDNS». Тут можно также использовать существующую учетную запись в no-ip.com

Но гораздо удобнее поставить флажок в «Поставщике услуг» на «TP-LINK». Для того, чтобы все заработало, нужно авторизоваться под своим .

Если вы в нем еще не зарегистрировались, то не теряйте времени и сделайте это сейчас — он абсолютно бесплатен для пользователей роутеров TP-Link. Зато потом через облачные технологии сможете из-под своей учетной записи удаленно управлять роутером без каких-либо дополнительных сложных настроек DDNS, статических 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).

1. Страница официального сайта ISC DHCP – https://www.isc.org/software/dhcp .
2. Колисниченко Д. Конфигурирование DHCP. //Системный администратор, №5, 2003 г. – С. 12-14 (http://www.algoint.ru/?MenuItem=tech_dhcp2).
3. Иванов П. DHCP: искусство управления IP-адресами. – http://www.citforum.ru/internet/tifamily/dhcp.shtml .
4. Bog BOS: Протокол BOOTP/DHCP – http://www.bog.pp.ru/work/bootp.html .
5. RFC 2131. Dynamic Host Configuration Protocol – http://tools.ietf.org/html/rfc2131 .
6. http://www.ietf.org/rfc/rfc2136.txt .

http://www.dyndns.com/ .

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

Итак зайдя на сайт dyndns.com видим стартовую картинку, затем если вы уже бывали тут и в дальнейшем после регистрации жмём на Sign In (Войти) . А сейчас жмём на Get a FREE Domain Name (Получить бесплатное доменное имя)

Выбираем 1й бесплатный вариант и жмём Sign up (Зарегистрироваться)

1. Вводим имя для вашего поддомена (тут как пример teamspeak3) и выбираем домен из списка возможных , который вам больше по душе.

2. Вводим текущий ip адрес вашего ПК или сервера, если вы делаете эту операцию непосредственно с него, то можно нажать на ссылку Your current location IP address is (Ваш текущий ип адрес) и система сама подставит его в поле Ip Address.

3. Жмём на Add to cart (Добавить в корзину)

Ошибки :

Please enter a valid IP address (Забыли ввести ваш ип)

This hostname already exists (Этот поддомен уже заняли)

Ещё раз проверяем имя для вашего домена и стоимость всего 0$ за данную услугу, а далее заполняем непосредственно регистрационные данные .

1. Username (Придумайте и запомните имя пользователя для данного сервиса)

2. Password (Придумайте и запомните пароль)

3. Confirm password (Ещё раз введите пароль)

4. Email (Введите ваш рабочий адрес эл. почты, на него придёт подтверждение регистрации)

5. Confirm email (Ещё раз введите ваш эл. адрес почты)

6. Enter the number from the above image (Введите цифры с картинки)

7. I agree (Обязательно поставьте галочку, что согласны с условиями сервиса, остальные галочки можно не ставить)

Затем нажмите Create Account (Создать учётную запись)

Теперь щёлкаем на My hosts (Мои домены), чтобы просмотреть и активировать наш созданный поддомен.

Кликаем на Checkout to Activate , чтобы активировать домен

Вся процедура стоит 0 у.е., просто щёлкаем Next (Далее)

Осталось нажать Activate Services (Активировать сервисы), для завершения активации вашего домена.

Теперь получаем сообщение об успешной активации , осталось немного: научиться просматривать список ваших доменов и скачать программу для ПК (Сервера), которая будет автоматически сообщать серверу об изменении ip адреса.

DDNS — Dynamic DNS (динамический DNS).
Очень часто провайдеры Интернет при подключении к сети предоставляют внешний динамический ip-адрес (Stream, Beeline/Corbina и т.п.). Подавляющему большинству пользователей этого достаточно. Однако в некоторых случаях (для сетевых игр, для доступа к своему компьютеру из вне) необходим внешний статический адрес. Эту услугу предоставляют далеко не все провайдеры, а если и предоставляют, то за дополнительную плату. Обойти эту проблему можно с помощью технологии DDNS, позволяющей связать внешний динамический ip-адрес и постоянное доменное имя. Воспользоваться DDNS можно совершенно бесплатно!

Переадресация 80-го порта. Будет полезна тем, кто настроил свой веб-сервер на нестандартный порт. Избавляет от необходимости прописывать номер порта в адресной строке браузера.
TTL равное 4 часа. Подойдет тем, у кого адрес меняется относительно редко (компьютер, маршрутизатор работает целый день или дольше). В этом случае скорость доступа будет выше, т.к. будут задействованы механизмы кеширования DNS.

Для себя я выбрал no-ip.com, из-за более длительного срока действия акаунта.

Теперь перейдем к регистрации на сайте.

Регистрация на no-ip.com

Заполняем форму регистрации:

Обязательно требуется заполнить все поля кроме Zip/Postal Code.

В настоящее время выявился глюк, связанный с адресами mail.ru . При попытке зарегистрироваться появляется ошибка — “Enter a valid email address” . Выход — использовать любой другой почтовый адрес. Проверено, что с почтой от Яндекса и уж тем более Gmail регистрация проходит без проблем.

После нажатия на кнопку I Accept, Create my Account на ваш адрес будет отправлено письмо с ссылкой для активации акаунта. После активации вновь заходим на сайт и вводим свой логин / пароль. После входа в акаунт переходим в раздел Add a Host:

и переходим к настройкам хоста:

Hostname — выбираем имя домена третьего уровня. Справа в выпадающем списке выбираем домен второго уровня (какой больше нравится).
Host Type — для привязки к ip-адресу выбираем DNS Host(A). DNS Host(Round Robin) — для привязки доменного имени к нескольким ip-адресам (для балансировки нагрузки, платная функция). DNS Alias(CNAME) — привязка к доменному имени (создание синонима). Port 80 Redirect — перенаправление 80-го порта (в остальном аналогично DNS Host(A)). Web Redirect — привязка к URL.
Mail Options — оставляем без изменений.
В конце концов нажимаем Create Host.

Перед началом установки убедитесь, что вы подключены к Интернет.

Запускаем установщик. Все стандартно: выбираем расположение, отмечаем опцию Launch No-IP DUC (для запуска апдейтера сразу после завершения установки).

Переходим к настройке.

В начале необходимо ввести логин и пароль с которыми вы . Если логин и пароль правильные, вы должны увидеть список зарегистрированных хостов (см. Hosts).

Для обновления dns необходимо поставить галочки напротив нужных вам хостов (доменов). Процесс обновления начинается сразу после установки галочки (никаких дополнительных кнопок нажимать не надо). Под списком хостов программа выводит ip-адрес, используемый для обновления (на скриншоте выделено красным).

Для доступа к дополнительным настройкам нажмите кнопку Options.

Закладка Standard. Здесь четыре опции:

• Run on startup. Автоматический запуск программы при входе пользователя в систему. Также добавляет иконку программы в трей.
• Use alternate port. Использовать альтернативный порт. Вместо подключения к порту 8245 (по-умолчанию), программа будет использовать порт 80. Эту настройку нужно использовать в случае проблем с подключением к серверу no-ip (например, если провайдер блокирует порт 8245).
• Run as a system service. Запускать как службу. Настройка очень полезна, если в вашей системе несколько пользователей. Запускает клиент no-ip до входа пользователя в систему. Незаменима для серверов. Эту настройку можно комбинировать с Run on startup (если пользователь все же залогиниться, у него будет иконка no-ip в трее).
• Require password to resore window from system tray. Требовать пароль при открытии окна конфигурации. Позволяет защитить настройки клиента паролем. Единственный способ обойти пароль — удалить и установить клиент заново.

Закладка Connection. Подзакладка Standard. Здесь три опции:

• Override automatic connection detection и Override automatic ip detection. Эти опции полезны пользователям у которых несколько сетевых карт и при этом несколько активных подключений. Например подключены по локальной сети и одновременно по wi-fi. Первая опция позволяет вручную определить интерфейс, через который будет осуществляться подключение к серверу no-ip. Вторая опция позволяет вручную определить интерфейс, через который бдет определяться ваш внешний ip-адрес.
• Третья опция позволяет изменить частоту с которой клиент проверяет изменения внешнего ip-адреса. По-умолчанию этот интервал равен 30 минутам. Менять эту опцию советую только, если ваш ip меняется очень часто (уменьшить интервал до 5-10 минут).

Закладка Connection. Подзакладка Proxy.

Если подключение к интернет осуществляется через proxy-сервер, то здесь вы можете определить параметры подключения к нему.

Обычно proxy-сервера в домашних сетях почти не встречаются, так что для обычных пользователей эта закладка интереса не представляет. То же можно сказать и про закладки Scheduling/Autodial и Other, их описание я опущу.

Настройка маршрутизатора (D-link DI-804) для работы с DDNS
Настройка очень проста (на других маршрутизаторах с поддержкой DDNS выполняется аналогично).
Переходим в раздел настройки DDNS.

Выставляем опцию DDNS Enabled.
В поле Provider выбираем no-ip.com или dyndns.com.
В поле Host Name вводим имя домена (например example.no-ip.org).
В поле Username / E-mail и в поле Password / Key вводим логин / пароль с которыми зарегистрировались на сайте провайдера DDNS.
Сохраняем настройки. Перезагружаем маршрутизатор. Все.