0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Могу ли я иметь несколько DHCP-серверов в одной сети

Содержание

Могу ли я иметь несколько DHCP-серверов в одной сети?

Можно ли иметь более одного DHCP-сервера в одной локальной сети? Каковы последствия этого?

  1. Что произойдет, если доступно более одного DHCP-сервера? Как мои клиенты знают, какой использовать?
  2. Как я могу иметь серверы DHCP, предоставляющие адреса более чем одной подсети сегменту сети?
  3. Как настроить несколько серверов DHCP для предоставления адресов для одной подсети.

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

DHCP в простой сети работает по принципу DORA.

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

Предложение — правильно настроенный DHCP-сервер получает запрос от клиента и предлагает ему адрес из своего пула доступных адресов.

Запрос — клиент отвечает на предложение, запрашивая адрес, полученный в предложении.

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

Любое устройство в сегменте сети может быть сервером DHCP; это не обязательно должен быть маршрутизатор, контроллер домена или любое другое «специальное» устройство в сети.

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

Несколько DHCP-серверов PT 1: охват нескольких подсетей.

Если у вас есть несколько VLAN или сегментов физической сети, которые разделены на разные подсети, и вы хотите предоставить службу DHCP для устройств во всех этих подсетях, то есть два способа сделать это.

Если коммутатор маршрутизатора / уровня 3, разделяющий их, может действовать как агент ретрансляции BOOTP / DHCP, то вы можете продолжать хранить все свои серверы DHCP в одной или двух центральных частях вашей сети и настроить свой сервер (ы) DHCP на поддержка нескольких диапазонов адресов. Для поддержки этого ваш маршрутизатор или коммутатор уровня 3 должен поддерживать спецификацию агента ретрансляции BOOTP, описанную в разделе 4 RFC 1542 .

Если ваш маршрутизатор не поддерживает ретрансляторы RFC 1542 BOOTP, или если некоторые из ваших сегментов сети географически распределены по медленным каналам связи, вам потребуется разместить один или несколько серверов DHCP в каждой подсети. Этот «локальный» DHCP-сервер будет обслуживать только требования своего локального сегмента, и между ним и другими DHCP-серверами нет взаимодействия. Если это именно то, что вам нужно, вы можете просто настроить каждый DHCP-сервер как автономный сервер с подробной информацией о пуле адресов для своей подсети и не беспокоиться о других DHCP-серверах в других частях сети. Это самый простой пример наличия более одного DHCP-сервера в одной сети.

Несколько DHCP-серверов PT 2: DHCP-серверы, которые обслуживают один и тот же сегмент сети.

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

Это вполне возможно, хотя требует некоторого обдумывания и планирования.

С точки зрения «сетевого трафика» процесс DORA, описанный в начале этого ответа, объясняет, как более одного DHCP-сервера может присутствовать в сегменте сети; клиент просто передает запрос на обнаружение, и первым DHCP-сервером, ответившим на предложение, является «победитель».

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

Другими словами, если у вас есть диапазон адресов DHCP для выдачи клиентам от 192.168.1.100 до 192.168.1.200, тогда оба сервера должны быть настроены для обслуживания отдельных частей этого диапазона, поэтому первый сервер может использовать части этой области из С 192.168.1.100 по 192.168.1.150, и второй сервер затем выдаст с 192.168.1.151 по 192.168.1.200.

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

Разделение области — лучшая практика

Одна из лучших рекомендаций, о которых вы услышите, — это правило 80/20 для разделения области DHCP, что означает, что один сервер будет обслуживать 80% адресов в этой области, а другой — DHCP-сервер, который фактически находится «в резерве». будет обслуживать 20% адресов.

Идея разделения адресов 80/20 заключается в том, что 80% доступных адресов, как мы надеемся, должны быть достаточными для всех адресов, необходимых в подсети, и аренды DHCP обычно выдаются на несколько дней; поэтому, если ваш основной DHCP-сервер отключается в течение нескольких часов, маловероятно, что более 20% компьютеров в этой подсети будут вынуждены обновлять свои адреса во время простоя, что делает пул адресов в 20% достаточным.

Это все еще разумный совет, но он предполагает две вещи:

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

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

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

Объединяя эти идеи

Наконец, стоит помнить, что вы можете объединить принципы, рассмотренные выше — вы можете разместить все свои DHCP-серверы в одной или нескольких VLAN «центрального сервера» и использовать ретрансляторы BOOTP на всех ваших маршрутизаторах для отправки всех DHCP-запросов из очень больших и сегментированных сеть к централизованной службе DHCP (что я и делаю, см. ниже). Или вы можете иметь DHCP-серверы, распределенные по вашей сети, с «основным» DHCP-сервером в локальной подсети и «резервным» DHCP-сервером в «соседнем» сегменте сети, предоставляющем небольшое количество адресов в качестве резервной копии — вы даже можете иметь два DHCP-сервера в своих сегментах сети, настроенные для обеспечения диапазона адресов 80/20 друг для друга. Наиболее разумный выбор будет зависеть от того, как ваши физические и логические сети отображаются друг на друга.

Конфигурирование DHCP

Пусть IP-адреса присваивает DHCP Настроить сервис Windows NT под названием Dynamic Host Configuration Protocol (DHCP) не так уж сложно, как это может показаться. Если вы назначаете IP-адреса вручную, потому

Пусть IP-адреса присваивает DHCP

Настроить сервис Windows NT под названием Dynamic Host Configuration Protocol (DHCP) не так уж сложно, как это может показаться. Если вы назначаете IP-адреса вручную, потому что освоение DHCP вам кажется делом слишком трудным, то поверьте, что потратив всего пару часов на изучение этого сервиса, вы сумеете сэкономить массу своего рабочего времени.

Что такое DHCP?

DHCP — это протокол TCP/IP, автоматизирующий присвоение IP-адресов. (Название «автоматическое присвоение IP-адресов», Automatic IP Address Assignment, может, и лучше отражает суть, но AIAA больше похоже не на сокращение, а на вопль, издаваемый сетевым администратором от безысходности). Для использования протокола TCP/IP в сети администратор должен задать для каждого из компьютеров по меньшей мере три параметра — IP-адрес, маску подсети и адрес используемого по умолчанию шлюза. При этом каждый компьютер должен иметь уникальный IP-адрес. Кроме того, присвоенный адрес должен находиться в диапазоне подсети, к которой подключено устройство. В большой сети иногда бывает трудно определить, к какой же из подсетей подключен тот или иной компьютер. Однако DHCP «знает», из какой подсети приходит запрос на получение IP-адреса, и сделает за вас все как надо. Если в сети используются Windows Internet Naming Service (WINS) и Domain Name Service (DNS), то на каждом из клиентских компьютеров администратору необходимо также указать IP-адреса WINS и DNS-серверов.

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

Установка сервиса DHCP

Как и другие сервисы NT, DHCP работает в фоновом режиме. DHCP надо устанавливать на сервер, но администрировать можно и с рабочей станции. Серверы DHCP должны иметь фиксированные (статические) IP-адреса, потому что они не могут присваивать адреса сами себе. На роль DHCP-сервера хорошо подойдет, например, запасной контроллер доменов (Backup Domain Controller). Чтобы установить сервис DHCP, дважды щелкните на пиктограмму Network в Control Panel. (Можно также щелкнуть правой клавишей мыши на пиктограмму Network Neighborhood и выбрать Properties). Выберите ярлык Services, нажмите Add. Из списка Network Services выберите Microsoft DHCP Server и нажмите Ok. Затем перезагрузите сервер.

Конфигурирование DHCP-сервера

После установки необходимо сконфигурировать сервер. Запустите DHCP Manager, находящийся в группе Administrative Tools. На экране 1 показан открывающийся при этом диалог.

Экран1:
Диалог DHCP Manager

Главный компонент настройки DHCP — диапазон IP-адресов (scope). Каждой подсети соответствует один диапазон. Допустим, вам доступны адреса с 10.0.0.2 по 10.0.0.100. Однако компоненты вашей сети (принтеры, маршрутизаторы, DHCP-сервер) разбросаны внутри этого диапазона; к примеру, адрес принтера — 10.0.0.57. Указывать в качестве одного из диапазонов 10.0.02-10.0.0.56, а в качестве второго — 10.0.0.58-10.0.0.100 не нужно. Вместо этого DHCP позволяет указать IP-адреса или диапазоны адресов, которые DHCP-сервер присваивать не должен.

Экран2:
Задание и настройка диапазона адресов DHCP-сервера

В меню DHCP Manager выберите Scope, Create. На рис. 2 показан открывающийся при этом диалог Create Scope. Вам необходимо ввести первый и последний адреса диапазона и маску подсети. Затем введите адреса, которые следует исключить из диапазона. При этом можно вводить как одиночные адреса (например, принтеров и других компонентов сети, не поддерживающих DHCP), так и их диапазоны. Наконец, укажите срок аренды (lease). О нем я расскажу позже. Можно также присвоить диапазону имя и ввести комментарий. Эти возможности предусмотрены для случаев, когда подсетей достаточной много.

После нажатия Ok и закрытия диалога Create Scope необходимо указать, желаете ли вы немедленно активизировать диапазон. Как правило, это можно сделать сразу. Но если количество диапазонов велико, их все можно сначала задать, а потом одновременно активизировать.

При выходе из диалога Create Scope возможно появление сообщения об ошибке No more data is available. Его можно проигнорировать. Созданный диапазон появится в окне DHCP Manager. Если вы его активизировали, изображенная справа от него лампочка будет гореть желтым цветом. Не волнуйтесь, если вы ввели диапазон 131.107.2.100-131.107.2.199, а в окне DHCP Manager появилось 131.107.2.0. Просто DHCP показывает последние восемь адресов, как ноль.

Казалось бы, для избыточности неплохо было бы иметь несколько серверов, обслуживающих одни и те же диапазоны адресов. Однако в NT 4.0 DHCP-серверы не взаимодействуют друг с другом. Другими словами, создать несколько серверов для одного и того же диапазона нельзя, поскольку они будут назначать одни и те же адреса. Надеюсь, в будущих версиях этот недостаток будет устранен. Иногда администратор сети с двумя серверами, каждый из которых обслуживает ее часть, может поделить между ними доступные IP-адреса. Таким образом, в случае сбоя одного из серверов по крайней мере у части пользователей сохранится возможность получения IP-адресов.

Конфигурирование клиентов TCP/IP

Сконфигурировать клиенты очень просто. После установки TCP/IP на клиентскую машину необходимо ввести способ задания IP-адресов. Вам нужно поставить метку в окошке напротив надписи, указывающей, что назначением IP-адресов должен заниматься DHCP-сервер. Если вы хотите узнать, какой адрес был получен клиентом, наберите в командной строке NT ipconfig /all. В ответ будет выведен IP-адрес клиента, IP-адрес DHCP-сервера, а также адреса серверов WINS и DNS. Если вам нужен только IP-адрес клиента, наберите ipconfig. В Windows 95 и 98 можно запустить программу winipcfg.exe, которая выведет информацию об IP-адресах в графическом окне.

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

Настройка дополнительных параметров

Экран 3:
Настройка параметров WINS и DNS

При необходимости настроить WINS и DNS нужно ввести IP-адреса соответствующих серверов. В диалоге DHCP Manager выберите DHCP Options. Можно настраивать параметры отдельно для каждого диапазона, но, как правило, они задаются глобально. При наличии в сети нескольких подсетей обычно используется один-два сервера WINS и DNS. Как показано на экране 3, значения каждого параметра по умолчанию можно изменить. Выберите параметр в списке слева, нажмите Add. Во многих случаях, например для присвоения адреса WINS-сервера, придется воспользоваться функцией Edit Array. После ее активизации DHCP предоставляет необходимую информацию клиентским компьютерам. Экран 3 показывает, как настроаиваются наиболее часто используемые параметры (с использованием Add для выбора и Values для модификации). Параметр 003 — это адрес маршрутизатора или используемого по умолчанию шлюза, 006 — адрес DNS-сервера, а 044 — адрес WINS-сервера. При выборе 044 необходимо также выбрать 046 — тип узла WINS.

Срок аренды

DHCP присваивает IP-адреса на определенный срок, «сдает в аренду». По истечение половины этого срока клиент отправляет DHCP-серверу прямое сообщение с запросом о возобновлении аренды. Если сервер доступен, он ее продлевает. В противном случае клиент снова посылает запрос по истечение половины остатка интервала, и так далее. Если срок аренды 3 дня (72 часа), то клиент пытается возобновить его через 36 ч, 54 ч и 63 ч. Наконец, клиент отправляет широковещательный запрос ко всем DHCP-серверам. Если до окончания срока аренды клиент не находит сервер, компьютер утрачивает соединение с TCP/IP-сетью.

Читать еще:  Опишите порядок установки автоматического обновления программного обеспечения

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

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

Экран 4:
Просмотр сроков аренды

DHCP позволяет легко определить, какой машине какой адрес назначен. В диалоге DHCP Manager (показанном на экране 1), выберите Scope, затем Active Leases. Для получения подробной информации о сроке аренды адреса для каждой из машин, выберите ее и нажмите Properties (или два раза щелкните на имени машины). На экране 4 показан список компьютеров моей офисной сети. Уникальный идентификатор (например, 004005000001) — это MAC-адрес сетевой платы. При необходимости отключить компьютер от сети, или после того как одна из машин была из нее удалена, соответствующий срок аренды можно аннулировать.

Преимущества DHCP

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

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

Есть у DHCP преимущества и для пользователей. Пользователи ноутбуков, например, не смогут подключиться к сети, если адреса выдаются вручную. Однако клиенты, поддерживающие DHCP, по подключении сразу же получают новые действительные IP-адреса.

Кроме того, DHCP позволяет осуществлять совместное использование IP-адресов. Допустим, у вас имеется 50 свободных адресов и отдел сбыта со штатом в 100 человек. Сотрудники отдела проводят в офисе всего 1-2 дня в неделю; таким образом, одновременно к сети всегда подключены только 30-40 компьютеров. Каждый раз при подключении к сети сотрудник получает IP-адрес. После отключения система восстанавливает адрес, чтобы выдать его следующему пользователю.

Если ряд мобильных пользователей делят между собой несколько IP-адресов, некоторое их количество можно зарезервировать для тех, кому они больше всего нужны. Откройте диалог DHCP Manager, выберите Scope, Add Reservations. Таким образом вы сможете зарезервировать адрес для компьютера с определенным сетевым адаптером. Это может создать трудности, если пользователи поменяются адаптерами. Резервирование имеет свои отличия от присвоения фиксированного IP-адреса. Резервирование так же дает пользователю возможность подключаться к сети в различных отделах, но адрес в зависимости от местоположения может изменяться.

Засучите рукава

Настройка DHCP может показаться сложной, но за счет упрощения процесса администрирования вы сэкономите гораздо больше времени, чем потратите на изучение. В комплекте Service Pack 4 поддержка этого сервиса значительно улучшена.

Я знаю одну компанию, которая после внедрения DHCP перевела человека, занимавшегося исключительно управлением IP-адресами, на другую работу. Лучше тратить время на настройку ПО, чем на конфигурирование компьютеров и присвоение им IP-адресов.

Общие сведения

Протокол DHCP предоставляет хостам параметры автоматической конфигурации (например, IP-адрес с маской подсети, шлюз по умолчанию, адрес DNS-сервера и адрес WINS (Windows Internet Name Service)). Изначально у клиентов DHCP нет этих параметров конфигурации. Для получения этой информации они отправляют соответствующий широковещательный запрос. Когда сервер DHCP видит этот запрос, он предоставляет нужную информацию. Учитывая природу таких широковещательных запросов, DHCP-клиент и сервер должны находиться в пределах одной подсети. Устройства уровня 3 (маршрутизаторы и межсетевые экраны), как правило, не выполняют переадресацию этих широковещательных запросов по умолчанию.

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

Движение пакетов

На этой иллюстрации демонстрируется поток пакета DHCP, если агент ретрансляции DHCP не используется:

ASA перехватывает эти пакеты и преобразовывает их в формат ретрансляции DHCP:

Ретрансляция DHCP с перехватом пакета на внутренних и внешних интерфейсах ASA

Обратите внимание на содержимое, выделенное КРАСНЫМ, — именно так ASA изменяет поля.

    Чтобы запустить процесс DHCP, загрузите систему и отправьте широковещательное сообщение (DHCPDISCOVER) на адрес назначения 255.255.255.255 — UDP-порт 67.

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

Как правило, ASA отбрасывает широковещательное сообщение, но, поскольку эта платформа настроена как DHCP-ретранслятор, она переадресует сообщение DHCPDISCOVER в формате одноадресного пакета на IP-адрес DHCP-сервера из IP-интерфейса, который ориентирован на этот сервер. В данном случае это будет IP-адрес внешнего интерфейса. Обратите внимание на изменение IP-заголовка и поля агента ретрансляции:

Примечание. Благодаря исправлению для ошибки Cisco с идентификатором CSCuo89924, ASA 9.1(5.7), 9.3(1) и более поздних версий переадресует одноадресные пакеты на IP-адрес DHCP-сервера с IP-адреса, который ориентирован на клиент (giaddr), где активирован параметр dhcprelay. В данном случае это будет IP-адрес внутреннего интерфейса.

Сервер отправляет сообщение DHCPOFFER в формате одноадресного пакета обратно в ASA, на IP-адрес агента ретрансляции, настроенный в поле DHCPDISCOVER- UDP port 67.В данном случае это будет IP-адрес внутреннего интерфейса (giaddr), где активирован параметр dhcprelay. Обратите внимание на IP-адрес назначения в заголовке уровня 3:

ASA передает этот пакет из внутреннего интерфейса — UDP-порт 68. Обратите внимание на изменение заголовка IP-адреса в процессе отправки пакета из внутреннего интерфейса:

После вывода сообщения DHCPOFFER отправьте сообщение DHCPREQUEST, чтобы сообщить о принятии предложения.

ASA передает сообщение DHCPREQUEST на сервер DHCP.

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

ASA передает вам сообщение DHCPACK с DHCP-сервера, и транзакция завершается.

Отладка и системные журналы для транзакций ретрансляции DHCP

Это запрос DHCP, переадресованный на интерфейс DHCP-сервера 198.51.100.2:

После получения отклика от DHCP-сервера устройство безопасности переадресует его на DHCP-клиент с MAC-адресом 0050.5684.396a и изменяет адрес шлюза на адрес в собственном внутреннем интерфейсе.

Эта же транзакция отображается также и в системных журналах:

7 частых проблем с сетью и как их быстро решить

Приводим сеть в порядок

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

Дублирующиеся IP-адреса

Когда два устройства пытаются использовать один и тот же IP-адрес, вы видите страшную ошибку ”Адрес уже используется” (Address Already in Use) — без возможности доступа к сети.

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

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

Тут можно прочитать подробнее про DHCP и про его настройку

Исчерпание IP-адресов

Чтобы устранить эту проблему, используйте команду ipconfig. Если рабочая станция назначила себе IP-адрес, который начинается с 169.x.x.x, это означает, что IP-адрес не был доступен с сервера DHCP.

Быстрое исправление: у некоторых пользователей проводного интернета может не быть локального маршрутизатора, и в этом случае IP-адреса назначаются на ограниченной основе непосредственно от вашего интернет-провайдера. Возможно, у вас закончились разрешенные IP-адреса от вашего интернет-провайдера. Решением этой проблемы является покупка либо автономного маршрутизатора, либо точки доступа WiFi со встроенным маршрутизатором. Это создает ваш собственный локальный пул внутренних адресов, гарантируя, что вы не закончите.

Если у вас уже есть локальный маршрутизатор с DHCP, пул адресов по умолчанию может быть слишком мал для вашей сети. Получив доступ к настройкам DHCP на маршрутизаторе, вы можете настроить размер пула адресов в соответствии с потребностями вашей сети.

Превентивные меры: Важно, чтобы в любой сети, подключенной к Интернету, был локальный маршрутизатор, работающий с NAT и DHCP, как из соображений безопасности, так и для предотвращения исчерпания IP-адреса. Маршрутизатор должен быть единственным устройством, подключенным к модему, а все остальные устройства подключаются через маршрутизатор.

Проблемы с DNS

Ошибки, такие как “Сетевой путь не найден”(The Network Path Cannot Be Found) , “IP-адрес не найден”( IP Address Could Not Be Found) или “DNS-имя не существует”(DNS Name Does Not Exist) , обычно могут быть связаны с проблемой конфигурации DNS. Утилита командной строки nslookup может использоваться для быстрого отображения настроек DNS рабочей станции.

Быстрое исправление: рабочие станции и другие сетевые устройства можно настроить на использование своих собственных DNS-серверов, игнорируя сервер, назначенный DHCP. Проверка настроек «Протокол Интернета версии 4 (TCP/IP)» для вашего адаптера покажет, если указан неправильный DNS-сервер, поэтому просто выберите «Получить адрес DNS-сервера автоматически» .

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

Про DNS подробнее можно прочитать тут.

Один компьютер может подключиться к сети

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

Быстрое решение: чтобы решить эту проблему с сетью, начните с устранения очевидных коммуникационных барьеров, таких как плохой кабель, плохой сигнал WiFi, сбой сетевой карты или неправильные драйверы. Убедитесь, что сетевой адаптер рабочей станции настроен с использованием правильных IP-серверов, подсетей и DNS-серверов.

Если это не решает проблему, проверьте любое программное обеспечение брандмауэра на устройстве, чтобы убедиться, что необходимые порты открыты для внешней сети. Общие порты включают 80 и 443 для веб-трафика, плюс 25, 587, 465, 110 и 995 для электронной почты.

Превентивные меры: Обычно лучше оставить для всех настроек TCP/IP рабочей станции значение «Автоматически назначать». Используйте DHCP-сервер, чтобы передать единую конфигурацию всем устройствам в сети. Если на определенной рабочей станции или сервере требуется статический IP-адрес, большинство DHCP-серверов позволяют создавать статические сопоставления IP-адресов.

Невозможно подключиться к локальному файлу или принтеру

Проблемы с совместным использованием являются одними из самых сложных проблем в сети из-за количества компонентов, которые необходимо правильно настроить.

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

Быстрое исправление: мы можем наиболее эффективно вылечить проблемы с совместным использованием, рассмотрев возможности в следующем порядке:

  • Убедитесь, что необходимые службы запущены. В системах Windows должны быть запущены сервер, службы TCP/IP NetBIOS Helper, рабочая станция и компьютерный браузер. На компьютерах с Linux, Samba является основным компонентом, необходимым для совместного использования с системами Windows.
  • Проверьте свой файрвол. Очень часто файрвол на ПК настраивается на блокирование трафика совместного использования файлов и принтеров, особенно если установлен новый антивирусный пакет, который имеет собственный брандмауэр. Проблемы с брандмауэром также могут существовать на аппаратном уровне, поэтому убедитесь, что маршрутизаторы или управляемые коммутаторы передают общий трафик в подсети
  • Убедитесь, что все рабочие станции находятся в одной подсети. Эта проблема обычно возникает только в сложных сетях, однако даже в простых сетях иногда используется оборудование со статическим IP-адресом и неправильно настроенной подсетью. В результате внешний трафик будет двигаться очень хорошо, а внутренний трафик столкнется с неожиданными препятствиями.
  • Всем сетевым адаптерам Windows потребуется общий доступ к файлам и принтерам для сетей Microsoft, клиент для сетей Microsoft и NetBIOS через TCP/IP.
  • После того, как вышеуказанные проверки пройдены, настало время проверить наиболее вероятного виновника — разрешения. Требуется несколько уровней доступа, каждый со своим собственным интерфейсом в ОС. Необходимо проверить: системы настроены с неверной рабочей группой или доменом или неправильно настроенная HomeGroup или тип сети установлен в Public или неверные разрешения NTFS.

Локальная сеть не может подключиться к Интернету

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

Быстрое исправление: перезагрузка маршрутизатора и модема — это то что нужно сделать первым делом. Затем утилиту tracert можно использовать для выявления разрывов связи. Это будет явно сбой на конкретном хопе маршрутизатора, который вызывает проблему. Когда будете связываться со своим интернет провайдером, эта информация ускорит поиск проблемы.

Низкая скорость интернета

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

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

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

DNS-серверы — часто пропускаемый аспект интернет-производительности. Использование неправильных DNS-серверов может привести к перегрузке маршрутизации или проблемам с балансировкой нагрузки. Хотя обычно вы должны использовать настройки DNS вашего интернет-провайдера, когда это возможно, они могут фактически направлять трафик через перегруженные веб-кэши. Вы можете временно изменить настройки DNS для использования OpenDNS.

Превентивная мера: если производительность Интернета имеет решающее значение, вам необходимо обеспечить адекватное подключение. Хотя кабельный интернет может быть недорогим, местный оператор DSL может предложить повышенную надежность за несколько более высокую стоимость, но для наиболее стабильной работы вы можете обнаружить, что дорогая выделенная линия является требованием для вашей организации.

Читать еще:  Программа для снятия галочек при установке программ

Дополнительные настройки DHCP сервера.

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

Рассмотрим настраиваемые здесь опции.

Name-Любое имя

Interface – сетевой интерфейс на котором настроен сервер, может быть как физическим так и vlan или bridge.

Lease Time Время аренды ip, по истечении которого сетевому устройству будет выдан новый.

Address Pool диапазон из которого будут выдаваться ip для сетевых устройств, настраивается в IP->Pool.

Src.Address используется если на интерфейсе настроено несколько ip, здесь прописываем рабочий DHCP.

authoritative принимает следующие параметры

yes — если клиент запросит IP, Микротик ему сразу же ответит. Причём если устройство ранее получало IP другого DHCP в сети, то Микротик пошлёт ему пакет DHCPNAK заставляющий обновить ему свой IP

No — если клиент ранее получавший IP с другого DHCP запросит адрес у Микротика то он его проигнорирует

After 2s delay — если клиент запросит IP недоступный на Mikrotik он будет его игнорировать 2 секунды, а далее пошлёт DHCPNAK и присвоит IP из своего диапазона. Своим клиентам Микротик отвечает мгновенно.

After 10s delay — если клиент запросит IP адрес недоступный на Mikrotik он будет его игнорировать 10 секунд, а далее пошлёт DHCPNAK и присвоит IP адрес из своего диапазона. Своим клиентам Микротик отвечает мгновенно.

Bootp Support принимает значения

none — не реагировать на запросы BOOTP

static — предлагать только статические лизинг для BOOTP

dynamic — предлагать статическую и динамическую аренду для BOOTP

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

add arp for leases — автоматически заполняет ARP таблицу, соответствием MAC — IP.

always broadcast — Всегда отправляйте широковещательные пакеты, даже если IP-адрес назначения известен. При включении этой опции возможна дополнительная нагрузка на сеть L2.

Use Radius — Указывает использовать ли RADIUS server для аккаунтинга и аренды адресов.

На Вкладке Networks, кликаем два раза по созданному серверу и рассмотрим опции.

Address – здесь все понятно, ip Микротика

Gateway – шлюз выдаваемый сетевым устройствам

Netmask – маска сети

DNS Servers – ДНС выдаваемые сетевым устройствам

Domain – Имя домена сети

Boot File Name имя загрузочного файла, используется если включена загрузка по сети через tftp.

Options – дополнительные опции, как настроить рассмотрим ниже.

Привязка клиентов по MAC адресу

Если необходимо что бы клиент получал всегда один и тот же ip, то можно зарезервировать ip адрес за MAC адресом, для этого переходим во вкладку IP->DHCP Server, в открывшемся окне выбираем вкладку Leases, у нас откроется список клиентов.

Кликаем левой кнопкой мыши по нужной записи и нажимаем кнопку Make Static.

После этого буква D напротив этого клиента должна исчезнуть.

Теперь MAC клиента будет привязан к постоянному ip.

На этой вкладке также можно узнать и о статусе подключенных пользователей

waiting — пользователь не в сети, ожидается подключение.

testing — проверка использования этого адреса или нет (только для динамической аренды) путем опроса его с тайм-аутом 0,5 с

authorizing — ожидание ответа от сервера радиуса

busy — этот адрес назначается статически клиенту или уже существует в сети, поэтому он не может быть арендован, например если на компьютере настроить ip вручную.

offered — сервер предложил адрес пользователю, но не получил подтверждение от пользователя.

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

Настройка options

Если необходимо настроить опции, например option 82 использующаяся для привязки IP к порту, или option 66 указывающая ip tftp сервера.

Для настройки переходим на вкладку «Options» и жмем кнопку добавить (красный крест)

Заполняем поля открывшегося окошка.

Name-название, вводим любое имя

Code – код опции, 66, 82 и т.д.

Value – адрес ресурса, например tftp сервера

Важно: проверьте версию RouterOS, от этого будет зависеть синтаксис данной настройки.
Для версий с 6.0 -6.7, значение IP нужно вводить, используя одинарные ковычки — ’10.10.10.10’
Для версий от 6.8, значение IP нужно вводить, используя следующий синтаксис — s’10.10.10.10’

После нажатия кнопки Apply поле Raw Value заполнится автоматически, жмем OK, должна появится строчка нашей опции

Теперь переходим вкладку «Networks» и два раза кликаем по нужному серверу.

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

Обучающий курс по настройке MikroTik

Нужно разобраться с MikroTik, но не определились с чего начать? В курсе «Настройка оборудования MikroTik» все по порядку. Подойдет и для начала работы с этим оборудованием, и для того, чтобы систематизировать знания. Это видеокурс из 162 уроков и 45 лабораторных работ, построен на официальной программе MTCNA. Проходить можно, когда удобно и пересматривать по необходимости – материалы курса выдаются бессрочно. Также есть 30 дней на личные консультации с автором. На пробу выдают 25 уроков бесплатно, заказать их можно на странице курса.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

  • Автор: Уваров А.С.
  • 12.07.2019

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

DHCP — это клиент-серверный протокол, использующий в качестве транспорта UDP, порт сервера — 67, порт клиента — 68. Так как для работы протокола используется широковещание (broadcast), то его действие ограничено текущей подсетью (широковещательным доменом). Для взаимодействия с клиентами расположенными в иных широковещательных доменах могут использоваться агенты ретрансляции (DHCP Relay), о них мы поговорим позже.

Основная задача протокола — получение клиентом IP-адреса, поля для иных сетевых настроек не предусмотрены, дополнительные сетевые параметры передаются протоколом DHCР в виде опций, например: опция 1 — маска сети, опция 3 — адрес маршрутизатора (основной шлюз), опция 6 — адреса серверов имен (DNS).

Получение адреса

Рассмотрим процесс получения IP-адреса, он достаточно прост и состоит из четырех этапов, которые в упрощенном виде показаны на следующей схеме:

Начинает этот процесс клиент, отправляя широковещательное сообщение Обнаружения DHCP (DHCP DISCOVER), в качестве обязательных полей передается номер транзакции — xid, MAC-адрес устройства — chaddr, также в опциях передается последний присвоенный клиенту IP-адрес, однако данная опция может быть проигнорирована сервером.

Все это можно увидеть, если заглянуть внутрь DHCP-пакета:

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

Обратим внимание на опцию 55 (Parameter Request List) — это список опции запрашиваемых клиентом. Именно так, опции всегда запрашиваются клиентом. С непониманием этого момента связаны ситуации, когда администратор добавил на сервере нужные ему опции, но клиенты их «почему-то» не получают. Ниже показан состав данной опции для Linux и Windows клиентов:

Можно увидеть, что Linux-клиент запрашивает опцию 42 — сервера времени (NTP), а Windows нет, поэтому даже если вы укажете ее на сервере, то Windows-клиенты не будут ее использовать. А что радует, так это что оба клиента запрашивают обе опции для получения маршрутов: предусмотренную стандартом 121 и введенную Microsoft 249.

Запрос обнаружения рассылается для всех узлов сети, но отвечают на него только DHCP-сервера, формируя сообщение Предложения DHCP (DHCP OFFER), которое содержит предлагаемую сервером сетевую конфигурацию. Если серверов несколько, то предложений клиент получит несколько. Из предложенных конфигураций клиент выбирает одну, как правило полученную первой. Предлагаемый клиенту адрес содержится в специальном поле yiaddr, а поле siaddr передается адрес DHCP-сервера.

Так как MAC-адрес отправителя известен, то сервер направляет ответ непосредственно клиенту (unicast), хотя в некоторых случаях может ответить и широковещательным пакетом. Например, DHCP-сервера dnsmasq и Mikrotik отвечает непосредственно клиенту (юникастом), в то время как DHCP Windows Server отвечает широковещательным пакетом. По большому счету это не имеет особого значения, просто вы должны знать, что это вполне допустимые режимы работы DHCP-сервера и не являются признаком неправильной работы.

В структуре ответа мы также отметили цветом вышеописанные опции, также обратите внимание, что в данном случае ответ был отправлен широковещательным пакетом (Windows Server). Ниже показана структура ответа dnsmasq:

Здесь видно, что сервер ответил непосредственно клиенту (отправив фрейм на его MAC-адрес), не прибегая к широковещательной рассылке.

Остальные сетевые параметры передаются в виде опций, в нашем случае это опции 1, 3 и 6 (маска, шлюз, DNS):

Приняв предложение клиент официально запрашивает у сервера данную конфигурацию, для чего отправляет широковещательно Запрос DHCP (DHCP REQUEST), он полностью повторяет по структуре сообщение обнаружения (Discover), только добавляет к нему опцию 54 с адресом сервера, конфигурацию которого клиент принял. Опция 50 содержит предложенный сервером IP-адрес. Несмотря на то, что MAC-адрес DHCP-сервера известен, запрос (Request) рассылается широковещательно, это нужно для того, чтобы остальные DHCP-сервера понимали, что их предложение отвергнуто.

Выше показана структура запроса, можете сравнить его с пакетом обнаружения, обратите внимание на заполненное значение опции 54.

Получив запрос сервер направляет клиенту в ответ Подтверждение DHCP (DHCP ACK), которое отправляется на MAC-адрес клиента (хотя может и широковещательно) и получив которое клиент должен настроить свой сетевой адаптер согласно указанного адреса и опций.

По структуре сообщение подтверждения (Ask) практически не отличается от предложения (Offer), за исключением того, что поле siaddr с адресом DHCP-сервера не заполняется, но его адрес передается в опции 54.

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

Также клиент может самостоятельно отказаться от выданного адреса, отправив серверу сообщение Освобождения DHCP (DHCP RELEASE), в отличии от других сообщений, освобождение направляется юникастом серверу, выдавшему адрес. Получив такое сообщение сервер помечает адрес как доступный, но на всякий случай оставляет запись о клиенте, если он захочет получить адрес повторно. Это поведение не является обязательным, но реализовано в большинстве DHCP-серверов.

Обновление адреса

IP-адрес выдается клиенту на определенное время, называемое сроком аренды, его значение зависит от настроек сервера и может варьироваться в широких пределах, например, для DHCP-сервера Windows стандартный срок аренды — 8 дней.

В зависимости от срока прошедшего с момента получения адреса клиент может находится в одном из нескольких состояний.

Сразу после получения адреса клиент переходит в нормальное состояние (BOUND), при этом устанавливаются два момента времени T1 — равный половине времен аренды и T2 — равный 7/8 срока. По достижении времени T1 клиент переходит в состояние Обновления адреса (RENEWING), при котором он пытается обновить свой IP-адрес.

Для этого он отправляет сообщение запроса (Request), в котором указывает текущий IP-адрес. Если сервер подтверждает аренду, то отвечает сообщением подтверждения (Ask), клиент сбрасывает счетчики T1 и T2 и начинает отсчет срока аренды заново.

Обратите внимание, что на сообщение запроса ответит только тот сервер, у которого имеется запись для этого клиента, если такой записи нет — запрос будет проигнорирован.

Данные о сроке аренды и времени обновления адреса и обновлении конфигурации передаются сервером в опциях 51, 58 и 59:

Если сервер не ответил клиенту, то он берет промежуток времени до окончания состояния обновления и делит его пополам, в это время будет отправлен повторный запрос, при его отсутствии промежуток времени снова будет поделен пополам, потом снова пополам, при этом полученный промежуток времени не может быть меньше 60 сек. Таким образом, чем ближе окончание срока обновления, тем чаще будут делаться запросы.

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

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

Также при обновлении могут быть иные сценарии развития событий. Скажем, клиент был включен в другую подсеть. В этом случае при получении запроса DHCP (клиент не знает, что он в другой подсети и пытается продлить аренду) сервер определяет неподходящий адрес в запросе и отвечает ему сообщением Отмены DHCP (DHCP NAK), после чего клиент должен начать процедуру получения адреса заново.

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

Получение дополнительной информации

Если клиент имеет статически назначенный IP-адрес, но хочет получить дополнительные параметры, скажем адрес серверов имен или статические маршруты, то он отправляет специальное широковещательное сообщение Информации DHCP (DHCP INFORM), в ответ сервера отправляют сообщение подтверждения (Ask) без выделения IP-адреса.

2 ответа

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

DHCP на простой сети работает с использованием принципа DORA.

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

Предложение — подходящий DHCP-сервер получает запрос от клиента и предлагает ему адрес из своего пула доступных адресов.

Запрос — клиент отвечает на предложение, запрашивая адрес, полученный в Оферте.

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

Любое устройство в сегменте сети может быть DHCP-сервером; он не должен быть маршрутизатором или контроллером домена или любым другим «специальным» устройством в сети.

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

Несколько DHCP-серверов PT 1: объединение нескольких подсетей.

Если у вас несколько VLAN или физических сегментов сети, которые разделены на разные подсети, и вы хотите предоставить DHCP-сервис для устройств во всех этих подсетях, тогда есть два способа сделать это.

Если разделитель маршрутизатора /уровня 3, разделяющий их, может действовать как агент ретрансляции BOOTP /DHCP, вы можете продолжать хранить все ваши DHCP-серверы в одной или двух центральных частях вашей сети и настраивать DHCP-сервер (ы) для поддержки нескольких диапазонов адресов. Чтобы поддержать это, коммутатор маршрутизатора или уровня 3 должен поддерживать спецификацию агента ретрансляции BOOTP, описанную в разделе 4 RFC 1542 .

Если ваш маршрутизатор не поддерживает ретрансляторы RFC 1542 BOOTP, или если некоторые из ваших сегментов сети географически распределены по медленным ссылкам, вам нужно будет поместить один или несколько DHCP-серверов в каждую подсеть. Этот «сервер» DHCP-сервер будет выполнять только собственные требования к локальному сегменту, и нет никакого взаимодействия между ним и другими серверами DHCP. Если это то, что вам нужно, вы можете просто настроить каждый DHCP-сервер как автономный сервер с подробными сведениями о пуле адресов для собственной подсети и не беспокоиться о каких-либо других серверах DHCP в других частях сети. Это самый простой пример наличия нескольких DHCP-серверов в одной сети.

Читать еще:  Проверка SSD диска на битые сектора

Несколько DHCP-серверов PT 2: DHCP-серверы, обслуживающие один и тот же сегмент сети.

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

Это вполне возможно, хотя это требует некоторой мысли и планирования.

С точки зрения «сетевого трафика» процесс DORA, описанный в начале этого ответа, объясняет, как может присутствовать более одного DHCP-сервера в сегменте сети; клиент просто передает запрос на обнаружение, а первый DHCP-сервер отвечает предложением — это «победитель».

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

Другими словами, если у вас есть диапазон адресов DHCP для выдачи клиентам с 192.168.1.100 по 192.168.1.200, то оба сервера должны быть настроены для обслуживания отдельных частей этого диапазона, поэтому первый сервер может использовать части этот объем с 192.168.1.100 до 192.168.1.150, а второй сервер затем выдает 192.168.1.151 до 192.168.1.200.

В более поздних версиях Microsoft DHCP есть мастер, позволяющий разделить вашу область, как это легко сделать, описанную в Technet article , на которые стоит обратить внимание, даже если вы не используете реализацию Microsoft DHCP, так как этоиллюстрирует принципы, о которых здесь говорили довольно хорошо, и этот ответ уже достаточно длинный.

Разделение области — наилучшая практика

Одна вещь, которую вы услышите в качестве лучшей практики, — это правило 80/20 для разделения области DHCP, а это означает, что один сервер будет обслуживать 80% адресов в этой области и другого DHCP-сервера, что эффективно «В резерве» будет обслуживать 20% адресов.

Идея разделения адресов 80/20 заключается в том, что 80% доступных адресов, должно быть, будет достаточным для всех адресов, необходимых для подсети, а аренды DHCP обычно выдаются на несколько дней; поэтому, если ваш основной сервер DHCP снизится в течение нескольких часов, маловероятно, что более 20% компьютеров в этой подсети должны будут обновлять свои адреса во время простоя, делая достаточным количество адресов на 20%.

Это по-прежнему разумный совет, но он предполагает две вещи:

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

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

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

Объединение этих идей

Наконец, стоит вспомнить, что вы можете объединить принципы, о которых говорилось выше, — вы можете поместить все ваши DHCP-серверы в одну или несколько VLAN с центральным сервером и использовать ретрансляционные агенты BOOTP на всех ваших маршрутизаторах для отправки всех запросов DHCP с очень большой и сегментированной сети к централизованной службе DHCP (что я и делаю, см. ниже). Или вы можете иметь DHCP-серверы, распределенные по всей вашей сети, с «основным» DHCP-сервером в своей локальной подсети и «резервным» DHCP-сервером в «ближайшем» сегменте сети, обеспечивающим небольшое количество адресов в качестве резервной копии — вы могли бы даже два DHCP-сервера в своих собственных сегментах сети, настроенных для предоставления адресов адресов 80/20 друг для друга. Наиболее разумный выбор будет зависеть от того, как ваши физические и логические сети сопоставляются друг с другом.

Настройка dhcp cisco

Настройка для маленького офиса

У нас есть филиал, 3 компьютера, один коммутатор второго уровня Cisco 2960 и роутер Cisco 1841. Все компьютеры находятся в нативном vlan (vlan по умолчанию). Вот схема сети.

Приступаем к настройке Cisco 1841. Поднимем у него порт fa0/0 и назначим ему ip 192.168.1.1/24

Видим, что порт загорелся зеленым.

Далее создаем pool ip адресов на cisco dhcp server, для этого вводим команду: DHCP_192.168.1.0 это имя

Посмотрим теперь доступные команды

Router(dhcp-config)#?
default-router Default routers
dns-server Set name server
exit Exit from DHCP pool configuration mode
network Network number and mask
no Negate a command or set its defaults
option Raw DHCP options

Задаем в начале сеть которую будем раздавать, естественно она должна быть в том же диапазоне что и ip адрес устройства Cisco. Создаю сеть 192.168.1.0

Теперь давайте исключим из созданного пула первые 50 ip адресов, которые отдадим для серверов и про запас.

Проверка получения ip адреса

Берем первый компьютер, вводи на нем команду ipconfig чтобы посмотреть текущие настройки. Как видим, ip адрес не назначен. Так как это у меня симулятор Cisco packet tracer 6.2, то у него по умолчанию стоит статический ip в настройках, поставлю получение автоматически с DHCP.

Делаем снова ipconfig и видим, что получили ip адрес 192.168.1.51

Делаем на двух других компьютерах такие же настройки, и пробуем пропинговать друг друга, видим, все ок пинги доходят.

В малом офисе мы настроили dhcp сервер cisco.

Принципы работы DHCP

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

Для начала давайте вспомним, что требуется компьютеру для работы в сети. К примеру, так выглядит консоль настроек сети в Windows.

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

С помощью DHCP решаются две основные проблемы:

• Автоматизация. При наличии в сети DHCP-сервера не требуется производить настройки на каждом новом клиенте. Достаточно один раз настроить DHCP-сервер и дальнейшая настройка IP-адресов и прочих сетевых параметров производится автоматически;
• Централизованное управление. DHCP-сервер осуществляет контроль за выданными адресами, предотвращает их дублирование, а также своевременно освобождает неиспользуемые IP-адреса.

Подробно протокол DHCP описан в документе RFC 2131, мы же не будем вдаваться в детали, а рассмотрим только основные моменты. Начнем с процедуры получения настроек.

Получение настроек

DHCP работает по схеме клиент-сервер. Процесс получения настроек происходит в несколько этапов и описывается схемой DORA (Discover-Offer-Request-Acknowledge):

Discover (Обнаружение)
Клиент DHCP подключается к сети и приступает к инициализации (состояние INIT). Первым делом он ищет в сети подходящий DHCP-сервер, для чего отправляет запрос DHCPDISCOVER на широковещательный адрес 255.255.255.255. В качестве своего адреса клиент указывает 0.0.0.0, поскольку своего адреса у него еще нет. Также в запросе клиент указывает свой MAC-адрес. Запрос доставляется всем компьютерам, находящимся в данном сегменте сети, но отвечают на него только DHCP-сервера.

Offer (Предложение)
DHCP-сервер, получивший запрос DHCPDISCOVER, анализирует его содержимое, выбирает подходящую конфигурацию сети и отправляют ее в сообщении DHCPOFFER. Обычно DHCPOFFER отправляется на MAC-адрес клиента, указанный в DHCPDISCOVER, хотя иногда может использоваться широковещание. Если в сети находятся несколько DHCP-серверов, то клиент получает несколько ответов DHCPOFFER и выбирает из них один, как правило полученный первым.

Request (Запрос)
Получив ответ сервера, клиент отвечает сообщением DHCPREQUEST, в котором ″официально″ запрашивает у сервера предоставленные настройки. В сообщении DHCPREQUEST содержится та же информация, что и в DHCPDISCOVER, а также IP-адрес выбранного DHCP-сервера. DHCPREQUEST отправляется на широковещательный адрес и те DHCP-сервера, чей адрес отсутствует в сообщении, понимают что их предложение отвергнуто.

Acknowledge (Подтверждение)
DHCP-сервер, адрес которого указан в DHCPREQUEST, получает сообщение и понимает, что его выбрали. Он фиксирует привязку для клиента и отвечает сообщением DHCPACK, подтверждая выданные клиенту настройки. DHCPACK отправляется на MAC-адрес клиента, указанный в DHCPREQUEST. Клиент получает сообщение DHCPACK, проверяет настройки и применяет конфигурацию (состояние BOUND), которая была получена в сообщении DHCPOFFER.

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

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

У клиента уже есть назначенный ранее адрес

Если у клиента имеется выданный ранее сетевой адрес и он хочет его использовать, то можно пропустить некоторые этапы. В этом случае клиент передает широковещательное сообщение DHCPREQUEST, указывая в сообщении имеющийся у него адрес. DHCP-cервер, получивший запрос, проверяет корректность сети и адреса и в случае успешной проверки посылает клиенту подтверждение DHCPACK. Клиент получает подтверждение и применяет настройки.

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

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

У клиента есть адрес, полученный другим способом

Если у клиента уже есть адрес, назначенный любым другим способом (например вручную), то он может запросить у DHCP-сервера только конкретные параметры конфигурации (например адреса DNS-серверов) с помощью сообщения DHCPINFORM. Сообщение передается на адрес сервера (если он известен) либо широковещанием на адрес 255.255.255.255. DHCP-сервер, получивший сообщение DHCPINFORM, отвечает сообщением DHCPACK с требуемыми параметрами конфигурации, но без проверки аренды и выделения сетевого адреса. Сообщение передается клиенту напрямую. Клиент принимает ответ и применяет полученные настройки.

Если клиент не получает от сервера сообщения DHCPACK в течение разумного срока ожидания, то он должен выдать пользователю сообщение о проблеме и приступить к работе в сети, используя параметры, рекомендованные в RFC 1122.

Примечание. Вообще процедура получения адреса может кардинально отличаться в зависимости от настроек DHCP-сервера. Например сервер может выдать клиенту адрес, отличающийся от запрошенного, предложить адрес из другой подсети и даже вообще отказать в предоставлении адреса. Более того, DHCP-сервер вовсе не должен отвечать на каждый поступивший к нему запрос. Это позволяет контролировать доступ к сети, например можно выдавать адреса только клиентам, прошедшим определенную проверку.

Обновление адреса

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

В процессе обновления клиент проходит два состояния — обновление адреса (RENEWING) и обновление конфигурации (REBINDING). Первое состояние наступает на примерно половине срока аренды адреса (T1), второе – по истечении 87.5% (или 7/8) полного срока аренды (T2). Для предотвращения синхронизации разных клиентов при расчете значений T1 и T2 к ним добавляется случайное отклонение.

Обновление адреса (RENEWING)

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

• Сервер соглашается продлить аренду. Для подтверждения продления аренды он посылает клиенту сообщение DHCPACK с указанием нового срока аренды и тех параметров, которые могли измениться с момента создания или последнего продления аренды;
• Сервер отказывается продлевать аренду. В этом случае он шлет клиенту сообщение об отказе DHCPNACK.

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

• В случае положительного ответа DHCPACK отмечает новый срок истечения аренды и все измененные параметры, полученные от сервера, сбрасывает таймеры T1 и T2 и переходит в нормальное (BOUND) состояние.
• Получив отрицательный ответ DHCPNACK немедленно переходит в состояние инициализации (INIT) и начинает процедуру получения аренды заново.

Обновление конфигурации (REBINDING)

Если клиент сразу не получает ответ от сервера на запрос обновления аренды, то он ожидает ответ в течение времени (T2 — t)/2 сек (но не меньше 60 сек), где t — время отправки последнего сообщения DHCPREQUEST, затем отправляет сообщение повторно. Пока сервер не ответит, клиент остается в состоянии RENEWING и регулярно шлет запрос DHCPREQUEST на сервер. В течение этого времени он сохраняет свой текущий адрес и продолжает нормально работать.

Если ответ от сервера не поступил к моменту T2, клиент переходит в состояние REBINDING и передает уже широковещательное сообщение DHCPREQUEST со своим текущим адресом. В этом случае срок повтора запросов DHCPREQUEST рассчитывается аналогично предыдущему случаю, только вместо T2 используется полное время окончания срока аренды.

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

Освобождение адреса

Клиент может явно отказаться от аренды сетевого адреса, передав серверу сообщение DHCPRELEASE. При получении этого сообщения сервер помечает адрес как свободный, но сохраняет запись с параметрами клиента в базе на тот случай, если клиент захочет использовать адрес повторно. Стоит уточнить, что клиент не освобождает аренду при обычном выключении, все настройки сохраняются локально. Клиент передает DHCPRELEASE только при явной необходимости отказаться от аренды, например при перемещении в другую подсеть. Также освободить аренду можно вручную, например с помощью команды ipconfig /release.

Еще из важного

Для своей работы DHCP использует протокол UDP. Сообщения от клиента к серверу передаются по порту 67 UDP, а сообщения от сервера клиенту — на порт UDP 68.

Также надо знать, что по умолчанию сообщения DHCP ограничены текущей подсетью. Дело в том, что для своей работы DHCP использует широковещание (broadcast), а маршрутизаторы не пропускают широковещательный трафик за пределы широковещательного домена.

Примечание. Широковещательный домен ( broadcast domain ) — область сети, в которой все узлы могут общаться между собой с помощью широковещания, без участия маршрутизатора. Обычно широковещательному домену соответствует физическая или логическая подсеть.

Так вот, если DHCP-сервер и клиенты находятся в разных широковещательных доменах и не могут общаться напрямую, то для их взаимодействия требуется специальный DHCP ретранслятор (DHCP relay agent). Ретранслятор является как бы посредником между клиентом и сервером, он обрабатывает стандартный широковещательный DHCP-запрос и отправляет его на сервер в виде адресного (unicast) пакета, а полученный от сервера ответ переправляет DHCP-клиенту. В роли ретранслятора могут выступать как маршрутизаторы, так и специальные серверы. К примеру в Windows Server для этого есть специальная серверная роль.

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

На этом пожалуй закончим теоретическую часть. В следующей статье речь пойдет о настройке DHCP-сервера на базе Windows Server 2016.

Ссылка на основную публикацию
Статьи c упоминанием слов:

Adblock
detector