Dns dhcp что это
Принципы работы протокола DHCP
DHCP — протокол автоматизации назначения IP-адреса клиенту. Он широко используется в современных сетях. В статье рассмотрим принципы работы, процесс DORA, основные опции и другие аспекты протокола.
Для чего нужен протокол DHCP
DHCP — протокол прикладного уровня модели TCP/IP, служит для назначения IP-адреса клиенту. Это следует из его названия — Dynamic Host Configuration Protocol. IP-адрес можно назначать вручную каждому клиенту, то есть компьютеру в локальной сети. Но в больших сетях это очень трудозатратно, к тому же, чем больше локальная сеть, тем выше возрастает вероятность ошибки при настройке. Поэтому для автоматизации назначения IP был создан протокол DHCP.
Впервые протокол был описан в 1993 году в документе RFC 1531, но с тех пор в описание вносились правки. На сегодняшний день основным документом, регламентирующим протокол, является RFC 2131. Помимо автоматизации процесса настройки IP, DHCP позволяет упростить диагностику подключения и переход из одной подсети в другую, оставляя уведомления для системного администратора в логах.
Принцип работы DHCP
Из вступления ясно, какие функции предоставляет DHCP, но по какому принципу он работает? Получение адреса проходит в четыре шага. Этот процесс называют DORA по первым буквам каждого шага: Discovery, Offer, Request, Acknowledgement.
Давайте подробнее рассмотрим DORA — принцип работы DHCP.
Протокол DHCP, получение адреса IP — DORA
Discovery, или поиск
Изначально клиент находится в состоянии инициализации (INIT) и не имеет своего IP-адреса. Поэтому он отправляет широковещательное (broadcast) сообщение DHCPDISCOVER на все устройства в локальной сети. В той же локальной сети находится DHCP-сервер. DHCP-сервер — это, например, маршрутизатор или коммутатор, существуют также выделенные DHCP-серверы.
Не всегда одну сеть обслуживает один DHCP-сервер, нередко организации устанавливают сразу несколько. Какие порты использует DHCP? Сервер всегда слушает 67 порт, ожидает широковещательное сообщение от клиента, а после его получения отправляет ответное предложение — DHCPOFFER. Клиент принимает сообщение на 68 порту.
Offer, или предложение
DHCP-сервер отвечает на поиск предложением, он сообщает IP, который может подойти клиенту. IP выделяются из области (SCOPE) доступных адресов, которая задается администратором.
Если имеются адреса, которые не должны быть назначены DHCP-сервером, область можно ограничить, указав только разрешенные адреса. Например, администратор может задать диапазон используемых IP-адресов от 192.0.0.10 до 192.0.0.255.
Бывает и так, что не все доступные адреса должны быть назначены клиентам. Например, администратор может исключить (exclude) диапазон 192.0.0.100 — 192.0.0.200 из используемой области. Такое ограничение называется исключением.
DHCP выделяет доступные IP-адреса из области только временно (об этом позже), поэтому нет гарантии, что при следующем подключении у данного клиента останется прежний IP. Но есть возможность назначить какому-либо клиенту определенный IP навсегда. К примеру, забронировать 192.0.0.10 за компьютером системного администратора. Такое сохранение IP для отдельных клиентов называют резервацией (reservation).
DHCPOFFER содержит IP из доступной области, который предлагается клиенту отправкой широковещательного (broadcast, «если вы тот, кто запрашивал IP-адрес, то доступен вот такой») или прямого (unicast, «вы запрашивали IP, предлагаю вот такой») сообщения. При этом, поскольку нужный клиент пока не имеет IP, для отправки прямого сообщения он идентифицируется по MAC-адресу.
Request, или запрос
Клиент получает DHCPOFFER, а затем отправляет на сервер сообщение DHCPREQUEST. Этим сообщением он принимает предлагаемый адрес и уведомляет DHCP-сервер об этом. Широковещательное сообщение почти полностью дублирует DHCPDISCOVER, но содержит в себе уникальный IP, выделенный сервером. Таким образом, клиент сообщает всем доступным DHCP-серверам «да, я беру этот адрес», а сервера помечают IP как занятый.
Acknowledgement, или подтверждение
Сервер получает от клиента DHCPREQUEST и окончательно подтверждает передачу IP-адреса клиенту сообщением DHCPACK. Это широковещательное или прямое сообщение утверждает не только владельца IP, но и срок, в течение которого клиент может использовать этот адрес.
Со схемой отправки сообщений разобрались, но, если в сети несколько DHCP-серверов, пославших предложение, какое из них выберет клиент? Хороший вопрос. В состоянии INIT, если клиент получает адрес впервые, он будет принимать только первое предложение IP. Однако, если клиент уже общался ранее с определенным DHCP-сервером, он отдаст предпочтение этому серверу и, наоборот, сервер выберет знакомого клиента.
Срок аренды
Когда DHCP-сервер выделяет IP из области, он оставляет запись о том, что этот адрес зарезервирован за клиентом с указанием срока действия IP. Этот срок действия называется срок аренды (lease time). Срок аренды может составлять от 24 часов до нескольких дней, недель или даже месяцев, он задается в настройках самого сервера.
Предоставление адреса в аренду, а не на постоянной основе необходимо по нескольким причинам. Во-первых, это разумное использование IP-адресов — отключенные или вышедшие из строя клиенты не резервируют за собой адрес. Во-вторых, это гарантия того, что новые клиенты при необходимости смогут получить уникальный адрес.
После получения адреса из области, клиент берет его в аренду на время, называемое T. Клиент переходит в связанное (BOUND) состояние и продолжает нормальную работу, пока не наступит время половины срока аренды — T1.
По наступлении T1 клиент инициализирует процедуру получения нового IP или обновления адреса — состояние RENEWING. Процесс повторного получения происходит по упрощенной схеме: клиент прямым сообщением запрашивает (DHCPREQUEST), а сервер подтверждает (DHCPACK) запрос. Время аренды начинает отсчитываться заново.
Если подтверждение (DHCPACK) от сервера не поступает, клиент снова запрашивает адрес, но только когда истекает половина T1. Если запрос адреса остается без ответа второй раз, клиент отправляет еще одно сообщение, когда истекает половина от T1/2 (25% от полного срока аренды). Следующий запрос будет отправлен после истечения еще половины оставшегося времени, потом еще половины. И так далее, пока не наступит T2, которое равняется 87,5%, или 7/8 от всего времени аренды. После T2 все попытки продлить аренду IP будут широковещательными. Это значит, что, если первый сервер по какой-то причине недоступен, на запрос адреса сможет ответить любой другой, и работа не будет прервана.
Три подхода к распределению адресов
Сервер назначает IP одним из трех основных способов.
Статическое распределение (static allocation). Почти как ввод адреса на каждом компьютере вручную. Отличие в том, что системный администратор задает нужные соответствия IP для MAC-адресов клиентов на самом DHCP-сервере. IP останется за клиентом, даже если тот выйдет из сети, отключится, перейдет в новую сеть и т.п.
Автоматическое распределение (automatic allocation). Сервер закрепляет IP из области за каждым клиентом навсегда. Срок аренды не ограничен.
Динамическое распределение (dynamic allocation). DHCP-сервер назначает адрес из области на определенное время, называемое сроком аренды. Такой подход полезен, если число доступных IP ограничено. IP назначается каждому клиенту при подключении к сети и возвращается в область, как только клиент его освобождает. В таком случае IP может отличаться при каждом подключении, но обычно назначается прежний.
Особые DHCP сообщения
Кроме DORA — четырех сообщений для получения адреса — DHCP использует и другие. Давайте рассмотрим каждое.
DHCPNAK. Нередко в источниках можно встретить написание DHCPNACK, что является неправильным, так как RFC 2131 регламентирует именно NAK. DHCPNAK отправляется сервером вместо окончательного подтверждения. Такой отказ может быть отправлен клиенту, если аренда запрашиваемого IP истекла или клиент перешел в новую подсеть.
DHCPRELEASE. Клиент отправляет это сообщение, чтобы уведомить сервер об освобождении занимаемого IP. Иными словами, это досрочное окончание аренды.
DHCPINFORM. Этим сообщением клиент запрашивает у сервера локальные настройки. Отправляется, когда клиент уже получил IP, но для правильной работы ему требуется конфигурация сети. Сервер информирует клиента ответным сообщением с указанием всех запрошенных опций.
Опции DHCP
Для работы в сети клиенту требуется не только IP, но и другие параметры DHCP — например, маска подсети, шлюз по умолчанию и адрес сервера. Опции представляют собой пронумерованные пункты, строки данных, которые содержат необходимые клиенту сервера параметры конфигурации. Дадим описания некоторым опциям:
Option 82 — ретрансляция DHCP-сервера
Option 82 — информация об агенте ретрансляции (relay agent information). Благодаря ретранслятору клиент и сервер могут общаться, находясь в разных подсетях. По умолчанию широковещательные сообщения не могут выходить за пределы текущего широковещательного домена (подсети). Внимательный читатель скажет, что выше мы писали, как клиент отправляет широковещательное сообщение DHCPDISCOVER всем доступным DHCP-серверам. А что если в сети нет DHCP?
Предположим, широковещательные сообщения не выходят за пределы подсети компании, которая не установила DHCP-сервер. В таком случае сообщение DHCPDISCOVER должно будет пропасть, и ни один компьютер компании не сможет выйти в интернет. Однако в реальности отсутствие DHCP-сервера не мешает выходу в сеть.
Значит ли это, что широковещательные сообщения каким-то образом выходят за пределы подсети? Не совсем. За пределы подсети выходят только широковещательные DHCP-сообщения. Это становится возможным благодаря агенту ретрансляции. Обычно в его роли выступает маршрутизатор или сервер. Ретранслятор получает сообщения от клиента в своей подсети, направляют его на DHCP-сервер, который тем же образом — через ретранслятор — отправляет ответ. Так ретранслятор выступает в качестве посредника между подсетями.
Опции DHCP для загрузки PXE
Протокол DHCP позволяет загрузку компьютера без использования носителя данных. Такая загрузка происходит с сетевой карты и называется PXE (Preboot eXecution Environment). Для конфигурации сетевой загрузки LEGACY BIOS PXE используются DHCP-опции 43, 60, 66 и 67.
Взаимодействие DHCP и DNS
Как мы упоминали выше, Option 6 — это сервер DNS. Давайте рассмотрим подробнее взаимодействие двух протоколов.
DNS (система доменных имен) отвечает за соответствие доменных имен и IP-адресов. Доменное имя — это не только адрес в интернете, например, selectel.ru, но также имя компьютера в локальной сети, например, Director PC. DNS проводит соединительную линию между IP и буквенно-числовым доменным именем компьютера или веб-сайта. DHCP занимается выделением и назначением IP из области. Очевидно, что два протокола должны тесно взаимодействовать между собой.
В статье мы уже говорили, что DHCP-сервер имеет область IP-адресов, которые допускается распределять между клиентами в сети. DNS-сервер занимается тем, что сопоставляет IP-адреса и доменные имена. Это не только имена сайтов, но и имена компьютеров в сети, (например, NetworkServer PC).
Если вы хотите создать свою локальную сеть на базе Linux, потому что это бесплатно и вы не хотите связываться Windows, то вы можете столкнуться с проблемой взаимодействия DNS и DHCP. Linux не имеет Active Directory, как в Windows, позволяющей тесно связать DHCP и DNS, избегая необходимости обращаться к клиенту каждый раз по IP. Однако способы организовать такую связь существуют и для свободной системы.
Первый вариант — настроить DHCP-сервер так, чтобы фиксировал адрес за клиентом. Второй вариант — настроить взаимодействие DHCP- и DNS- серверов. Первый вариант подходит, если область IP-адресов широкая и вы можете позволить себе фиксировать IP за каждым клиентом. Если же для вас такой метод будет расточительным, то необходимо дать двум серверам работать вместе.
Взаимодействие DHCP и DNS необходимо для того, чтобы DNS-сервер вовремя получал информацию о новом IP клиента и мог сопоставить его с именем клиента в сети. Если сервера не будет взаимодействовать, это чревато ошибками и недоступностью клиентов.
Настроить данное взаимодействие можно в четыре шага при помощи пакета dnsmasq, доступного в стандартных репозиториях Ubuntu и Debian. Мы не будем давать детальную инструкцию по осуществлению, а лишь кратко опишем каждый шаг.
Шаг 1 — конфигурация сети
В первую очередь необходимо определиться с компьютером, который будет выполнять роль сервера. Важно выбрать тот компьютер (Ubuntu Server или Ubuntu Desktop), который вы не планируете выключать слишком часто. Если после полной настройки вы решите выключить компьютер, то вся сеть тоже выключится.
Выбранному компьютеру необходимо назначить статический IP. Делается это редактированием конфигурационного файла в директории /etc/network/interfaces.
Шаг 2 — установка dnsmasq
Установите пакет dnsmasq командой из терминала:
А затем откройте файл конфигурации /etc/dnsmasq.conf. Файл конфигурации dnsmasq очень большой, но он содержит комментарии с объяснениями того, за что отвечает каждая настройка. Чтобы добавить требуемые настройки, откройте файл и удалите решетку (#), означающую комментарий, в начале нужных строк.
Шаг 3 — настройка фаервола
Для изменения настроек фаервола можно использовать Ubuntu Uncomplicated Firewall. Используйте следующие команды:
Шаг 4 — изменение настроек роутера
Зайдите в настройки вашего роутера из браузера, отключите DHCP для локальной сети, измените все настройки DNS так, чтобы они указывали на ваш только что настроенный сервер. Последнее действие — перезапуск сети на сервере. Для этого вы можете просто перезагрузить компьютер или использовать команды:
Недостатки протокола DHCP
DHCP имеет свои уязвимости. Основная заключается в четырех шагах, необходимых для получения IP. Процесс DORA подразумевает рассылку сообщений широковещательного типа, когда первый откликнувшийся DHCP-сервер получает возможность предложить IP из своей области. Если злоумышленник сможет использовать свой сервер, который даст самый быстрый ответ клиенту, то у него откроется возможность получить контроль над действиями пользователя в сети и нанести существенный ущерб.
Еще одна брешь в безопасности — в том, что DHCP использует UDP-протокол. UDP — протокол обмена датаграммами без установления соединения, а значит, и без шифрования. Передаваемая по UDP информация не защищена и может быть «подслушана», что также может быть использовано злоумышленниками.
Третий недостаток — вновь ненадежность UDP, но другого рода. UDP не обеспечивает гарантию доставки информации. Этот протокол допускает потери и ошибки, которые могут сказаться и на работе DHCP, в частности при PXE-загрузке.
Заключение
Мы рассмотрели основные принципы работы DHCP-серверов. Несмотря на недостатки и частые доработки, протокол DHCP широко используется в современных сетях. Также изучили процесс DORA, основные опции и другие аспекты протокола. Надеемся, эта статья оказалась вам полезна.
Тренинг Cisco 200-125 CCNA v3.0. День 26. DNS и DHCP
Система распределения доменных имен DNS и протокол динамической настройки узла DHCP являются очень важными для сетей, особенно для сети Интернет, так как позволяют настроить доступ к интернету, сконфигурировать браузер и т.д. На предыдущих уроках мы уже рассматривали настройку DHCP-сервера, так что не будем терять время и приступим к уроку.
Сегодня мы рассмотрим три темы: работу DNS, настройку DNS и проблемы, которые могут встретиться при использовании этой системы, а также настройку и проблемы DHCP. Перед тем, как двинуться дальше, мы должны рассмотреть несколько вещей. Они не являются частью тематики курса CCNA, но нужны для понимания базовых понятий того, как осуществляется хостинг нового веб-сайта. Если вас интересует создание сайтов, вы хотите узнать о HTML, CSS, PHP, Java-script, хочу сказать, что я собираюсь сделать новую серию видеоуроков о том, как создавать сайты. Однако учитывая, что я занимаюсь этим в свободное от основной работы время, эта серия выйдет ещё не скоро. Пока же я хочу рассказать о некоторых основах сайтостроительства, касающихся не столько разработки сайтов, сколько хостинга и сетевого обеспечения работы веб-страниц.
Если кто-то наберет в поисковике своего браузера imran.com, вы должны подсказать его компьютеру, где именно находится сайт с данным именем, чтобы он мог найти в интернете запрашиваемые HTML-файлы и открыть в браузере нужную страницу.
Предположим, слева у нас имеется доменное имя сайта www.imran.com, а справа в прямоугольнике расположен хост 74.1.1.10, на котором хранятся файлы этого сайта. Внизу я нарисую компьютер, браузер которого обращается к имени сайта www. imran.com. Поскольку компьютер не знает, где именно расположены файлы этого сайта, должен быть механизм, который поможет ему их найти. Этот механизм помогает компьютеру отослать запрос на хостинг, а хостинг по этому запросу отсылает файлы, которые отображаются в браузере на экране компьютера.
Технически вы можете вместо www.imran.com набрать в строке браузера IP-адрес хоста 74.1.1.10, и все будет работать точно также – вы сможете получить любые нужные вам файлы. Однако запомнить подобный адрес сайта очень трудно, вот почему создаются доменные имена. Предположим, что завтра хостинг поднял свои цены, и пользоваться хостом 74.1.1.10 для хранения файлов моего сайта стало очень дорого. В этом случае я нахожу более дешевый хостинг и загружаю свой сайт туда, при этом доменное имя сайта не меняется – я отвязываю домен от старого хоста и прилинковываю его к новому хосту 58.1.1.10.
Теперь компьютер точно также может получать HTML-файлы с нового хоста, если в строке браузера будет значиться доменное имя imran.com. Таким образом, пользователю нужно всего лишь помнить доменное имя и не думать о том, на каком хосте расположены файлы самого сайта. Вот в чем состоит причина, по которой мы используем доменные имена и хосты. Напомню ещё раз – эти понятия не входят в тематику курса CCNA, и если вы захотите узнать больше о хостинге и сайтах, то должны будете посмотреть другие серии видеоуроков.
Давайте перейдём к DNS. Это система, которая конвертирует доменные имена в IP-адреса. Как я сказал, доменное имя вида www.imran.com намного легче запомнить, чем набор чисел IP-адреса. Поэтому нужен механизм для перевода доменного имени в IP-адрес хоста, на котором хранятся файлы данного сайта. Сейчас я кое-что вам покажу. Вот командная строка, в которой я наберу команду ping google.com.
Вы видите, что рядом с доменным именем система показывает IP-адрес хоста. Если я наберу этот адрес в строке браузера и нажму ввод, то попаду на сайт google.com. При этом в адресной строке браузера отобразится именно доменное имя сайта, а не его IP-адрес. Технически браузеру все равно, какого вида адрес набирать, однако как я уже сказал, если вы запомните IP-адрес хоста какого-то ресурса, а его владелец перенесет сайт на другой хостинг, вы не сможете найти искомый ресурс. Потому что если моим сайтом пользуется 10000 людей, я не смогу сообщить всем, что сайт переехал на новый хост и его IP-адрес изменился. Так что лучшим способом будет запоминание доменного имени, ведь изменение адреса хоста будет проходить автоматически и никак не отразится на имени сайта.
Существует два типа DNS-серверов: приватный, или внутренний, и публичный, или внешний. В первом случае у нас может быть сеть из 100 компьютеров, которые нуждаются в локальном доменном имени. Например, для использования файлового сервера компании, который расположен на хосте с неким IP-адресом, вам не нужно будет набирать и помнить этот адрес, если вы будете пользоваться простым доменным именем fileserver. При этом администратор сети может поменять IP-адрес файлового сервера в любое время, и это никак не отразится на пользователях локальной сети.
Аналогично можно использовать публичный DNS-сервер, или DNS-резольвер. Если вы набираете в адресной строке браузера imran.com, ваш компьютер не знает, что это за имя и где его можно найти, поэтому обращается к DNS-серверу. В сетевых настройках Windows имеется возможность указать первичный, предпочитаемый и вторичный, альтернативный DNS-сервер.
Этот процесс может происходить автоматически при помощи ISP – вашего сетевого провайдера. Если вы вводите доменное имя imran.com, ваш компьютер обращается к DNS-серверу. Если предпочитаемый сервер, IP-адрес которого вы внесли вручную, будет недоступен по каким-то причинам, компьютер обратиться к альтернативному DNS-серверу. Это не означает, что если первичный сервер ничего не знает о доменном имени imran.com, он перешлет запрос вторичному серверу. Если набранное вами доменное имя не существует в сети, то есть первичный сервер о нем ничего не знает, он просто отбросит неверный запрос. Но если предпочитаемый DNS-сервер просто недоступен по техническим причинам, вас переадресует к альтернативному серверу.
Сейчас я покажу, как это работает. Я нарисую ваш компьютер, который связан с DNS- резольвером. Обычно как только вы набираете imran.com, ваш компьютер, вернее, его браузер, проверяет собственный кеш. Если компьютер имел ранее доступ к данному сайту, его IP-адрес сохранился в кеше. Если это первое обращение к сайту, запрос поступает к резольверу, который тоже в первую очередь проверяет свой кеш. Если там нет никакой информации, резольвер обращается к root-серверу. По всему миру раскиданы десятки корневых DNS – серверов, и если вы выходите в интернет из Индии, то связываетесь с индийским root-сервером, если из США, то попадаете на ближайший к вам американский корневой сервер. Эти сервера имеют anycast IP-адреса.
Домен верхнего уровня отвечает: «я не знаю, где находится imran.com, но знаю, где находится авторитарный сервер имен Authoritative Nameserver для imran.com», и отправляет свой ответ резольверу.
После этого DNS-резольвер направляет запрос авторитарному серверу, и тот наконец отвечает резольверу: «imran.com находится по адресу 74.1.0.1».
После этого резольвер сохраняет этот IP-адрес в своем кеше и сообщает его компьютеру. Наконец, компьютер обращается напрямую к серверу 74.1.0.1, и тот отсылает браузеру нужный HTML-файл. Вы можете подумать, что это довольно длительный процесс, но в реальности обращение ко всем этим серверам и получение ответов занимает меньше секунды.
Существует очень популярный публичный резольвер, которым пользуются все – это Google DNS, который имеет IP-адрес 8.8.8.8. Google имеет множество резольверов, которые хранят в своих кешах огромное количество адресов самых разных ресурсов, поэтому обращение к Google и получение ответа происходит намного быстрее. А теперь давайте перейдем к рассмотрению DHCP.
Далее необходимо указать default router, который представляет собой IP-адрес шлюза по умолчанию, и указать сам DNS –сервер, обозначив его IP-адрес. Например, если в качестве DNS-сервера указать адрес 8.8.8.8, то DHCP сообщит этот адрес всем клиентам пула.
Приведу пример, как можно реализовать данный запрет. В этом случае задается диапазон IP-адресов, которые DHCP-сервер не должен присваивать клиентам. Я покажу вам этот процесс в программе Packet Tracer. Вы видите топологию сети, в которой первый роутер играет роль DHCP-сервера.
В левой части расположена сеть 192.168.1.0, в состав которой входят два компьютера, свитч, веб-сервер и DNS-сервер. Компьютеры выступают в качестве клиентов, которые автоматически получают адреса из пула DHCP. Я настрою DNS-сервер таким образом, что каждый раз, когда клиенты обращаются к сайту google.com или cisco.com, они будут отсылать запрос веб-серверу, который будет снабжать их запрашиваемой информацией. Это первое, что необходимо сделать.
Затем я должен перейти к DHCP-серверу, справа от которого размещены еще две сети: сеть 192.168.2.0, которая связывает его с Router1, и сеть 192.168.3.0, в которой расположен свитч и компьютер PC2. Этот компьютер тоже должен иметь возможность обратиться к DHCP-серверу. Однако DHCP-запрос является широковещательным, а как мы знаем, роутер не воспринимает broadcast-запрос и отбрасывает его. Поэтому нам нужно настроить Router1 так, чтобы он служил передатчиком DHCP-запросов компьютера PC2 DHCP-серверу. Получив такой запрос, сервер должен предоставить третьему компьютеру IP-адрес, однако этот адрес не должен принадлежать диапазону адресов сети 192.168.1.0, так как компьютер PC2 находится в сети 192.168.3.0. Поэтому PC2 должен получить IP-адрес из диапазона адресов сети 192.168.3.0.
Таким образом, нам нужен механизм, позволяющий создавать несколько пулов для работы с устройствами, расположенными в разных подсетях. Для организации работы DHCP-сервера с несколькими подсетями нужно зайти в настройки роутера и присвоить его интерфейсам IP-адреса, которые я обозначил на схеме.
Сначала я вхожу в глобальный режим настроек и ввожу команду hostname DHCP_server, после чего присваиваю интерфейсу f0/0 IP-адрес командой ip address 192.168.1.1 255.255.255.0 и добавляю команду no shutdown. Интерфейсу f0/1 присваивается адрес 192.168.2.1.
Теперь создадим пул IP-адресов. Для этого используется команда ip dhcp pool, в которой нужно указать название пула, чтобы затем перейти в режим подкоманд созданного пула, указать диапазон свободных IP-адресов пула и пассивный сервер DHCP-relay.
Итак, я создаю пул под названием NET1 с помощью команды ip dhcp pool NET1, нажимаю «Ввод» и перехожу к подкомандам. Система выдает подсказку, какие параметры можно настроить.
Можно указать роутер по умолчанию default-router, имя DNS-сервера dns-server, команда exit позволяет выйти из настроек DHCP-пула, параметр network позволяет указать номер сети и маску, команда no отменяет все изменения и сбрасывает к настройкам по умолчанию, а option позволяет указать функции Raw DHCP.
Начнем с того, что укажем роутер по умолчанию, то есть укажем IP-адрес 192.168.1.1. Это означает, что если компьютер PC0 или PC1 захочет получить IP-адрес, он должен будет обратиться к шлюзу, который имеет этот адрес. Этот параметр вводится командой default-router 192.168.1.1. Далее нужно указать, для какой сети настроен данный пул. Для этого используется команда network 192.168.1.0 255.255.255.0.
Теперь нужно указать DNS-сервер, который на нашей схеме имеет IP-адрес 192.168.1.2. Для этого я ввожу команду dns-server 192.168.1.2 без указания маски подсети.
Закончив настройку DHCP-сервера, перейдем к настройке DNS-сервера. Для этого я щелкаю по иконке этого устройства и захожу на вкладку IP configuration. В данном случае используется статический IP-адрес 192.168.1.2, адрес шлюза по умолчанию 192.168.1.1, а в качестве DNS-сервера устройство указывает само себя, то есть IP-адрес 192.168.1.2.
Теперь можно перейти к настройкам веб-сервера. Я точно также захожу в настройки IP и ввожу нужные параметры.
Мне также необходимо провести некоторую дополнительную настройку веб-сервера, но можете не волноваться, настройка таких серверов не входит в тематику курса CCNA, я просто должен это сделать, чтобы продолжить работать с примером нашей сети. Я просто хочу показать, что на вкладке «Службы» расположен HTML-файл, который я заранее сюда поместил. После того, как веб-сервер получит запрос компьютера, он отошлет ему этот файл. Я снова перехожу к настройкам DNS-сервера, открываю вкладку «Службы» и включаю DNS-службу. Затем я создаю запись DNS-сервиса: в поле Name я ввожу имя сайта, к которому обращается клиент – www.nwking.org, а в следующей строке Address ввожу IP-адрес веб-сервера, на котором хранится этот сайт – 192.168.1.3.
После этого я нажимаю на кнопку Add (Добавить), и у нас появляется запись о том, как можно добраться к ресурсу nwking.org. В данном случае эта запись просто конвертирует имя сайта в IP-адрес. Существует возможность её изменить, но я не буду останавливаться на этом, так как настройка DNS-сервера не входит в тематику вашего курса CCNA. Я просто показал, как настраивается хостинг веб-сайта.
Теперь я перейду к компьютеру PC0 и настрою DHCP. Для этого я отправлю запрос, и как видите, DHCP тут же автоматически ответит компьютеру, заполнив строки информацией. Таким образом PC0 получит свой IP-адрес 192.168.1.4
Перейдем к компьютеру PC1 и проделаем то же самое. Мы видим, что сервер присвоил ему следующий доступный IP-адрес 192.168.1.12, шлюз по умолчанию имеет адрес 192.168.1.1, а DNS-сервер — 192.168.1.2.
Теперь я зайду в настройки компьютера PC0 и перейду на вкладку Web Browser, затем наберу в адресной строке www.nwking.org и кликну кнопку Go. После этого браузер покажет мне страницу сайта, вернее, тот файл, который я разместил в качестве сайта на веб-сервере. При этом произошло следующее: компьютер отослал запрос DNS-серверу, тот сообщил, что если вы ищите данный сайт, то он доступен на устройстве с IP-адресом 192.168.1.3, после чего компьютер PC0 напрямую обратился к веб-серверу и получил от него нужную информацию.
Сейчас я отключу DNS-сервер, удалив кабель, который связывает его со свитчем. Если я снова попробую вызвать данный сайт с компьютера PC0, он должен снова открыть его в браузере, потому что данные сохранены в кеше. Я ввожу адрес www.nwking.org и нажимаю Go, однако ничего не происходит. Это странно, потому что информация о доступе к сайту должна была остаться в кеше браузера.
Я проделаю то же самое с PC1, и как видите, нажатие на кнопку Go не приводит ни к какому результату. Позвольте мне снова подключить DNS-сервер к свитчу и еще раз запустить браузер компьютера PC0. Технически, если информация о сайте сохранилась в кеше браузера, вам не нужна связь с DNS-сервером, чтобы получить доступ к этому сайту, потому что компьютер автоматически обратится напрямую к веб-серверу.
Я думаю, что нам это не удалось из-за того, что используются не физические устройства, а программа Packet Tracer. Сейчас я снова отсоединю DNS-сервер и повторю запрос сайта с компьютера PC0. На этот раз все получилось – сайт отображается в браузере при отключенном DNS-сервере, потому что PC0 использовал данные кеша. Однако кеш браузера компьютера PC1 пуст, поэтому при вводе адреса сайта www.nwking.org ничего не происходит – этот компьютер обращается к DNS-серверу, но попытка заканчивается неудачей. Думаю, вы поняли, как это работает, так что присоединю DNS-сервер обратно к свитчу.
Обратимся снова к нашему DHCP-серверу и организуем пул для второй сети, в которой находится компьютер PC2, я назову эту сеть NET2. Для этого я последовательно ввожу команды ip dhcp pool NET2 и network 192.168.3.0 255.255.255.0. Затем я ввожу IP-адрес DNS-сервера, общий для обеих сетей — 192.168.1.2 и назначаю роутер по умолчанию. Поскольку дело касается сети 3.0, в качестве default router я указываю второй роутер Router1 с IP-адресом 192.168.3.2.
Еще нам нужно настроить сеть между двумя роутерами, поэтому я захожу в настройки Router1 и присваиваю его интерфейсам f0/0 и f0/1 соответствующие IP-адреса 192.168.2.2 и 192.168.3.2.
Сейчас, если я зайду в IP-настройки PC2 и включу режим DHCP, этот компьютер обратиться с запросом к Router1. Поскольку роутер не является DHCP-сервером, система выдаст сообщение, что запрос потерпел неудачу и будет использована служба APIPA, которая автоматически присваивает устройствам IP-адреса, если в сети нет DHCP-сервера.
В данном случае APIPA назначила компьютеру случайный IP-адрес 169.254.133.157. Это нормально и мы знаем, почему так произошло. Однако нам нужно, чтобы Router1, получив запрос на IP-адрес, отправил его по сети дальше к DHCP-серверу, то есть нам нужно, чтобы этот роутер выполнял роль пассивного сервера DHCP-relay. Перед тем, как заняться его настройкой, вернемся к первому роутеру DHCP-server и включим функцию RIP-маршрутизации.
Затем перейдем ко второму роутеру Router1 и выполним аналогичные настройки, чтобы оба эти устройства могли связываться по протоколу RIP.
Теперь нужно настроить внешний интерфейс f0/1, указав для него вспомогательный адрес helper-address. Команда helper-address служит для пересылки широковещательного DHCP-запроса на указанный адрес, в нашем случае это 192.168.2.1.
Теперь любой DHCP-запрос компьютера PC2 будет автоматически пересылаться DHCP-серверу. Попробуем еще раз включить DHCP, и непонятно почему, но наш компьютер снова использует APIPA – запрос с DHCP-серверу остался без ответа.
Попробуем разобраться с проблемой, для этого я захожу в настройки Router1 и ввожу команду ping 192.168.2.1. Пинг не проходит, поэтому я по-быстрому проверю интерфейсы DHCP-сервера, используя команду show ip int brief, и обнаруживаю ошибку. Да, я бы не сдал экзамен с такими знаниями! Поэтому, ребята, нужно практиковаться, чтобы не делать подобных ошибок. Сейчас я её исправлю.
Я забыл использовать в настройках DHCP-сервера важную команду, и сейчас введу её для интерфейса f0/1: ip add 192.168.2.1 255.255.255.0. Это просто досадная ошибка, которую я исправил. Теперь снова заходим в настройки PC2 и включаем DHCP. Что, опять? Запрос снова не проходит!
Я снова проверяю настройки Router1. C таблицей маршрутизации все в порядке, все нужные записи присутствуют, в чем же проблема? Вспомогательный адрес тоже назначен правильно. Ну ничего, в конце концов я найду причину.
Я снова возвращаюсь к настройкам DHCP-сервера и ввожу команду show ip route. Выясняется, что маршрута не существует, потому что я не указал версию протокола. Я исправляю эту ошибку, и теперь все должно заработать.
Я возвращаюсь к PC2 и снова включаю DHCP – теперь все нормально, компьютер получает IP-адрес 192.168.3.6, присвоенный ему DHCP-сервером. Из-за своей невнимательности я допустил ошибку и потратил время на её поиск, так что прошу меня простить.
Сейчас, если зайти в браузер третьего компьютера и ввести в строке www.nwking.org, запрос отправится к авторитарному серверу Nameserver и будет возвращен с примечанием, что компьютер должен обратиться с этим запросом к веб-серверу 192.168.1.3. После этого PC2 направит запрос по указанному адресу и получит запрашиваемый HTML-файл.
Вот таким образом работает пассивный сервер DHCP-relay, который использует helper-address. Как видите, все очень просто и понимание изложенной темы не должно представлять для вас особых сложностей. Владение основами DNS и DHCP очень важно для подключения ваших компьютеров к сети.
Как я уже говорил, мы приближаемся к концу тематики, необходимой для сдачи первого экзамена CCNA, нам осталось еще несколько важных видеоуроков, в частности, ASL, NAT и PAT. Прошу не беспокоиться по поводу несовместимости видеоуроков старой и новой версий CCNA – я своевременно добавляю новые серии и удаляю не нужные, так что вы будете изучать только актуальные темы.