Dhcp что это такое: DHCP что это такое

Содержание

Что такое DHCP? (Протокол динамического конфигурирования сервера)

Автор comhub Просмотров 386 Опубликовано 10 августа, 2018 Обновлено 17 августа, 2018

DHCP (Dynamic Host Configuration Protocol) — это протокол, используемый для быстрого, автоматического и централизованного управления распределением IP-адресов в сети.

DHCP также используется для настройки правильной маски подсети , шлюза по умолчанию и информации DNS-сервера на устройстве.

DHCP — Dynamic Host Configuration Protocol — Протокол динамического конфигурирования сервера

Как работает DHCP

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

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

Когда устройство включено и подключено к сети с DHCP-сервером, он отправит запрос на сервер, называемый запросом DHCPDISCOVER.

После того, как пакет DISCOVER достигнет DHCP-сервера, сервер попытается удержать IP-адрес, который может использовать устройство, а затем предлагает клиенту адрес с пакетом DHCPOFFER.

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

Если сервер решает, что устройство не может иметь IP-адрес, он отправит NACK.

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

Плюсы и минусы использования DHCP

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

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

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

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

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

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

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

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

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

Дополнительная информация о DHCP

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

Это еще одна причина, по которой DHCP настолько полезен, потому что он позволяет множеству устройств подключаться к сети в течение определенного периода времени, не требуя массивного пула доступных адресов. Например, даже если только DHCP-сервер определяет только 20 адресов, 30, 50 или даже 200 (или более) устройств могут подключаться к сети, если не более 20 используют один из доступных IP-адресов одновременно.

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

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

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

В Windows APIPA назначает специальный временный IP-адрес, когда DHCP-сервер не может доставить функциональное устройство на устройство и использует этот адрес, пока он не сможет получить тот, который работает.

Рабочая группа конфигурации динамического хоста Целевой группы Internet Engineering создала DHCP.

DHCP — Википедия

Не следует путать с HDCP.

DHCP
Название	Dynamic Host Configuration Protocol
Уровень (по модели OSI)	Прикладной ^[1]
Семейство	TCP/IP
Создан в	1990
Порт/ID	67, 68/UDP
Назначение протокола	Получение сетевой конфигурации
Спецификация	RFC 2131
Основные реализации (клиенты)	ISC DHCP, ядро Windows
Основные реализации (серверы)	dhcpd, ISC DHCP Server, Infoblox

DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) — сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP, и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве сетей TCP/IP.

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

История

Стандарт протокола DHCP был принят в октябре 1993 года. Действующая версия протокола (март 1997 года) описана в RFC 2131. Новая версия DHCP, предназначенная для использования в среде IPv6, носит название DHCPv6 и определена в RFC 3315 (июль 2003 года).

Распределение IP-адресов

Протокол DHCP предоставляет три способа распределения IP-адресов:

Ручное распределение. При этом способе сетевой администратор сопоставляет аппаратному адресу (для Ethernet сетей это MAC-адрес) каждого клиентского компьютера определённый IP-адрес. Фактически данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости.
Автоматическое распределение. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона.
Динамическое распределение. Этот способ аналогичен автоматическому распределению за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым). Кроме того, клиент сам может отказаться от полученного адреса.

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

Опции DHCP

Помимо IP-адреса, DHCP также может сообщать клиенту дополнительные параметры, необходимые для нормальной работы в сети. Эти параметры называются опциями DHCP. Список стандартных опций можно найти в RFC 2132.

Некоторыми из наиболее часто используемых опций являются:

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

Устройство протокола

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

Структура сообщений DHCP

Все сообщения протокола DHCP разбиваются на поля, каждое из которых содержит определённую информацию. Все поля, кроме последнего (поля опций DHCP), имеют фиксированную длину.

Поле	Описание	Длина (в байтах)
op	Тип сообщения. Например может принимать значения: BOOTREQUEST (0x01, запрос от клиента к серверу) и BOOTREPLY (0x02, ответ от сервера к клиенту).	1
htype	Тип аппаратного адреса. Допустимые значения этого поля определены в RFC 1700 «Assigned Numbers». Например, для MAC-адреса Ethernet это поле принимает значение 0x01.	1
hlen	Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet —0x06.	1
hops	Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP), через которые прошло сообщение. Клиент устанавливает это поле в 0x00.	1
xid	Уникальный идентификатор транзакции в 4 байта, генерируемый клиентом в начале процесса получения адреса.	4
secs	Время в секундах с момента начала процесса получения адреса. Может не использоваться (в этом случае оно устанавливается в 0x0000).	2
flags	Поле для флагов — специальных параметров протокола DHCP.	2
ciaddr	IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру обновления адреса по истечении срока аренды).	4
yiaddr	Новый IP-адрес клиента, предложенный сервером.	4
siaddr	IP-адрес сервера. Возвращается в предложении DHCP (см. ниже).	4
giaddr	IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до сервера.	4
chaddr	Аппаратный адрес (обычно MAC-адрес) клиента.	16
sname	Необязательное имя сервера в виде нуль-терминированной строки.	64
file	Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки.	128
options	Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные числа»), позволяющие серверу определить наличие этого поля. Поле имеет переменную длину, однако DHCP-клиент должен быть готов принять DHCP-сообщение длиной в 576 байт (в этом сообщении поле options имеет длину 340 байт).	переменная

Пример процесса получения адреса

Рассмотрим пример процесса получения IP-адреса клиентом от сервера DHCP. Предположим, клиент ещё не имеет собственного IP-адреса, но ему известен его предыдущий адрес — 192.168.1.100. Процесс состоит из четырёх этапов. Эти этапы часто сокращаются как DORA (Discovery, Offer, Request, и Acknowledgement)

Обнаружение DHCP

В начале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (если компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения —широковещательный адрес 255.255.255.255.

Клиент заполняет несколько полей сообщения начальными значениями:

В поле xid помещается уникальный идентификатор транзакции, который позволяет отличать данный процесс получения IP-адреса от других, протекающих в то же время.
В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента.
В поле опций указывается последний известный клиенту IP-адрес. В данном примере это 192.168.1.100. Это необязательно и может быть проигнорировано сервером.

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

Не всегда процесс получения IP адреса начинается с DHCPDISCOVER. В случае, если клиент ранее уже получал IP адрес и срок его аренды ещё не прошёл — клиент может пропустить стадию DHCPDISCOVER начав с запроса DHCPREQUEST отправляемого с идентификатором сервера, который выдал адрес в прошлый раз. В случае же отсутствия ответа от DHCP сервера, выдавшего настройки в прошлый раз, клиент отправляет DHCPDISCOVER. Тем самым, клиент начинает процесс получения с начала, обращаясь уже ко всем DHCP серверам в сегменте сети.

Предложение DHCP

Получив сообщение от клиента, сервер определяет требуемую конфигурацию клиента в соответствии с указанными сетевым администратором настройками. В данном случае DHCP-сервер согласен с запрошенным клиентом адресом 192.168.1.100. Сервер отправляет ему ответ (DHCPOFFER), в котором предлагает конфигурацию. Предлагаемый клиенту IP-адрес указывается в поле yiaddr. Прочие параметры (такие, как адреса маршрутизаторов и DNS-серверов) указываются в виде опций в соответствующем поле.

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

Запрос DHCP

Выбрав одну из конфигураций, предложенных DHCP-серверами, клиент отправляет запрос DHCP (DHCPREQUEST). Он рассылается широковещательно; при этом к опциям, указанным клиентом в сообщении DHCPDISCOVER, добавляется специальная опция — идентификатор сервера — указывающая адрес DHCP-сервера, выбранного клиентом (в данном случае — 192.168.1.1).

Подтверждение DHCP

Наконец, сервер подтверждает запрос и направляет это подтверждение (DHCPACK) клиенту. После этого клиент должен настроить свой сетевой интерфейс, используя предоставленные опции.

Вид сообщений

Ниже приведены значения каждого поля для каждого из отправляемых в процессе сообщений DHCP.

**Обнаружение DHCP**
DHCPDISCOVER
OP	HTYPE	HLEN	HOPS
UDP Src=0.0.0.0 Dest=255.255.255.255
0x01	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0x00000000
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: обнаружение DHCP
Опция DHCP 50: запрос адреса 192.168.1.100

**Предложение DHCP**
DHCPOFFER
OP	HTYPE	HLEN	HOPS
UDP Src=192.168.1.1 Dest=255.255.255.255
0x02	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0xC0A80164
SIADDR
0xC0A80101
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: предложение DHCP
Опция DHCP 1: маска подсети 255.255.255.0
Опция DHCP 3: маршрутизатор 192.168.1.1
Опция DHCP 51: срок аренды IP-адреса — 1 день
Опция DHCP 54: DHCP-сервер 192.168.1.1

**Запрос DHCP**
DHCPREQUEST
OP	HTYPE	HLEN	HOPS
UDP Src=0.0.0.0 Dest=255.255.255.255
0x01	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0x00000000
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: запрос DHCP
Опция DHCP 50: запрос адреса 192.168.1.100
Опция DHCP 54: DHCP-сервер 192.168.1.1

**Подтверждение DHCP**
DHCPACK
OP	HTYPE	HLEN	HOPS
UDP Src=192.168.1.1 Dest=255.255.255.255
0x02	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0xC0A80164
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: подтверждение DHCP
Опция DHCP 1: маска подсети 255.255.255.0
Опция DHCP 3: маршрутизатор 192.168.1.1
Опция DHCP 51: срок аренды IP-адреса — 1 день
Опция DHCP 54: DHCP-сервер 192.168.1.1

Прочие сообщения DHCP

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

Отказ DHCP

Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.

Сообщение отмены DHCP (DHCPNAK). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.

Освобождение DHCP

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

Информация DHCP

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

Реализации

Компания Microsoft впервые включила сервер DHCP в поставку серверной версии Windows NT 3.5, выпущенной в 1994 году. Начиная с Windows 2000 Server реализация DHCP-сервера от Microsoft позволяет динамически обновлять записи DNS, что используется в Active Directory.

Internet Systems Consortium выпустил первую версию ISC DHCP Server (для Unix-подобных систем) 6 декабря 1997 года. 22 июня 1999 года вышла версия 2.0, более точно соответствующая стандарту.

Компания Cisco включила сервер DHCP в Cisco IOS 12.0 в феврале 1999 года. Sun добавила DHCP-сервер в Solaris 8 в июле 2001 года.

В настоящее время существуют реализации сервера DHCP для ОС Windows в виде отдельных программ, в том числе открытых^[2], позволяющих выполнять роль сервера DHCP компьютерам под управлением не серверных версий данной ОС.

Примечания

См. также

Ссылки

Что такое DHCP — энциклопедия lanmarket.ua

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

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

Что такое DHCP?

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

Зачем вам нужно использовать DНСР? Благодаря динамической адресации компьютер может иметь другой IP-адрес при каждом подключении к сети, к которой он принадлежит, без вмешательства администратора UNIX. Благодаря этой функции DHCP каждому новому компьютеру, добавленному в сеть, автоматически назначается уникальный IP-адрес.

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

Как он работает?

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

Методы распределения DHCP

В зависимости от конфигурации DHCP-сервер может работать тремя способами:

Динамическое распределение

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

Автоматическое распределение

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

Статическое распределение

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

DHCP-сервер может быть настроен на работу с использованием комбинации методов распределения. Например, в общедоступной сети Wi-Fi все известные хосты и постоянные клиенты могут использовать статическое распределение, тогда как для гостей используется динамическое распределение. Таким образом, известные хосты могут всегда использовать один и тот же IP-адрес, а пул IP-адресов одинаково доступен для всех.

Функции клиента DHCP

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

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

Два дополнительных типа сообщений в определении DHCP предназначены для использования клиентом: сообщение DHCPINFORM и опция DHCPRELEASE.

DHCP Inform

Сообщение DHCPOFFER состоит из нескольких полей параметров в его структуре пакетов. Тем не менее, сервер редко использует все эти и не дает значений для каких-либо. Конкретной клиентской программе может потребоваться определенная информация для правильной настройки своего устройства в сети. Если эта важная информация отсутствует в сообщении предложения DHCP, она может отправить сообщение «Информер» с просьбой отправить детали. Если эта информация доступна, она будет отправлена сервером в виде другого сообщения «Предложение» с заполненными полями необходимых параметров. Примером использования DHCP Inform является то, что браузер часто использует это сообщение как способ получить веб-прокси с помощью процедур автоматического обнаружения веб-прокси.

DHCP Release

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

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

Другие узлы DHCP

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

Структура пакетов всех типов сообщений DHCP включает поле GIADDR, которое заполняется реле. Это собственный адрес реле, поэтому, когда сообщение, полученное ретранслятором от клиента, перенаправляется на сервер DHCP, сервер знает, куда отправить ответ, и какой диапазон адресов использовать для распределения адреса на этом реле подсети.

Связь ретранслятора с DHCP-сервером рассматривает оба устройства с использованием UDP-порта 67.

Недостатки безопасности DHCP

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

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

DHCP — это… Что такое DHCP?

Не следует путать с HDCP.

DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической конфигурации узла) — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP, и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве сетей TCP/IP.

История

Распределение IP-адресов

Протокол DHCP предоставляет три способа распределения IP-адресов:

Ручное распределение. При этом способе сетевой администратор сопоставляет аппаратному адресу (для Ethernet сетей это MAC-адрес) каждого клиентского компьютера определённый IP-адрес. Фактически, данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости.
Автоматическое распределение. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона.
Динамическое распределение. Этот способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым). Кроме того, клиент сам может отказаться от полученного адреса.

Опции DHCP

Некоторыми из наиболее часто используемых опций являются:

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

Устройство протокола

Протокол DHCP является клиент-серверным, то есть в его работе участвуют клиент DHCP и сервер DHCP. Передача данных производится при помощи протокола UDP, при этом сервер принимает сообщения от клиентов на порт 67 и отправляет сообщения клиентам на порт 68.

Структура сообщений DHCP

Поле	Описание	Длина (в байтах)
op	Тип сообщения. Например может принимать значения: BOOTREQUEST (1, запрос от клиента к серверу) и BOOTREPLY (2, ответ от сервера к клиенту).	1
htype	Тип аппаратного адреса. Допустимые значения этого поля определены в RFC1700 «Assigned Numbers». Например, для MAC-адреса Ethernet 10 Мбит/с это поле принимает значение 1.	1
hlen	Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet — 6.	1
hops	Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP), через которые прошло сообщение. Клиент устанавливает это поле в 0.	1
xid	Уникальный идентификатор транзакции, генерируемый клиентом в начале процесса получения адреса.	4
secs	Время в секундах с момента начала процесса получения адреса. Может не использоваться (в этом случае оно устанавливается в 0).	2
flags	Поле для флагов — специальных параметров протокола DHCP.	2
ciaddr	IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру обновления адреса по истечении срока аренды).	4
yiaddr	Новый IP-адрес клиента, предложенный сервером.	4
siaddr	IP-адрес сервера. Возвращается в предложении DHCP (см. ниже).	4
giaddr	IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до сервера.	4
chaddr	Аппаратный адрес (обычно MAC-адрес) клиента.	16
sname	Необязательное имя сервера в виде нуль-терминированной строки.	64
file	Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки.	128
options	Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные числа»), позволяющие серверу определить наличие этого поля. Поле имеет переменную длину, однако DHCP-клиент должен быть готов принять DHCP-сообщение длиной в 576 байт (в этом сообщении поле options имеет длину 340 байт).	переменная

Пример процесса получения адреса

Обнаружение DHCP

Вначале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения — широковещательный адрес 255.255.255.255.

Клиент заполняет несколько полей сообщения начальными значениями:

В поле xid помещается уникальный идентификатор транзакции, который позволяет отличать данный процесс получения IP-адреса от других, протекающих в то же время.
В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента.
В поле опций указывается последний известный клиенту IP-адрес. В данном примере это 192.168.1.100. Это необязательно и может быть проигнорировано сервером.

Предложение DHCP

Запрос DHCP

Подтверждение DHCP

Вид сообщений

Ниже приведены значения каждого поля для каждого из отправляемых в процессе сообщений DHCP.

**Обнаружение DHCP**
DHCPDISCOVER
OP	HTYPE	HLEN	HOPS
UDP Src=0.0.0.0 Dest=255.255.255.255
0x01	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0x00000000
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: обнаружение DHCP
Опция DHCP 50: запрос адреса 192.168.1.100

**Предложение DHCP**
DHCPOFFER
OP	HTYPE	HLEN	HOPS
UDP Src=192.168.1.1 Dest=255.255.255.255
0x02	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0xC0A80164
SIADDR
0xC0A80101
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: предложение DHCP
Опция DHCP 1: маска подсети 255.255.255.0
Опция DHCP 3: маршрутизатор 192.168.1.1
Опция DHCP 51: срок аренды IP-адреса — 1 день
Опция DHCP 54: DHCP-сервер 192.168.1.1

**Запрос DHCP**
DHCPREQUEST
OP	HTYPE	HLEN	HOPS
UDP Src=0.0.0.0 Dest=255.255.255.255
0x01	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0x00000000
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: запрос DHCP
Опция DHCP 50: запрос адреса 192.168.1.100
Опция DHCP 54: DHCP-сервер 192.168.1.1

**Подтверждение DHCP**
DHCPACK
OP	HTYPE	HLEN	HOPS
UDP Src=192.168.1.1 Dest=255.255.255.255
0x02	0x01	0x06	0x00
XID
0x3903F326
SECS		FLAGS
0x0000		0x0000
CIADDR
0x00000000
YIADDR
0xC0A80164
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x0000001d6057ed80
SNAME
(пустое поле)
FILE
(пустое поле)
OPTIONS
Опция DHCP 53: подтверждение DHCP
Опция DHCP 1: маска подсети 255.255.255.0
Опция DHCP 3: маршрутизатор 192.168.1.1
Опция DHCP 51: срок аренды IP-адреса — 1 день
Опция DHCP 54: DHCP-сервер 192.168.1.1

Прочие сообщения DHCP

Отказ DHCP

Отмена DHCP

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

Освобождение DHCP

Информация DHCP

Реализации

Компания Cisco включила сервер DHCP в Cisco IOS 12.0 в феврале 1999 года. Sun добавила DHCP-сервер в Solaris 8 в июле 2001 года.

В настоящее время существуют реализации сервера DHCP для ОС Windows в виде отдельных программ, в том числе открытых^[1], позволяющих выполнять роль сервера DHCP компьютерам под управлением несерверных версий данной ОС.

Примечания

См. также

Ссылки

DHCP сервер, что это такое и как он работает?

Автор Исхаков Максим На чтение 3 мин. Просмотров 155 Опубликовано 13.08.2019 Обновлено 12.08.2019

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

Как работает DHCP?

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

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

На видео: Полноценный разбор протокола DHCP

Динамические IP-адреса не вечны

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

Статические IP-адреса не меняются

Бывают случаи, когда требуется наличие статического IP-адреса, который никогда не меняется. Например, сетевые принтеры легче найти, если у них тот же IP. Но сама процедура получения статического IP-адреса не стандартная. Это всегда связано с MAC-адресом устройства, а точнее с конкретным клиентом. Некоторые роутеры “резервируют IP-адреса”, чтобы он стал статическим для конкретного устройства, подключенного к сети.

Нужно ли настраивать DHCP?

Если вам не нужно устанавливать неизменный IP-адрес для какого либо-устройства, то вряд ли вам понадобится погружаться в тонкости настроек DHCP, который сделает все автоматически. Но если сетевое подключение не произошло само, то перейдите в Панель управления > Сеть и Интернет > Сетевые подключения, так вы получите доступ к свойствам вашего подключения. Здесь вы найдете параметр “Получить IP-адрес автоматически”, включите “Включить DHCP” и ваше устройство, с которого вы подключаетесь получит свой адрес IP по этому протоколу.

Как использовать DHCP для защиты сети?

Протокол DHCP может предотвратить использование вашей Wi-Fi сети без вашего разрешения. Войдя в панель управления роутера, вы можете задать начальный и конечный IP-адрес. Система DHCP назначит IP-адреса в этом диапазоне. Таким образом, если у вас дома 5 устройств (например: ПК, ноутбук, два смартфона и планшет), вы можете установить адреса в диапазоне, например, от 192.168.1.1 до 192.168.1.5. Шестое устройство (например, ноутбук вашего соседа) не сможет подключиться к вашей домашней сети. Но это также означает, что если к вам придет друг и ему понадобится Wi-Fi, то вам придется перенастроить маршрутизатор специально для него.

Как работают сети: что такое свитч, роутер, DNS, DHCP, NAT, VPN и ещё с десяток необходимых вещей

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

Часто бывает у наших коллег: вроде бы слова IP и DNS используют каждый день, а понимания как это всё работает нет, и как это всё пощупать вживую тоже непонятно. Такое отношение не только некорректно, но и вредно для карьеры любого уважающего себя инженера из IT. Сколько бы JS-фреймворков ты не выучил, без знания основ сетей тебя никто всерьёз воспринимать не будет.
Ни одна часть инфраструктуры не должна оставаться чёрной коробкой ни для разработчиков, ни для администраторов, ни уж тем более для тебя, будущего DevOps инженера.

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

В этом же тексте мы сфокусируемся на структуре сети, основных её компонентах и рассмотрим как они используются на практике при помощи уже освоенных нами в предущей статье виртуальных машин и libvirt/KVM в частности.

Сетевая модель OSI

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

OSI делит коммуникацию на 7 слоёв, на каждом слое есть свои протоколы. Ты часто будешь слышать вещи в духе «это происходит на Layer 3». Вот эти слои:

Физический уровень (physical layer)
Канальный уровень (data link layer)
Сетевой уровень (network layer)
Транспортный уровень (transport layer)
Сеансовый уровень (session layer)
Представительский уровень или уровень представления (presentation layer)
Прикладной уровень (application layer)

Физический уровень (physical layer)

Протоколы этого уровня отвечают за связь между железками на самом низком уровне. Непосредственная передача данных по проводам (и без проводов) описывается как раз на физическом уровне. Примеры протоколов: Wi-Fi, Bluetooth, DSL.

Канальный уровень (data link layer)

Канальный уровень отвечает за передачу данных между устройствами одной сети. Данные передаются в виде кадров (frames), в кадре указан физический адрес получателя и отправителя. Этот адрес называется MAC-адрес.

Кто же выступает в роли отправителя и получателя?

Во-первых, у каждой машины (включая твой ноут) есть NIC — Network Interface Controller. Это железка (или виртуальная железка), которая отвечает за передачу и приём кадров. У NIC есть MAC-адрес — уникальный адрес, который обычно прошит в железке, или же генерируется системой виртуализации.

Само собой, у машины может быть несколько NIC. Посмотрим интерфейсы при помощи команды ip:

[root@localhost ~]$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:05:36:e6 brd ff:ff:ff:ff:ff:ff

В данном случае, интерфейс, использующийся для связи с внешним миром по сети, — это eth0, обладающий MAC-адресом 52:54:00:05:36:e6. Но что такое lo?

lo — это loopback device, специальный виртуальный интерфейс, который система использует, чтобы общаться самой с собой. Благодаря lo даже без подключения к сети локальные приложения могут взаимодействовать друг с другом.

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

Например, свитч (switch).

Свитч — это такое устройство, которое формирует сеть, и в которое подключаются наши машинки через порты. Задача свитча L2 (есть ещё более продвинутые, относящиеся к L3 и даже к L7) — перенаправлять кадры от MAC отправителя к MAC получателя. Множество машин, подключенных к одному свитчу формируют локальную сеть (LAN).

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

Для таких случаев создают VLAN (виртуальную локальную сеть), которую можно реализовать, например, при помощи свитча. Работает это достаточно просто: к кадрам добавляется дополнительный заголовок с VLAN-тегом, по которому и определяется к какой сети принадлежит кадр.

Другое устройство — мост (bridge). Мост L2 используют чтобы объединить две сети, сформированные при помощи свитчей, примерно таким образом:

И свитчи и мосты (а ещё хабы (hub), о которых почитай сам) помогают объединить несколько машин в одну сеть. А есть ещё маршрутизаторы (или роутеры, routers), которые соединяют сети между собой и работают уже на L3. Например, твой Wi-Fi роутер соединяет твою локальную сеть (в которой находятся твой ноутбук, телефон и планшет) с Интернетом.

Помимо LAN разделяют ещё несколько типов сетей. Например, WAN. Интернет можно считать за WAN, за тем исключением, что Интернет полностью стирает географические границы сети.

Как я уже упомянул, есть ещё свитчи L3, которые могут не просто перенаправлять кадры от одного устройства к другому, но и обладают более продвинутыми фишками, типа маршрутизации. Чем же отличается роутер от свитча L3, спросишь ты? Тут всё сложно (и скучно), но если тебе интересно, то прочитай статью Layer 3 Switches compared to Routers

Сетевой уровень (network layer)

На третьем, сетевом уровне используются не MAC, а IP адреса. Посмотрим IP адрес нашей машины при помощи той же самой команды ip:

[root@localhost ~]$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:05:36:e6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.212/24 brd 192.168.122.255 scope global dynamic eth0
       valid_lft 2930sec preferred_lft 2930sec
    inet6 fe80::5054:ff:fe05:36e6/64 scope link
       valid_lft forever preferred_lft forever

Интерфейсу eth0 присвоен адрес 192.168.122.212/24.

Но что такое /24? И почему у loopback интерфейса стоит /8? Ты уже, наверное, слышал, что всего существует 4 294 967 296 IPv4 адресов. Интернет — это не одна большая сеть, а много сетей поменьше. При этом для отдельных типов сетей (например, частных, недоступных извне сетей) выделены отдельные блоки IP адресов.

IPv6 адресов гораздо больше. Но полный переход IPv6 ещё не произошёл 🙂

CIDR — это метод выделения блоков адресов отдельным сетям. А CIDR-нотация — это способ описать этот блок в виде 192.168.122.212/24, где число /24, называемое маской, как раз и позволяет понять, сколько адресов входит в этот блок.

IPv4 — это простое число длинной 32 бита, которое можно представить в двоичном виде. В двоичной форме IP адреса идут от 00000000000000000000000000000000 до 11111111111111111111111111111111. Для удобства разобьём это число на 4 части по 8 цифр: 11111111.11111111.11111111.11111111. В привычной нам десятеричной системе этот адрес выглядит так: 255.255.255.255.

Маска /24 может быть представлена как 255.255.255.0, или, в двоичной системе, 11111111.11111111.11111111.00000000. Чтобы найти первый и последний адреса сети мы можем использовать один из адресов и маску сети, применив логическое побитовое И на их двоичном представлении:

11000000.10101000.01111010.11010100
&
11111111.11111111.11111111.00000000
=
11000000.10101000.01111010.00000000

И переведём результат в человеко-читаемую форму: 192.168.122.0 — начальный адрес нашей сети. Чтобы подсчитать число доступных адресов, нужно посчитать число нулей в маске. В нашем случае нулей, или разрядов, 8. Каждый может принимать значение 1 или 0, поэтому в сумме получаем 2^8 степени, или 256 адресов. Значит, последний адрес сети будет равен 192.168.122.255.

Вручную всё считать необязательно, можно воспользоваться калькулятором.

ARP

Мы уже знаем, что на L2 используются MAC-адреса, а на L3 — IP адреса. Должен существовать какой-то механизм, который ассоциирует MAC-адрес сервера с его IP адресом. Этот механим называется ARP (Address Resolution Protocol).

В Линуксе есть одноимённая команда arp, которая позволит посмотреть табличку известных машине MAC-адресов и соответствующих им IP адресов:

[root@localhost]# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.178.1 ether 5c:49:79:99:f3:23 C wlp3s0

В данном случае, 192.168.178.1 — это IP адрес моего Wi-Fi роутера, к которому ноутбук подключен через интерфейс wlp3s0.

Команда arp считается deprecated и вместо неё рекомендуется использовать ip neigh.

Один из видов кибер-атак связан с ARP и называется ARP spoofing. Цель такой атаки — подменить MAC-адрес, ассоциированный с определённым IP, на адрес машины хакера. Как страшно жить, да?

DHCP

Но как именно у сетевого интерфейса появляется IP адрес? Один из вариантов — задать его вручную. Недостаток: ручная работа. Если руки кривые, то можно настроить дублирующиеся адреса и получить конфликт 🙂

Другой вариант: Dynamic Host Configuration Protocol (DHCP), протокол, использующийся для автоматического выставления различной конфигурации, в том числе IP-адресов.

За детальным изучением DHCP обратись к документации в RFC: https://www.ietf.org/rfc/rfc2131.txt

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

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

Как это происходит в случае с DHCP:

DHCP-клиент отправляет broadcast сообщение с вопросом «Хочу IP адрес»
DHCP-сервер его ловит и в ответ отправляет так же broadcast сообщение «У меня есть адрес x.x.x.x, хочешь его?»
DHCP-клиент получает это сообщение и отправляет ещё одно: «Да, я хочу адрес x.x.x.x»
DHCP-сервер отвечает «Хорошо, тогда x.x.x.x принадлежит тебе»

Вот в этом видео чуть более наглядно показан весь процесс: https://www.youtube.com/watch?v=RUZohsAxPxQ

А где хранятся настройки соединений?

Настройки сетевых подключений хранятся в /etc/sysconfig/network-scripts. Там ты можешь отредактировать такие вещи, как способ получения IP адреса (автоматический или статичный), стартовать ли соединение автоматически при загрузке системы и т.п. Например, вот так выглядит мой конфиг для Wi-Fi-соединения:

[root@localhost network-scripts]# cat ifcfg-FRITZ-Box_7490
HWADDR=4C:34:88:54:C1:2B
ESSID="FRITZ!Box 7490"
MODE=Managed
KEY_MGMT=WPA-PSK
TYPE=Wireless
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME="FRITZ!Box 7490"
UUID=55ba9218-1d2f-407d-af13-51502d542edb
ONBOOT=yes
SECURITYMODE=open
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

Обрати внимание на BOOTPROTO=dhcp — эта опция означает, что будет использован DHCP-сервер, в том числе для получения IP адреса. Для сравнения, конфиг соединения для loopback устройства:

[root@localhost network-scripts]# cat ifcfg-lo
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback

Здесь прописан статичный адрес: IPADDR=127.0.0.1. В домашнаних условиях вместо редактирования конфигов вручную можно использовать утилиту nmcli, либо установить пакетик NetworkManager-tui, который предоставит удобный текстовый интерфейс прямо в консоли. В боевых условиях на серверах лучше так не делать, а использовать систему конфигурации (Puppet, Chef, Salt).

Ещё одна важная часть конфигурации: роутинг. Как понять, куда именно побежит трафик? Всё просто: достаточно посмотреть локальную таблицу роутинга при помощи команды ip r. На момент написания этих строк я сижу в кофейне с ноутбука, который использует телефон как роутер. Вот что мне выдаёт ip r:

default via 172.20.10.1 dev wlp3s0 proto static metric 600
172.20.10.0/28 dev wlp3s0 proto kernel scope link src 172.20.10.3 metric 600
192.168.100.0/24 dev virbr2 proto kernel scope link src 192.168.100.1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

Как видишь, весь трафик идёт по-умолчанию на машинку с адресом 172.20.10.1. А если выполнить ip addr show, то можно увидеть, что у сетевого интерфейса в ноутбуке так же есть IP адрес из этой сети:

4: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 4c:34:88:54:c1:2b brd ff:ff:ff:ff:ff:ff
    inet 172.20.10.3/28 brd 172.20.10.15 scope global dynamic wlp3s0
       valid_lft 83892sec preferred_lft 83892sec
    inet6 fe80::4e34:88ff:fe54:c12b/64 scope link
       valid_lft forever preferred_lft forever

Командой ip r add можно добавлять новые пути, а командой ip r del — удалять.

DNS

Про DNS ты наверняка слышишь не в первый раз. Простая идея: обращаться к серверу не по IP адресу (тяжело запомнить для людей), а по нормальному имени.

Самый старый и популярный DNS-сервер (тот, что хранит информацию об адресах и отвечает на запросы) — это BIND. Альтернатив тоже много, но тебе в первую очередь рекомендуется развернуть локально именно BIND.

Обязателен к прочтению материал от Cisco DNS Best Practices, Network Protections, and Attack Identification — там узнаешь не только все основы DNS, но и кучу важных рекомендаций по созданию безопасного и устойчивого DNS-сервера.

Есть возможность обновлять записи в DNS-сервере динамически. Для этого почитай про nsupdate. Ниже найдёшь ссылку на отличное руководство по настройке, включая безопасное обновление записей. Одно из интересных применений — service discovery. Поищи в Интернете, о чём это, или дождись соответствующей статьи на mkdev 😉

До появления DNS всё, что у нас было — это файлик /etc/hosts. Он и сейчас часто используется.

Рубрика «Вирусы для чайников»! Открываем /etc/hosts на компьютера друга и добавляем туда строчку 52.28.20.212 vk.com. Хватит другу сидеть вконтакте, пусть учится разработке!

Ещё очень интересен файлик /etc/nsswitch.conf. В нём определяется в каком порядке и где искать разную информацию, в том числе где искать хосты. По-умолчанию, сначала они ищутся в /etc/hosts, а уже потом отправляется запрос в DNS-сервер.

Используемый для разрешения DNS-имён сервер, кстати, указан в /etc/resolv.conf.

Дебажить DNS проблемы удобнее всего командой dig и nslookup. Например, чтобы запросить информацию о mkdev.me у nameserver 8.8.8.8 можно сделать так:

# dig mkdev.me @8.8.8.8

; <<>> DiG 9.10.3-P4-RedHat-9.10.3-12.P4.fc23 <<>> mkdev.me @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3320
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mkdev.me. IN A

;; ANSWER SECTION:
mkdev.me. 299 IN A 52.28.20.212

;; Query time: 355 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 27 12:51:04 CEST 2016
;; MSG SIZE rcvd: 53

Виртуалки

До этого момента все примеры выполнялись на локальной машине. Это, конечно, полезно для восприятия, но не так интересно. Поэтому дальше мы укрепим только что прочитанное при помощи виртуальных машин и libvirt, а заодно познакомимся с ещё парой терминов.

В первую очередь, создадим виртуалку при помощи virt-install:

sudo virt-install --name mkdev-networking-basics-1 \
--location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \
--initrd-inject /path/to/ks.cfg \
--extra-args ks=file:/ks.cfg \
--memory=1024 --vcpus=1 --disk size=8

По-умолчанию libvirt создаёт одну сеть:

[root@localhost]# virsh net-list
 Name State Autostart Persistent
----------------------------------------------------------
 default active yes yes

Блок 192.168.0.0/16 выделен для частных сетей. libvirt выделил для своей сети блок 192.168.122.212/24, то есть все адреса от 192.168.122.0 до 192.168.122.255.

Чтобы посмотреть подробную информацию о конкретной сети можно использовать либо virsh net-info, либо virsh net-dumpxml. Вторая команда вернёт гораздо больше деталей, поэтому используем её:

[root@CentOS-72-64-minimal ~]# virsh net-dumpxml default
<network connections='1'>
  <name>default</name>
  <uuid>f2ee9249-6bed-451f-a248-9cd223a80702</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:83:b4:74'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

connections показывает количество машинок, подключённых к этой сети. Подробное описание всех возможных опций этого XML-файла можно прочитать в документации libvirt. Нас же сейчас интересуют два слова: bridge и dhcp.

bridge, или устройство virbr0, или virtual network switch — это специальное устройство, в которое подсоединяются все виртуалки этой сети. Все запросы от одной виртуалки к другой в пределах одной сети идут через этот виртуальный свитч. Для каждой сети libvirt создаёт по одному виртуальному свитчу и каждый свитч распознаётся как отдельное устройство на хост машине:

[root@localhost]# ip link show
8: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 52:54:00:a8:02:f2 brd ff:ff:ff:ff:ff:ff

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

Реализован свитч virbr0 при помощи Linux Bridge — технологии, изначально предназначенной как раз для создания виртуальных локальных сетей. Выполнив команду brctl show на хост-машине можно увидеть список всех свитчей.

Linux Bridge «слегка» отличается от типичного железного свитча L2. За годы его существования к нему прилепили множество дополнительных фич, например, фильтрацию трафика и файрвол. Корректнее всего назвать его свитчем L3, но здесь ваш покорный слуга не уверен до конца.

Теперь обратим внимание на следующую секцию:

  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>

Здесь указан блок адресов, использующихся для виртуальных машин в этой сети. 192.168.122.1 — IP-адрес хост-машины в пределах этой виртуальной сети.

Выполнив ip r в виртуалке увидим:

[vagrant@localhost ~]$ ip r
default via 192.168.122.1 dev eth0 proto static metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.209 metric 100

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

Как мы уже знаем, за назначение IP адресов отвечает служба DHCP. Libvirt использует dnsmaq для DHCP и DNS и запускает по экземпляру dnsmasq для каждой сети.

`[root@CentOS-72-64-minimal ~]# ps aux | grep dns
nobody 10600 0.0 0.0 15548 856 ? S Apr01 0:02 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
root 10601 0.0 0.0 15520 312 ? S Apr01 0:00 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper

Мы можем посмотреть табличку DHCP, которая покажет нам выданные адреса:

[root@loclahost]# virsh net-dhcp-leases default
 Expiry Time MAC address Protocol IP address Hostname Client ID or DUID
-------------------------------------------------------------------------------------------------------------------
 2016-04-29 16:31:19 52:54:00:05:36:e6 ipv4 192.168.122.212/24 - -

Обрати внимание, что 52:54:00:05:36:e6 это MAC-адрес интерфейса eth0 нашей виртуалки.

NAT

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

Это так же и верно для наших виртуалок. У каждой есть частный IP-адрес из блока 192.168.122.0/24, и все они скрываются за публичным адресом хост-машины.

Хост-машина, если мы продолжаем использовать для неё свой личный ноутбук у себя дома, прячется на Wi-Fi роутером и так же не обладает собственным публичным адресом.

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

Эту проблему решает NAT (Network Address Translation) — механизм преобразования IP адресов в сетевых пакетах. Обычно в пакете указан IP, откуда пакет отправлен и IP, куда пакет идёт. NAT позволяет динамически менять эти адреса и сохранять таблицу подменённых адресов.

Существует SNAT (source NAT), который и используется для наших виртуалок для доступа в Интернет. Когда пакет отправляется, то его исходящий адрес заменяется на адрес хост машины. Когда ответ от сервера назначения идёт назад, то адрес меняется с адреса хост машины на адрес виртуалки. Меняет адрес роутер.

DNAT (destination NAT) занимается примерно тем же самым, но наоборот: это когда ты обращаешься к некоему публичному адресу, за которым скрываются частные, локальные адреса.

NAT — способ по умолчанию для общения виртуалок с внешним миром. Но libvirt штука гибкая. Можно, например, цеплять виртуалки напрямую к физическому интерфейсу хоста, вместо виртуального свитча. Вариантов создания сети, на самом деле, много.

Для NAT libvirt использует iptables. Если кратко, то это инструмент, отвечающий за фильтрацию сетевых пакетов. iptables настраиваются через специальные правила (rules), которые комбинируются в цепочки (chains). Вот путём добавления таких правил libvirt и добавляет нашим виртуалкам доступ в Интернет, используя NAT. Мы вернёмся к iptables когда будем говорить о безопасности в целом.

Ещё для того чтобы на хосте работало перенаправление пакетов в настройках ядра должна быть включена опция ipforward. Включается она просто: `echo 1 > /proc/sys/net/ipv4/ipforward`

tcpdump

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

Открываем консоль на хост-машине и делаем tcpdump -i virbr0.

Открываем отдельное окошко и делаем virsh reboot #{номер_виртуалки}.

Смотрим результат в первом окошке и видимо откуда какие запросы пришли:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on virbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:57:31.339135 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
12:57:31.397937 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:e0:06:54 (oui Unknown), length 300
12:57:31.398182 IP linux.fritz.box.bootps > 192.168.122.209.bootpc: BOOTP/DHCP, Reply, length 301
12:57:31.590332 ARP, Request who-has linux.fritz.box tell 192.168.122.209, length 28
12:57:31.590373 ARP, Reply linux.fritz.box is-at 52:54:00:7e:33:23 (oui Unknown), length 28
12:57:31.590409 IP 192.168.122.209.38438 > linux.fritz.box.domain: 61342+ A? 0.centos.pool.ntp.org. (39)
12:57:31.590458 IP 192.168.122.209.38438 > linux.fritz.box.domain: 25671+ AAAA? 0.centos.pool.ntp.org. (39)
12:57:31.590618 IP linux.fritz.box.domain > 192.168.122.209.38438: 25671 0/0/0 (39)
### И так далее

Вот, например, broadcast от виртуалки: 12:57:31.397937 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:e0:06:54 (oui Unknown), length 300.

Ну и заодно глянем ARP табличку:

Address HWtype HWaddress Flags Mask Iface
# ...
192.168.122.209 ether 52:54:00:e0:06:54 C virbr0
# ...

VPN

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

По сути VPN — это вложение одного tcp/ip пакета в другой и шифрование содержимого. Получается виртуальная сеть работающая внутри реальной сети. Для виртуальных сетей создаются виртуальные сетевые устройства (tun/tap) с виртуальными же IP адресами, видимыми только внутри нашей виртуальной зашифрованной сети.

Я оставлю настройку VPN за пределами этой статьи. На совести читателя останется попробовать это сделать самостоятельно при помощи OpenVPN или strongSwan.

Мы ещё вернёмся к тебе безопасности, но ты уже можешь почитать про IPsec — этот протокол использует strongSwan.

Для самостоятельного изучения

Мы только что пробежались по самым основам сетей, но, конечно же, есть ещё с десяток технологий, которые стоит посмотреть. Погугли самостоятельно VXLAN, изучи TCP и UDP (и разберись когда какой использовать), глянь что такое ICMP. Ты постоянно будешь сталкиваться с новыми терминами, но, как и всегда, главное — усвоить основы.

Мы не поднялись до более высоких уровней модели OSI, не посмотрели различные протоколы, с которыми работают веб-приложения: HTTP(S), FTP, SSH, NTP и многие другие.

Не забывай заглядывать в RFC. Это первая остановка в поиске нужной тебе информации по сетям.

Мы, скорее всего, вернёмся к этим темам в последующих статьях. Для меня лично сложнее всего было раньше понять именно то, как всё работает на уровнях ниже уровня приложения: все эти сети, подсети, непонятные проблемы с доступом от одного сервера к другому и т.п.

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

Что дальше?

Я знаю, что дорогой читатель ждёт-недождётся, когда я начну рассказывать про Chef, Puppet, Ansible и прочие модные штуки. Но рано, пока ещё рано. Нас ждёт ещё как минимум одна статья подобного рода, в которой мы рассмотрим все возможные способы аутенфицировать и авторизовывать пользователей и сервера, тем самым сильно копнув в сторону темы безопасности в целом.

Дополнительное чтение

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

Что такое DHCP Snooping и как это работает? / Хабр

«Почему я не могу подключиться к сети, даже если мой ноутбук получил IP-адрес динамически?» Сталкивались ли вы с этой проблемой в повседневной жизни? Вы сомневались в подлинности IP-адресов? Получены ли они с авторизованного DHCP-сервера? Если нет, как предотвратить это? В этой статье будет введен термин DHCP Snooping, чтобы помочь пользователям избежать использование незаконных IP-адресов.

Что такое DHCP Snooping?

DHCP Snooping — это технология безопасности уровня 2, встроенная в операционную систему работоспособного сетевого коммутатора, которая отбрасывает трафик DHCP, определенный как неприемлемый. DHCP Snooping предотвращает несанкционированные (мошеннические) DHCP-серверы, предлагающие IP-адреса DHCP-клиентам. Функция DHCP Snooping выполняет следующие действия:

Проверяет сообщения DHCP из ненадежных источников и отфильтровывает недействительные сообщения.

Создает и поддерживает базу данных привязки DHCP Snooping, которая содержит информацию о ненадежных хостах с арендованными IP-адресами.

Использует базу данных привязки DHCP Snooping для проверки последующих запросов от ненадежных хостов.

Как работает DHCP Snooping ?

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

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

На этапе подтверждения, будет создана таблица привязки DHCP в соответствии с сообщением DHCP ACK. Он записывает MAC-адрес хоста, арендованный IP-адрес, время аренды, тип привязки, а также номер VLAN и информацию об интерфейсе, связанную с хостом, как показано на рисунке 3. Если последующий пакет DHCP, полученный от ненадежного хоста, не совпадает с информацией, он будет удален.

Основные типы Атак, предотвращаемые DHCP Snooping

Спуфинговая атака DHCP

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

DHCP Starvation (истощение ресурсов DHCP)

Истощение ресурсов DHCP обычно нацелено на сетевые DHCP-серверы с целью наполнить авторизованный DHCP-сервер сообщениями DHCP REQUEST с использованием поддельных MAC-адресов источника. Сервер DHCP будет отвечать на все запросы, не зная, что это атака с истощением DHCP, назначая доступные IP-адреса, что приводит к истощению пула DHCP.

Как включить отслеживание DHCP?

DHCP Snooping применим только к проводным пользователям. Как функция безопасности уровня доступа, она в основном включена на любом коммутаторе, содержащем порты доступа VLAN, обслуживаемой DHCP. При развертывании DHCP Snooping необходимо настроить доверенные порты (порты, через которые будут проходить допустимые сообщения DHCP-сервера), прежде чем включать DHCP Snooping в VLAN, которую вы хотите защитить. Это может быть реализовано как в интерфейсе CLI, так и в веб-интерфейсе.

Заключение

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

Что такое протокол DHCP и как он работает?

Протокол DHCP

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

Как работает протокол DHCP?

Хост, подключающийся к сети (кабельной или беспроводной), отправляет сообщение об обнаружении DHCP всем хостам в сегменте уровня 2 (адрес назначения — FF: FF: FF: FF: FF: FF).Кадр с этим сообщением DISCOVER попадает на DHCP-сервер.

2. После того, как DHCP-сервер получает сообщение об обнаружении, он предлагает клиентскому хосту предложение IP-адресации путем одноадресной рассылки. Это сообщение ПРЕДЛОЖЕНИЕ содержит:

предлагаемый IP-адрес для клиента (здесь 192.168.1.10)

Маска подсети

для определения пространства подсети (здесь 255.255.255.0)
IP шлюза по умолчанию для подсети (здесь 192.168.1.1)
IP DNS-сервера для трансляции имен (здесь 8.8.8.8)
Options (читать статью полностью)

3. Теперь, когда клиент получает предложение, он запрашивает информацию, официально отправляя на сервер сообщение REQUEST , на этот раз по одноадресной передаче.

4. Сервер отправляет клиенту сообщение ACKNOWLEDGE , подтверждающее аренду DHCP. Теперь клиенту разрешено использовать новые настройки IP.

Какая информация по протоколу DHCP необходима, а какая необязательна?

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

В дополнение к необходимым параметрам DHCP существуют такие параметры DHCP, как популярная опция 150, используемая в IP-телефонии для информирования IP-телефонов об IP-адресе IP-УАТС для правильной регистрации телефона — например, Cisco Call Manager или Asterisk PBX.Почти все поставщики DHCP-серверов могут передавать параметры DHCP.

Что делать, если DHCP-сервер не находится в той же подсети?

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

Узнайте, как настроить DHCP-сервер на сетевом устройстве.

Что такое опция DHCP | EfficientIP

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

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

Экран бездискового дисплея X11 больше не существует, но многие устройства могут воспользоваться преимуществами настройки во время доступа к сети — например, устройства IoT. BOOTP, который привносит дополнительную конфигурацию параметров в исторический протокол RARP (см. RFC903), который предоставляет только IP-адрес, сам развился в протокол DHCP. Благодаря управлению пулом и мобильности устройств DHCP также может обрабатывать широкий список параметров для настройки множества различных устройств.

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

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

Общие параметры

Вот список наиболее распространенных опций DHCP, которыми обмениваются клиенты:

Опция DHCP 1 : маска подсети, которая будет применяться к интерфейсу, запрашивающему IP-адрес
Опция DHCP 3 : маршрутизатор по умолчанию или шлюз последней инстанции для этого интерфейса
Параметр DHCP 6 : какой DNS (сервер доменных имен) включить в конфигурацию IP для разрешения имен
Параметр DHCP 51 : время аренды для этого IP-адреса

Интересные опции

Ниже приведен список других интересных опций, которые могут быть предоставлены клиентам для упрощения их первоначальной настройки:

Опция DHCP 2 : смещение времени в секундах от UTC для применения к текущему времени (примечание: не рекомендуется по RFC4833 — опции 100 и 101)
Опция DHCP 4 : список серверов времени, как указано в RFC868 (протокол времени)
Опция DHCP 9002 0 12 : имя хоста клиента, очень полезно для IoT и любого устройства без пользователя
Параметр DHCP 15 : указывает имя домена, которое клиент должен использовать в качестве суффикса при разрешении имен хостов через систему доменных имен
Параметр DHCP 42 : список серверов NTP в порядке предпочтения, используемых для синхронизации времени клиента.
Параметр DHCP. . 58 и 59: значение времени обновления (T1) и значение времени повторной привязки (T2).См. Главу «Управление сроком аренды DHCP» в разделе Что такое DHCP?
Параметры DHCP 69 и 70: соответственно для серверов SMTP и POP3 для отправки и получения электронной почты. Мы часто видим эти параметры на принтерах и сканерах.
Параметр DHCP 81 : Полное доменное имя клиента — этот параметр позволяет выполнять автоматическое обновление записей DNS, связанных с клиентом, в основном A и PTR. В этой опции мы можем указать, будет ли клиент или сервер обновлять записи и полное доменное имя, связанное с клиентом.Он определен в RFC4702
параметр DHCP 100 : строка POSIX часового пояса, как в IEEE 1003.1
Параметр DHCP 101 : часовой пояс в виде строки, как в базе данных TZ (например: Европа / Париж)
DHCP option 119 : список поиска DNS-домена, который будет использоваться для выполнения DNS-запросов на основе короткого имени с использованием суффиксов, представленных в этом списке.
Параметр DHCP 121 : таблица бесклассовых статических маршрутов, состоящая из нескольких сетей и масок подсети, эта опция заменяет исходную под номером 33 (см. RFC3442)

Параметры клиента

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

В этом случае используются две основные опции: идентификатор класса поставщика (опция 60) и идентификатор клиента (опция 61). Идентификатор клиента уникален и помогает DHCP-серверу управлять своими клиентами и арендой. Обычно он устанавливается на MAC-адрес сетевого интерфейса в локальной сети. Идентификатор класса поставщика более интересен, поскольку он определяет тип поставщика и конфигурацию DHCP-клиента в простой строке символов.Формат открыт и может быть интерпретирован сервером для корректировки вариантов ответа и содержимого.

Анализируя идентификатор клиента, идентификатор класса и список запрашиваемых опций на первом этапе запроса DHCP, помогает профилировать клиента и предоставить ему соответствующий ответ.

Пример

На портативном компьютере под управлением Windows 10 параметры, включенные в начальный кадр DHCP Discover, могут выглядеть так:

параметр 61: Идентификатор клиента = 00: e0: 4c: 36: 0a: ac
параметр 12: Имя портативного компьютера
опция 60: Идентификатор класса поставщика, здесь установлено значение MSFT 5.0 (для Microsoft Windows 10)
опция 55: Список запросов параметров установлен на:
- 1: Маска подсети
- 3: Маршрутизатор
- 6: Сервер доменных имен
- 15: Доменное имя
- 31: Выполнить обнаружение маршрутизатора
- 33: Статический маршрут
- 43: Информация производителя
- 44: NetBIOS через сервер имен TCP / IP
- 46: NetBIOS через TCP / IP тип узла
- 47: NetBIOS через TCP / IP Область
- 119: Поиск домена
- 121: Бесклассовый статический маршрут
- 249: Частный / бесклассовый статический маршрут Microsoft
- 252: Автообнаружение частного / прокси

Для информации, этот конкретный список запросов параметров идентифицируется как «Операционная система / ОС Windows / Microsoft Windows» Ядро 10.0 »с помощью Fingerbank API.

Что такое аренда DHCP | EfficientIP

Аренда DHCP — это временное присвоение IP-адреса устройству в сети. При использовании DHCP для управления пулом IP-адресов каждый клиент, обслуживаемый в сети, только «арендует» свой IP-адрес. Таким образом, IP-адреса, управляемые DHCP-сервером, назначаются только на ограниченный период времени.

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

Продолжительность аренды DHCP выражается в секундах. Его можно указать как «бесконечный» для постоянной аренды, обычно используемой для устройств, которые не должны менять свой IP-адрес без необходимости изменения своей конфигурации (некоторые IOT, принтеры или серверы приложений).

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

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

Windows Server: интеграция между DNS и DHCP — статьи TechNet — США (английский)

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

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

Поскольку DNS и DHCP являются основой ИТ-инфраструктуры организации, изменение любых настроек в производственной среде может иметь серьезные последствия.В связи с этим следует хорошо спланировать интеграцию между DNS и DHCP.
перед внедрением и должен быть частью HLD (High-Level Design) или LLD (Low-Level Design).

В этой статье предполагается несколько вещей:

Мы используем встроенный DNS Active Directory.
Мы используем DHCP-сервер Windows.

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

Как известно, записи DNS могут быть статическими или динамическими.Статические записи создаются вручную, либо через консоль DNS, либо программно с помощью какого-либо скрипта. С другой стороны, динамические записи регистрируются DNS-клиентом или DHCP.
Сервер.
Когда реализован DHCP, по умолчанию записи PTR регистрируются в DNS сервером DHCP, тогда как записи узла (A) регистрируются клиентом DHCP. Это связано с тем, что клиент является источником имени хоста и DHCP.
является источником IP-адреса.
Начиная с Windows Server 2008 / Vista, именно DHCP регистрирует записи A и PTR от имени клиента, независимо от того, запрашивает ли клиент DHCP-сервер для выполнения обновления или нет.Конечно, если IP-адрес статически
назначенный клиенту, DHCP не играет роли, и в этом случае клиент обновляет запись.

Рекомендуется, чтобы DHCP обновлял записи A и PTR для всех клиентов, получающих IP-адрес от DHCP.

Для этого выберите этот параметр: Всегда динамически обновлять записи DNS A и PTR.

Если выбрана эта опция, DHCP-сервер будет обновлять записи A и PTR, как только он назначит IP-адрес DHCP-клиенту, и не будет проверять, запрашивает ли клиент DHCP-сервер регистрацию / обновление записи DNS.Мы всегда
рекомендую использовать эту опцию.

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

Теперь, когда мы знаем основы, давайте рассмотрим подробнее.

Интегрированная зона DNS AD предлагает три различных параметра безопасности, связанных с обновлением динамического DNS (DDNS):

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

Примечание
Опция Только безопасная доступна, только если зона DNS интегрирована с AD.

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

Когда мы настраиваем вариант 3 (только безопасное динамическое обновление), есть еще один важный момент, который нам необходимо учитывать, а именно разрешение записи DNS (ACL).

Когда параметр динамического обновления настроен как «Безопасный и небезопасный», ACL для конкретной записи отсутствует, и все записи наследуют ACL из зоны DNS. В этом параметре любой источник может создать новую запись, а также обновить
существующая запись.

Однако все меняется, когда мы меняем настройки на «Только безопасный» .В этой настройке:

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

Предположим, что IP-адрес назначается сервером Server1 напрямую, а не DHCP.Таким образом, Server1 зарегистрирует запись на DNS-сервере и станет владельцем записи. В следующий раз только server1
может обновить эту запись, если мы изменим ее IP-адрес. Здесь нет роли DHCP.

Обратите внимание, что, поскольку зона принимает только безопасные обновления, Server1 должен быть членом домена AD, чтобы он мог регистрировать / обновлять запись на DNS-сервере.

Теперь предположим, что у нас есть рабочая станция с именем WS1. IP-адрес назначается DHCP-сервером A, поэтому запись DNS будет зарегистрирована и принадлежать DHCP-серверу A.Никакая другая система, включая WS1 или любой другой DHCP-сервер, не может обновлять
эта запись.

У подхода есть серьезный недостаток, когда один DHCP-сервер становится владельцем огромного количества записей. Что произойдет, если исходный DHCP-сервер выйдет из строя, и мы развернем новый DHCP-сервер?

Может ли новый DHCP-сервер обновить все записи, которые были зарегистрированы (и принадлежали) предыдущему DHCP-серверу?

Ответ — НЕТ.

Предположим, что DHCP-сервер A зарегистрировал 5000 записей на DNS-сервере, а затем по какой-то причине произошел сбой.Мы ввели в эксплуатацию новый DHCP-сервер, которым является DHCP-сервер B. Но DHCP-сервер B НЕ сможет обновить эти 5000 записей.
которые были зарегистрированы и принадлежали DHCP-серверу A. Даже если мы переименуем DHCP-сервер B в DHCP-сервер A, проблема не будет решена, поскольку ACL работает через SID, а не по имени хоста. SID учетной записи компьютера DHCP-сервера A и DHCP-сервера B никогда не будет одинаковым.

Microsoft предлагает решение этой проблемы. Есть встроенная группа под названием
DnsUpdateProxy , который можно (и нужно) использовать в этом сценарии.

Как использовать DnsUpdateProxy Group

Шаг 1: Первое, что нам нужно сделать, это поместить DHCP-серверы в группу DnsUpdateProxy. Обратите внимание, что это глобальная группа безопасности, поэтому она не позволяет добавлять какой-либо DHCP-сервер.
которого нет в текущем домене.

Шаг 2: Теперь создайте учетную запись пользователя (службы) в Active Directory, которая будет использоваться всеми DHCP-серверами во время безопасного динамического обновления.Назовите учетную запись как-то вроде , чтобы мы могли понять
позже цель этого аккаунта.

Эта учетная запись должна быть создана в том же домене AD, где мы добавили DHCP-серверы в группу DnsUpdateProxy на шаге 1. Однако Microsoft подтверждает, что можно создать учетную запись в другом лесу, если лес
доверие настроено.

Шаг 3 : Следующим шагом будет настройка этой учетной записи и учетных данных пользователя, которые мы создали на шаге 2.Эти учетные данные будут использоваться всеми DHCP-серверами для безопасной регистрации записи на DNS-сервере. Эта
необходимо настроить на каждом DHCP-сервере, который мы добавили в группу DnsUpdateProxy.

Чтобы настроить это, щелкните правой кнопкой мыши IPv4
> Продвинутый > Учетные данные .

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

Повторите шаг 3 для всех DHCP-серверов, которые мы добавили в группу DnsUpdateProxy.

На этом настройка динамического обновления завершена.

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

Преимущества такого подхода:

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

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

Чтобы проиллюстрировать сценарий, предположим, что мы настроили учетную запись пользователя «dhcp_update» на DHCP-сервере A. Этот DHCP-сервер является членом группы DnsUpdateProxy. Теперь, когда DHCP-сервер A будет регистрировать записи в DNS, те
записи будут принадлежать «dhcp_update», а не DHCP-серверу A.

Теперь предположим, что DHCP-сервер A дает сбой, и мы развернули новый DHCP-сервер B. Мы добавили DHCP-сервер B в группу DnsUpdateProxy и настроили те же учетные данные, которые были настроены на DHCP-сервере A.Теперь DHCP-сервер
B может обновлять все записи, которые были зарегистрированы DHCP-сервером A, поскольку эти записи принадлежат учетной записи «dhcp_update», а не DHCP-серверу A.

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

Как подтвердила Microsoft, мы должны настроить выделенную учетную запись пользователя и настроить DHCP-сервер с учетными данными в следующих случаях:

Контроллер домена настроен для работы в качестве DHCP-сервера
DHCP-сервер настроен на выполнение динамических обновлений DNS от имени DHCP-клиентов.
Зоны DNS, обновляемые DHCP-сервером, настроены так, чтобы разрешать только безопасные динамические обновления.

Теперь предположим сценарий, в котором организация имеет зону DNS, интегрированную в AD, где параметры динамического обновления настроены как «Небезопасный и безопасный». После недавнего аудита безопасности они выявили этот недостаток безопасности.
и решил изменить его на «Только безопасный». Что нужно учитывать перед изменением типа безопасности зоны? Давайте рассмотрим эти моменты:

Поскольку это уже существующая зона, в которой уже ведется работа, есть тысячи живых записей.
Это действие не повлияет на те записи, которые создаются статически. Как правило, это устройства, отличные от Windows, которые не поддерживают DDNS, например устройства хранения данных, сетевые устройства. Кроме того, начиная с Windows Server 2008, весь домен
Контроллеры регистрируют статические записи DNS во время повышения DC. Однако, если мы удалим статическую запись контроллера домена, в следующий раз эта же запись будет зарегистрирована как динамическая.
По крайней мере 80% этих записей являются динамическими, то есть они обновляются / обновляются через определенный интервал либо самой системой, либо DHCP-сервером.
Поскольку текущие параметры динамического обновления следующие: Разрешить небезопасное и безопасное обновление, ACL не связан ни с одной из этих динамических записей, и все записи унаследовали ACL (разрешение) от родительской зоны DNS.
В тот момент, когда мы изменим тип зоны с небезопасного на безопасный, ACL появится в картине, и он НЕ позволит обновить какие-либо из этих динамических записей, потому что не будет найдена соответствующая запись (ACE) с подходящей
разрешение на изменение записи.
Изменение типа зоны может не привести к немедленному отключению, так как все записи не будут обновлены одновременно. Однако со временем, когда система получит новые IP-адреса и попытается обновить соответствующие записи DNS,
эти попытки не увенчаются успехом, что вызовет большие проблемы и сделает всю среду нестабильной.

Теперь, когда мы определили потенциальный риск, приступим к решению.

Случай 1: Для тех систем, где IP-адреса назначаются вручную

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

То, что мы пытаемся достичь, будет примерно таким:

Имя записи DNS	Запись для добавления в ACL записи
Сервер1	Учетная запись компьютера Сервера 1
Сервер2	Учетная запись компьютера Сервера 2
Сервер3	Учетная запись компьютера Сервера 3

Но как этого добиться? Как это сделать для огромного количества записей?

Я создал два сценария PowerShell, которые могут здесь помочь:

Скрипт 1:
Получите право собственности на несколько записей DNS

Скрипт 2:
Установка и удаление записей DNS ACL

Используя второй сценарий, мы можем изменить ACL для массовых записей DNS. Приведенные выше ссылки рассказывают нам, как использовать эти сценарии.

Случай 2: Для тех систем, где IP-адреса назначаются через DHCP

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

Опять же, мы должны запустить тот же сценарий для обновления ACL существующих записей и добавить учетную запись «DHCP_Update» в ACL с полным контролем.

Как разделить случай 1 и случай 2?

Предположим, что существует 5000 динамических записей, некоторые из которых обновляются самой системой (Случай 1), а некоторые обновляются сервером DHCP (Случай 2).

Как это отделить?

Один из способов — использовать первый сценарий и получить владельца записи.Если владельцем является сама система, запись регистрируется и будет обновляться системой. Если владельцем является DHCP-сервер, запись регистрируется и будет
обновляется DHCP-сервером.

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

Таким образом, в этом подходе к каждой динамической записи будут добавлены две записи с разрешением полного управления:

Учетная запись системного компьютера.
Учетная запись пользователя (службы) DHCP: в данном случае «DHCP_Update».

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

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

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

Давайте теперь обсудим распространенный сценарий, когда DHCP-сервер авторизован в лесу AD и обслуживает DHCP-клиентов из нескольких доменов в этом лесу. Теперь, когда DHCP-сервер зарегистрирует DNS-запись, какой DNS-домен он будет
выбрать регистрацию записи?

Рассмотрим сценарий ниже:

У нас есть подчиненное подразделение корневого домена леса.com.
Мы развернули DHCP-сервер в корневом домене леса subhro.com.
Мы настроили учетные данные DHCP и поместили DHCP-сервер в группу subhro.com \ DnsUpdateProxy, чтобы он мог обновлять записи в защищенной зоне.
Мы также выбрали опцию: Всегда динамически обновлять записи DNS.

Есть дочерний домен: abc.subhro.com.
Сервер EXMB01 является членом домена abc.subhro.com.
Мы создали новую область для компьютеров abc.subhro.com.
Зона обратного просмотра настраивается как в родительском, так и в дочернем домене. Это сделано для тестирования.

Теперь, когда DHCP будет назначать IP-адреса компьютерам abc.subhro.com, на каком DNS-сервере он обновит запись:

DNS-сервер домена subhro.com? (DHCP-сервер является членом этого домена),
Или
DNS-сервер abc.subhro.com домен? (DHCP-клиент является членом этого домена)

Мы знаем, что в этом сценарии, когда DHCP-сервер будет выделять IP-адрес, он зарегистрирует записи A и PTR в DNS, но в какой зоне DNS Зона DNS, к которой принадлежит DHCP-сервер, или зона DNS, где находится клиент DHCP. принадлежит?

Другими словами, как регистрация DHCP работает в многодоменной среде? Попробуем узнать ответ. Как видно на диаграмме ниже, мы настроили область на DHCP-сервере, который находится в подчиненном узле корневого домена.com.
Но мы не настроили какой-либо параметр области действия.

DHCP-сервер назначил IP-адрес из своего пула.

Теперь давайте проверим, обновляется ли запись DNS, и если да, то где.

Как мы видим, запись хоста (A) обновляется в зоне DNS abc.subhro.com, что правильно, поскольку этот сервер является членом домена abc.subhro.com.

Однако PTR-запись регистрируется в зоне обратного просмотра, которая размещается на subhro.com Домен AD, а не зона обратного просмотра, которая находится в дочернем домене.

Теперь, чтобы провести дополнительное тестирование, давайте отключим этот сервер от домена abc.subhro.com и присоединим его к домену subhro.com, и посмотрим на результат.

Перед этим удалите текущую аренду, запись хоста DNS и запись PTR.

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

Удалите эту запись перед присоединением этого сервера к домену subhro.com.

После присоединения сервера к домену subhro.com перезагрузите его.

Теперь мы увидим, что записи Host и PTR зарегистрированы в домене subhro.com.

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

При обновлении записи хоста DHCP-сервер ищет DNS-сервер, который является полномочным для зоны, соответствующей доменному имени DHCP-клиента.

Итак, если DHCP-клиент является членом домена abc.subhro.com, DHCP-сервер будет искать DNS-сервер, который является полномочным для зоны abc.subhro.com.

Если DHCP-клиент является членом домена subhro.com, DHCP-сервер будет искать DNS-сервер, который является полномочным для зоны subhro.com.

Даже если мы укажем другое доменное имя в опции 15 области DHCP (DNS-имя домена), это поведение не изменится. Мы проверили этот момент.

Однако было замечено, что для обновления записи PTR он всегда ищет DNS-сервер родительского домена.

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

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

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

В DHCP-сервере есть настройка: Отменить записи A и PTR при удалении аренды.

Если этот параметр включен, записи A и PTR будут удалены из DNS, как только аренда будет удалена с сервера DHCP.

Мы протестировали этот сценарий в нашей тестовой лаборатории, сохраняя DHCP-сервер и клиент в двух разных доменах, и каждый раз он работал. Чтобы это работало, включение очистки не требуется. В нашей тестовой лаборатории мы не включили очистку
в прямой или обратной зоне, но все равно сразу сработало.

Для управления другими устаревшими записями на DNS-сервере необходимо включить очистку.
Однако очистка выходит за рамки этой статьи, поскольку мы рассматриваем только интеграцию между DNS и DHCP. Пожалуйста, не забывайте устанавливать объединенные значения NOREFRESH и REFRESH для очистки, равные или превышающие период аренды DHCP.

Защита имени DHCP — это функция, которая была введена для предотвращения чего-то, что называется приспосабливанием имен. Эта функция была впервые представлена в Windows Server R2.

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

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

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

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

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

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30