Создание сайта начинается с выбора и регистрации доменного имени, то есть символьного адреса той части Всемирной сети, где и будет располагаться сайт. Грубо говоря, доменное имя - это адрес будущего сайта. Как правило, одному сайту соответствует одно доменное имя, но бывает и так, что на один сайт указывает сразу несколько доменных имен. Для того, чтобы не возникало путаницы, каждое доменное имя должно быть уникально.

Имена доменов иерархичны. Иными словами, имя каждого домена включает в себя перечисление всех более крупных доменов, в которые он входит. Например, адрес указывает на домен второго уровня, входящий в более крупный домен.ru, а адрес принадлежит домену третьего уровня, входящий в домен второго уровня и домен первого уровня.ru.

Домены первого уровня, такие как.ru, .com, .org, .ua, .uk и т. д., также называются зонами. В настоящее время зарегистрировать доменное имя первого уровня может только корпорация ICANN (Internet Corporation for Assigned Names and Numbers), осуществляющая надзор за интернет-адресами и протоколами, но в ближайшем она намерена разрешить их регистрацию за сумму в несколько десятков тысяч долларов в год.

Большая часть регистрируемых доменных имен - второго и третьего уровней. Доменные имена второго уровня проходят платную регистрацию. Впрочем, сумма, которую придется заплатить, как правило, невелика. Так, в зоне.ru ежегодная оплата за доменное имя составляет примерно 24 доллара. Тем не менее, люди, которым не требуется, чтобы их сайт производил солидное впечатление, например, желающие создать свою домашнюю страницу, предпочитают доменные имена третьего уровня, большинство из которых регистрируются бесплатно.

Регистрация бесплатного доменного имени

Многие серверы бесплатно предоставляют возможность зарегистрировать свое доменное имя. Так, например, большой популярностью пользуются доменные имена типа имя.narod.ru, предоставляемые компанией Яндекс. Регистрация подобных доменных имен происходит крайне просто: достаточно завести себе e-mail на соответствующем сайте, и за вами автоматически закрепляется то же имя, что и в электронной почте. То есть при регистрации электронной почты [email protected], пользователь получает право создать сайт с адресом ivanov.narod.ru (если это имя не занято). Аналогичным образом выглядит процедура регистрации на почтовом сервисе newmail.ru , а также некоторых других сайтах.

Желающим бесплатно зарегистрировать домен третьего уровня в зонах net.ru, org.ru и pp.ru необходимо обратить внимание на сайт Российского НИИ Развития Общественных Сетей . Здесь находятся весьма удобные формы онлайн-регистрации для организаций и физических лиц. На этом сайте существует ограничение по количеству доменных имен: за час в каждой из его зон один человек может зарегистрировать не более 4 доменных имен.

Регистрация платного доменного имени

По сути, регистрация доменного имени представляет собой внесение этого имени в реестр международной организации ICANN. Процессом оформления регистрации занимаются организации, имеющие на это разрешение от ICANN - так называемые регистраторы. Их список можно найти на сайте http://www.internic.com/ или на сайте самого ICANN http://www.icann.org/en/registrars/accredited-list.html . Регистрацией доменных имен в зоне.ru занимается Координационный центр национального домена сети Интернет . На его сайте можно найти полный список аккредитованных регистраторов в зоне.ru. Причем многие из указанных там организаций осуществляют регистрацию не только в национальном домене, но и в других зонах, например, .su, .com, .biz, .net.

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

Оплата регистрации доменного имени, как правило, происходит через , например, через Яндекс.Деньги, или WebMoney. Кроме того, можно воспользоваться кредитной картой. Единой цены для регистрации доменных имен не существует: она зависит от зоны. Однако все доменные имена внутри одной зоны стоят одинаково.

Whois и киберсквоттинг

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

Если окажется, что выбранное доменное имя занято, то остается либо придумать новое, либо узнать, не согласится ли его владелец перепродать это доменное имя вам. Стоит отметить, что некоторые пользователи делают подобную перепродажу доменных имен постоянным способом заработка. Подобных людей называют киберсквоттерами, а сам процесс перехвата доменных имен - киберсквоттингом. Это слово происходит от английского squatting, означающего незаконное поселение на чужой земле или в чужом доме.

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

Иногда необходимо прописать DNS для компьютера с динамическим IP адресом. Простым путем для этого являются сервисы по типу dyndns , описанные в недавнем топике Связываем домен и динамический IP . Иногда такой подход работает достаточно плохо.

Напрмер в моей ситуации, провайдер иногда меняет мой публичный IP адрес. Это иногда случается обычно раз в несколько месяцев. Кроме того, мой домашний компьютер перезагружается крайне редко. За это время сервис dyndns, которым я пользовался ранее успевал пару раз прислать мне оповещения о неактивности с целью отключить «неиспользуемый» аккаунт. Перейти на вручную прописываемую DNS зону также не получается, потому что иногда адрес все же меняется. Причем обычно об этом узнаешь когда нужен доступ к домашнему компьютеру здесь и сейчас.

Для реализации описываемого метода понадобится сервер в интернете с DNS сервером bind на нем. А так же доменная зона, субдомен которой мы будем выделять для нашего компьютера. Описывается вариант с подключением Linux-компьютера к Linux-серверу. Для использования других операционных систем понадобится почитать мануалы и модифицировать некоторые шаги.

Итак:
1. Имеем установленный сервер bind9 с доменом server.org
2. Создаем зону client.server.org.zone:

$ORIGIN .
$TTL 10 ; 10 seconds
client.server.net IN SOA ns1.server.net. hostmaster.server.net. (
18 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
10 ; minimum (10 seconds)
$TTL 3600 ; 1 hour
NS ns1.server.net.
NS ns2.server.net.
MX 10 client.server.net.

Здесь сервера ns1.server.net и ns2.server.net - DNS сервера для нашей зоны, client.server.net - адрес нашего домашнего компьютера

3. генерим ключи на клиенте:
client# cd /etc/namedb/keys
client# dnssec-keygen -b 512 -a HMAC-MD5 -v 2 -n HOST client.server.net.

4. Создаем фаил с ключем на сервере:
server# cd /var/named/chroot/etc
server# vim keys.conf:

Key client.server.net. {
algorithm "HMAC-MD5";
secret "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f+uIIxxei8qm7AVgNBprxtcU+FQMzBvU/Y+nyM2xbs/C8kF3eJQUA==";
};

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

Выставляем права доступа к фаилу с ключами:
server# chmod 640 keys.conf
server# chown root:named keys.conf

5. добавляем нашу зону в named.conf:
include "/etc/keys.conf"
zone "client.server.net" {
type master;
file "zones/client.server.net";
allow-update{
key client.server.net;
};
};

Здесь прописан параметр, который позволяет обновлять данные зоны. Вообще, почитав мануалы, можно найти опции этого параметра, позволяющие обновлять только одну запись в зоне для данного ключа. Т.е можно иметь зону с прописанными в ней поддоменами client1, client2, etc. которые будут авторизоваться с ключами key1, key2, etc.

6. Перезапускаем DNS сервер:
server# /etc/init.d/named reload

7. Создаем на клиенте скрипт, который будет обновлять данные зоны:
#!/bin/bash
IFACE="wlan0"
TTL=3600
SERVER=ns1.example.com
HOSTNAME=foo.example.com
ZONE=example.com
KEYFILE=/root/ddns-keys/Kfoo.example.com.+157+12345.private

New_ip_address=`ifconfig $IFACE | grep "inet addr:" | awk "{print $2}" | awk -F ":" "{print $2}"`
new_ip_address=${new_ip_address/ /}

Nsupdate -v -k $KEYFILE << EOF
server $SERVER
zone $ZONE
update delete $HOSTNAME A
update add $HOSTNAME $TTL A $new_ip_address
send
EOF

В начале скрипта описаны соответствующие параметры: интерфейс, имена сервера и зоны, местоположение фаила с ключем.

8. Осталось только настроить автозапуск/автоматическую смену адреса при смене DNS.
Мы это сделаем при помощи скрипта для NetworkManager:
создадим фаил /etc/NetworkManager/dispatcher.d/20-dyndns.sh:
#!/bin/sh

Iface=$1
state=$2

If [ "x$state" == "xup" ] ; then
/etc/namedb/ddns-update
elif [ "x$state" == "xdown" ]; then
true
fi

Сделаем его исполняемым и принадлежащим пользователю root.

Запускаем-проверяем-пользуемся.

Upd: Если не работает - проверяем (устанавливаем) на сервере права named на записть в папку в которой лежит фаил client.server.org.zone
named будет создавать там фаил client.server.org.zone.jnl

Использованы следующие материалы.

Для многих пользователей компьютерных систем понятие динамического DNS-сервера является несколько отвлеченным. Большинство юзеров понятия не имеет о том, что такое динамический ДНС и для чего используются серверы такого типа. Между тем ничего особо сложного и в понимании этого термина, и в настройке сервиса нет. Далее, к рассмотрению предлагаются теоретические сведения и практические решения, которые сможет без труда освоить любой человек, даже не знакомый с этими службами.

Динамический ДНС: что это и для чего нужно?

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

Все знают, что для ресурса в адресной строке браузера прописывается только название определенной страницы, состоящее из букв, цифр или специальных символов, а сервер DNS по имени ресурса производит перенаправление на соответствующий ему IP.

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

Вопросы динамического IP

Одним из основополагающих принципов работы динамических ДНС-серверов является наличие у клиентской машины динамического адреса IP. В случае использования статического адреса за его применение может потребоваться выложить немалую сумму денег. Именно поэтому при настройке DDNS покупать статический адрес и не нужно.

Специальные программные клиенты, устанавливаемые на пользовательских терминалах, могут производить такое преобразование без участия пользователя.

Преимущества использования DDNS

Но для чего же тогда применяется динамический ДНС-сервер? В качестве самого простого примера можно рассмотреть видеонаблюдение, организованное за счет установки регистратора и IP-камер.

Вроде бы в инструкции и написано, что данная модель поддерживает подключение через роутер с возможностью контроля происходящего через интернет, а на деле подключиться без сервера DDNS оказывается невозможным.

При использовании DDNS-технологии пользователи получают неоспоримые преимущества, среди которых отдельно можно выделить следующие:

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

Динамический (общие принципы)

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

В основе своей настройка сводится к тому, чтобы установить специальное приложение-клиент и добавить собственное название ресурса, для которого будут предоставлены три доменных имени третьего уровня. Это не всегда бывает удобным, поэтому в некоторые программы была добавлена возможность получения имени даже первого уровня.

Самые популярные платформы и клиенты

Динамический ДНС сегодня используется достаточно широко. Например, корпорация Microsoft для Active Directory применяет аутентификацию Kerberos без необходимости распространения ключей вручную.

Одной из наиболее популярных платформ для UNIX-систем является BIND, позволяющая произвести даже совместимость с Windows NT. Также динамический ДНС бесплатно предоставляют многие хостинговые компании, позволяя пользователям изменять содержимое контента через стандартный веб-интерфейс.

Если говорить о клиентских приложениях и сервисах, среди них наибольшей популярностью пользуются следующие:

  • ASUS DDNS;
  • No-IP;
  • HE Free ;
  • DNS-O-Matic;
  • Zone Edit;
  • DynDNS.

Рассмотрим настройку DDNS на примере каждого клиента.

ASUS DDNS

Тем пользователям, у которых имеется динамический ДНС-роутер от ASUS, повезло больше других. Для использования DDNS достаточно просто войти в раздел настроек и активировать сам сервис.

После этого следует придумать и зарегистрировать произвольное название, после чего пользователь получит доменное имя в виде «Название.asuscomm.com». Кроме того, динамический ДНС-список включает в себя еще множество дополнительных служб и сервисов, а также на сегодняшний день является чуть ли не самым большим.

No-IP

Не менее простую настройку предполагает и динамический ДНС в виде сервиса No-IP. Для него следует выполнить несколько простых шагов.

Сначала нужно зарегистрироваться на ресурсе noip.com и добавить с созданный при регистрации аккаунт нужный хост (функция Add Host). После этого для бесплатной регистрации станут доступны три доменных имени, для которых нужно будет придумать собственное название.

HE Free DNS Service

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

Однако именно эта служба привлекает пользователей достаточно внушительным списком дополнительных возможностей, на которые тут же представлены быстрые ссылки (сертификация, туннельный брокер, карта сети, управление протоколом IPv6, серверы DNS и telnet).

DNS-O-Matic

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

Как обычно, сначала нужно зарегистрироваться, а затем добавить сервис через функцию Add Service (например, из тех, что были перечислены выше). Далее. следует внести данные, использовавшиеся для регистрации именно в этих сервисах (User ID - адрес электронной почты, Password - пароль, Host/Identifier - имя домена третьего уровня, который был сгенерирован сервисом. По окончании ввода данных о привязке сервиса к аккаунту можно узнать по появившейся иконке в виде зеленой кисти руки с поднятым вверх большим пальцем напротив учетной записи указанного сервиса.

ZoneEdit

Все вышеперечисленные сервисы относятся к бесплатным. Теперь обратите внимание на данную службу.

Ее использование оплачивается в виде специальных «кредитов», стоимость которых приравнена к одному доллару США. То есть на год оплата составит двенадцать у. е. Процедура регистрации и настройки практически точно такая же, как и в первых примерах, поэтому останавливаться на ней подробно смысла нет.

DynDNS

Перед нами, пожалуй, самая популярная служба, хотя и не бесплатная. Стоимость ее использования стартует от двадцати пяти долларов в год.

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

СЕРГЕЙ СУПРУНОВ, инженер электросвязи широкого ИТ-профиля. В свободное время изучает 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 .

ЙЪ-ЪБ ИТПОЙЮЕУЛПК НПЪЗПЧПК ОЕДПУФБФПЮОПУФЙ ЬФПЗП РТПЧБКДЕТБ, С УФБМ ЙУЛБФШ УЕВЕ ОПЧЩК ЛБОБМ Ч йОФЕТОЕФ. йН УФБМ ччж гфл . лБЪБМПУШ ВЩ, ОЙЛБЛЙИ УМПЦОПУФЕК У РПДЛМАЮЕОЙЕН РП 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.