Windows Server для самых маленьких. Часть 8: DHCPv4
Все части серии «Windows Server для самых маленьких»Протокол DHCP для IPv4 — четыре сообщения Discover, Offer, Request, Ack, формат опций, продление аренды и ретрансляция — разобран в части 11 сетевой серии. Здесь речь о серверной стороне в домене: как роль DHCP Server устроена в Windows, чем сервер в домене отличается от сервера в роутере, как два сервера делят одну область без конфликтов и как они регистрируют имена клиентов в DNS, не ломая безопасные обновления из прошлой части.
DHCP в домене традиционно ставят на контроллеры: это две службы, которым нужна одинаковая доступность и которые вместе занимают несколько десятков мегабайт памяти. Для лаборатории сделаем так же: сейчас на dc1, во второй половине части — на dc2, когда он появится в части 10. Если в организации есть отдельные серверы инфраструктуры, DHCP ставят туда, и всё написанное ниже не меняется, кроме одного пункта про группу DnsUpdateProxy.
Установка и авторизация
PS C:\> Install-WindowsFeature -Name DHCP -IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {DHCP Server, DHCP Server Tools}
Роль установлена, служба DHCPServer запущена, но адресов она раздавать не будет, пока не выполнены два шага, которые в Server Manager скрыты за ссылкой «Complete DHCP configuration».
Группы безопасности. Две локальные группы: DHCP Administrators (полное управление сервером без прав администратора сервера) и DHCP Users (чтение). На контроллере локальных групп нет, поэтому они создаются доменными:
PS C:\> Add-DhcpServerSecurityGroup -ComputerName dc1.corp.example.com
PS C:\> Restart-Service DHCPServer
Авторизация в каталоге. DHCP-сервер Windows, стоящий на члене домена, перед тем как отвечать клиентам, проверяет, записан ли он в списке разрешённых серверов леса. Список — объекты класса dHCPClass в CN=NetServices,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com. Неавторизованный сервер пишет в журнал событие 1046 и молчит. Авторизовать может Enterprise Admins (или тот, кому делегировали права на этот контейнер):
PS C:\> Add-DhcpServerInDC -DnsName dc1.corp.example.com -IPAddress 192.168.1.10
PS C:\> Get-DhcpServerInDC
IPAddress DnsName
--------- -------
192.168.1.10 dc1.corp.example.com
Это защита от случайного DHCP-сервера: админ поднял роль на тестовой машине в домене, а она начала раздавать адреса всему офису. От злонамеренного сервера или домашнего роутера, принесённого в офис, авторизация не защищает: они про каталог ничего не знают и проверять его не будут. Против них работают только средства коммутаторов (DHCP snooping, о котором в сетевой серии).
Последний штрих — сказать Server Manager, что конфигурация завершена, иначе он будет показывать предупреждение вечно:
PS C:\> Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\ServerManager\Roles\12' -Name ConfigurationState -Value 2
Как устроен сервер
Сервер хранит конфигурацию и аренды в базе %SystemRoot%\System32\dhcp\dhcp.mdb — том же движке ESE, что у каталога и Exchange, — и раз в час сам делает её копию в dhcp\backup. Конфигурация строится из четырёх уровней, и каждый следующий переопределяет предыдущий:
Сервер параметры по умолчанию для всех областей: опции DNS-серверов, домена, NTP,
│ настройки регистрации в DNS, обнаружение конфликтов, журнал
├─ Область (scope) диапазон адресов одной подсети: границы, маска, исключения, аренда,
│ │ свои опции (шлюз — всегда здесь)
│ ├─ Политика подмножество клиентов области по условию (класс, MAC, ретранслятор):
│ │ свои опции или свой поддиапазон
│ └─ Резервирование фиксированный адрес для одного клиента, свои опции
└─ Суперобласть несколько областей на одном физическом сегменте
Проверка настроек сервера:
PS C:\> Get-DhcpServerSetting
IsDomainJoined : True
IsAuthorized : True
DynamicBootp : True
RestoreStatus : False
ConflictDetectionAttempts : 0
NpsUnreachableAction : Full
NapEnabled : False
ActivatePolicies : True
ConflictDetectionAttempts — сколько раз сервер пингует адрес перед выдачей. Ноль — не пингует; Set-DhcpServerSetting -ConflictDetectionAttempts 2 защитит от выдачи адреса, который кто-то прописал руками, ценой задержки на пару секунд при выдаче. В сети, где статические адреса исключены из области, это не нужно.
Область
Область — диапазон одной подсети. У лаборатории адреса .1–.49 заняты роутером и серверами, .50–.250 отдадим клиентам:
PS C:\> Add-DhcpServerv4Scope -Name 'Office' -StartRange 192.168.1.50 -EndRange 192.168.1.250 -SubnetMask 255.255.255.0 -LeaseDuration 8.00:00:00 -State Active
PS C:\> Get-DhcpServerv4Scope
ScopeId SubnetMask Name State StartRange EndRange LeaseDuration
------- ---------- ---- ----- ---------- -------- -------------
192.168.1.0 255.255.255.0 Office Active 192.168.1.50 192.168.1.250 8.00:00:00
ScopeId — адрес подсети, и именно он идентифицирует область во всех остальных командлетах. Если внутри диапазона есть адреса, которые раздавать нельзя (сетевое оборудование со статикой), их исключают: Add-DhcpServerv4ExclusionRange -ScopeId 192.168.1.0 -StartRange 192.168.1.200 -EndRange 192.168.1.210.
Аренда по умолчанию 8 дней. Клиент продлевает её на половине срока (через 4 дня) и, если сервер не отвечает, продолжает пользоваться адресом до истечения. Длинная аренда — меньше трафика и устойчивость к падению сервера; короткая (часы) — быстрее освобождаются адреса в сетях с текучкой устройств, вроде гостевого Wi-Fi. Для проводной офисной сети 8 дней — хороший выбор.
Опции — то, что клиент получает кроме адреса. Шлюз задаётся на уровне области (он у каждой подсети свой), всё остальное удобно задать на уровне сервера, чтобы не повторять в каждой области:
PS C:\> Set-DhcpServerv4OptionValue -DnsServer 192.168.1.10 -DnsDomain corp.example.com
PS C:\> Set-DhcpServerv4OptionValue -ScopeId 192.168.1.0 -Router 192.168.1.1
PS C:\> Get-DhcpServerv4OptionValue -ScopeId 192.168.1.0 -All | Format-Table OptionId, Name, Value -AutoSize
OptionId Name Value
-------- ---- -----
3 Router {192.168.1.1}
6 DNS Servers {192.168.1.10}
15 DNS Domain Name {corp.example.com}
51 Lease {691200}
У именованных параметров -DnsServer, -Router, -DnsDomain есть общий вид -OptionId N -Value ... для любой опции из списка Get-DhcpServerv4OptionDefinition:
| Опция | Имя | Зачем |
|---|---|---|
| 3 | Router | шлюз по умолчанию |
| 6 | DNS Servers | должны указывать на контроллеры: клиент с DNS роутера домен не найдёт |
| 15 | DNS Domain Name | суффикс для коротких имён и для регистрации в DNS |
| 42 | NTP Servers | источник времени для устройств, не состоящих в домене (члены домена берут время с контроллера сами) |
| 44, 46 | WINS/NBNS | нужны только совсем старым клиентам; не задавать |
| 51 | Lease | срок аренды; задаётся свойством области, не опцией |
| 60, 43 | Vendor class, Vendor specific | данные для конкретного оборудования: IP-телефоны, точки доступа |
| 66, 67 | Boot Server, Bootfile Name | загрузка по сети (PXE): адрес сервера и имя загрузчика |
| 81 | Client FQDN | имя клиента для регистрации в DNS; клиент и сервер обмениваются им автоматически |
| 119 | Domain Search List | список суффиксов поиска; Windows-клиент её не читает, Linux и macOS — да |
| 121 | Classless Static Routes | дополнительные маршруты; клиент Windows их применяет и игнорирует при этом опцию 3 |
| 150 | TFTP Server | адрес сервера TFTP для IP-телефонов Cisco |
TFTP (Trivial File Transfer Protocol, RFC 1350), который стоит за опциями 66 и 150, — простейший протокол передачи файлов: поверх UDP, порт 69, без аутентификации и без списка файлов на сервере. Клиент запрашивает файл по имени, сервер отдаёт его блоками по 512 байт и ждёт подтверждения каждого блока, прежде чем отправить следующий; блок короче 512 байт означает конец файла. Протокол настолько мал, что умещается в ПЗУ сетевой карты, поэтому им пользуются загрузчик PXE и IP-телефоны, когда скачивают загрузчик, прошивку или конфигурацию.
Опция 6 — то место, где администратор однажды добавляет второй контроллер, и об этом легко забыть: клиенты узнают о dc2 только тогда, когда он появится в опции.
Резервирование — постоянный адрес для устройства, которое само DHCP не выключит: принтеры, точки доступа, сканеры. Привязка по MAC-адресу (точнее, по идентификатору клиента, который у большинства Ethernet-устройств равен MAC; об исключениях ниже):
PS C:\> Add-DhcpServerv4Reservation -ScopeId 192.168.1.0 -IPAddress 192.168.1.31 -ClientId '00-11-22-33-44-55' -Name 'printer-3' -Description 'Принтер, 3 этаж'
PS C:\> Get-DhcpServerv4Reservation -ScopeId 192.168.1.0
IPAddress ScopeId ClientId Name Type Description
--------- ------- -------- ---- ---- -----------
192.168.1.31 192.168.1.0 00-11-22-33-44-55 printer-3 Both Принтер, 3 этаж
Адрес резервирования может лежать внутри диапазона области: сервер его никому другому не выдаст. Это удобнее статической настройки на самом устройстве тем, что все адреса видны в одном месте и устройство переживёт смену DNS-серверов без визита к нему.
Идентификатор клиента — это опция 61 запроса, и MAC-адресом он бывает не всегда. Windows, принтеры и большинство встроенных устройств кладут в неё тип оборудования и MAC (байт 01 и шесть байт адреса), но клиент вправе прислать любую строку, и сервер Windows сопоставляет резервирование именно с ней, а не с MAC-адресом из заголовка пакета. Иначе ведут себя, например, Ubuntu Server и другие системы, где адрес получает systemd-networkd (в Ubuntu его настраивает netplan): по умолчанию они шлют идентификатор по RFC 4361 — байт ff, четыре байта IAID (номер интерфейса, который systemd вычисляет сам) и DUID, идентификатор машины из DHCPv6, о котором подробно в следующей части. systemd строит DUID из /etc/machine-id, и в таблице аренд такой клиент выглядит так:
IPAddress ClientId HostName
--------- -------- --------
192.168.1.57 ff-b6-22-0e-1a-00-02-00-00-ab-11-6c-3f-19-a0-5e-d4-81-27 srv-linux1.corp.example.com
После ff и IAID идёт DUID: 00-02 — его тип DUID-EN (по номеру предприятия), 00-00-ab-11 — номер 43793, закреплённый за systemd, дальше хеш machine-id. Из этого три следствия:
- резервирование по MAC-адресу такой машине не подойдёт: сервер не найдёт совпадения и выдаст адрес из пула. Резервировать нужно по идентификатору из таблицы аренд —
-ClientIdуAdd-DhcpServerv4Reservationпринимает строку любой длины; - переустановка системы меняет machine-id, а с ним и идентификатор: машина получит новый адрес, хотя сетевая карта та же;
- виртуальные машины, клонированные из шаблона без сброса
/etc/machine-id, присылают одинаковый идентификатор и спорят за один адрес.
Если нужна привязка к MAC, её включают на клиенте. В netplan это одна строка у интерфейса:
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp-identifier: mac
После netplan apply следующий запрос придёт с идентификатором 01 и MAC-адресом, и резервирование по MAC заработает.
Политики
С Windows Server 2012 внутри области можно выдавать разным клиентам разное — по условию:
PS C:\> Add-DhcpServerv4Policy -Name 'IP phones' -ScopeId 192.168.1.0 -Condition OR -VendorClass EQ, 'Cisco Systems, Inc. IP Phone*'
PS C:\> Set-DhcpServerv4OptionValue -ScopeId 192.168.1.0 -PolicyName 'IP phones' -OptionId 150 -Value 192.168.1.40
PS C:\> Add-DhcpServerv4PolicyIPRange -ScopeId 192.168.1.0 -Name 'IP phones' -StartRange 192.168.1.220 -EndRange 192.168.1.250
Условия — класс производителя (опция 60), класс пользователя (опция 77), MAC-адрес с маской, идентификатор клиента, адрес ретранслятора, имя из опции 81. Телефоны получат адреса из своего поддиапазона и адрес сервера конфигурации, остальные клиенты — ничего не заметят. Классы объявляет сам клиент, так что для безопасности политика не годится, а для раздачи специфичных настроек — да.
Регистрация в DNS
В прошлой части клиент Windows регистрировал свою A-запись сам. DHCP-сервер может делать это за него, и в домене это нужно по трём причинам: клиенты не на Windows не умеют безопасных обновлений, PTR-записи клиент Windows по умолчанию просит зарегистрировать сервер, а запись устройства, которое исчезло из сети, кто-то должен удалить, когда аренда истечёт.
Договорённость идёт через опцию 81: клиент сообщает своё полное имя и флаги — «зарегистрируй A сам» или «зарегистрируй мне только PTR». Настройки сервера:
PS C:\> Get-DhcpServerv4DnsSetting
DynamicUpdates : OnClientRequest
DeleteDnsRROnLeaseExpiry : True
UpdateDnsRRForOlderClients : False
DnsSuffix :
DisableDnsPtrRRUpdate : False
NameProtection : False
DynamicUpdates:OnClientRequest— делать то, что просит клиент в опции 81 (Windows просит PTR);Always— регистрировать A и PTR всегда, не слушая клиента;Never.UpdateDnsRRForOlderClients— регистрировать записи клиентов без опции 81 (принтеры, старые Linux). Включить.DeleteDnsRROnLeaseExpiry— удалять записи, когда аренда истекает. Это второй механизм очистки зоны помимо старения, и более аккуратный.NameProtection— защита имён: сервер создаёт рядом с A-записью записьDHCIDс хешем идентификатора клиента и не позволяет другому клиенту занять то же имя. Защищает от того, чтобы ноутбук гостя, назвавший себяdc1, не перехватил имя.
Теперь главная тонкость. Записи, созданные DHCP-сервером в безопасной зоне, принадлежат учётной записи, под которой он сделал обновление — по умолчанию учётной записи компьютера DC1$. Когда появится второй сервер и failover, записи, созданные dc1, не сможет обновить dc2: он другой владелец. Решение в два шага.
Шаг 1: отдельная учётная запись для обновлений, одна на все DHCP-серверы домена:
PS C:\> New-ADUser -Name 'svc-dhcp-dns' -SamAccountName svc-dhcp-dns -UserPrincipalName svc-dhcp-dns@corp.example.com -AccountPassword (Read-Host -AsSecureString) -Enabled $true -PasswordNeverExpires $true -Description 'DHCP → DNS dynamic updates'
PS C:\> Set-DhcpServerDnsCredential -ComputerName dc1.corp.example.com -Credential (Get-Credential CORP\svc-dhcp-dns)
PS C:\> Get-DhcpServerDnsCredential -ComputerName dc1.corp.example.com
UserName DomainName
-------- ----------
svc-dhcp-dns corp.example.com
Обычная учётная запись без каких-либо прав: для создания записи в зоне с безопасными обновлениями достаточно быть аутентифицированным пользователем. Теперь все записи от обоих серверов будут принадлежать svc-dhcp-dns, и любой из них сможет их обновить и удалить. DHCP-сервер на контроллере без такой учётной записи пишет при каждом старте предупреждение 1056 именно об этом.
Шаг 2: группа DnsUpdateProxy. Встроенная группа домена, созданная для этого сценария: записи, которые создают её члены, получают пустые права владельца — первый, кто обновит такую запись не из группы, станет её владельцем. Задумано это так: DHCP-сервер создаёт запись для только что установленной машины, машина потом вступает в домен и забирает запись себе. Правильное применение — положить в DnsUpdateProxy учётную запись svc-dhcp-dns. Неправильное — положить туда учётную запись компьютера контроллера, на котором стоит DHCP: тогда записи, которые контроллер регистрирует для самого себя (SRV-записи, A-запись), тоже окажутся без владельца, и их сможет перезаписать кто угодно. Если DHCP стоит на рядовом сервере, в группу допустимо положить и его учётную запись компьютера.
PS C:\> Add-ADGroupMember -Identity DnsUpdateProxy -Members svc-dhcp-dns
С включённой защитой имён (NameProtection) группа не нужна и даже мешает: защита построена на записи DHCID, и владелец должен оставаться у DHCP-сервера.
Отказоустойчивость
Один DHCP-сервер — точка отказа с отложенным эффектом: при его падении сеть продолжает работать до истечения аренд, то есть до четырёх дней у половины клиентов, а новые устройства адресов не получают сразу. До Windows Server 2012 решали разделением области 80/20 между двумя серверами с одинаковыми настройками; с 2012 есть failover: два сервера обслуживают одну область и обмениваются арендами по TCP 647.
Два режима:
- Load Balance — оба сервера активны, запросы делят по хешу MAC-адреса клиента в заданной пропорции (обычно 50/50). Для двух серверов в одной сети.
- Hot Standby — один активен, второй отвечает только когда первый недоступен; резерву выделяется доля адресов (по умолчанию 5 %), которыми он может распоряжаться до перехода в режим Partner Down. Для центрального сервера и резервного в филиале.
Когда появится dc2 с установленной и авторизованной ролью, связь создаётся с одной стороны, и область копируется на партнёра автоматически:
PS C:\> Add-DhcpServerv4Failover -ComputerName dc1.corp.example.com -PartnerServer dc2.corp.example.com -Name 'Office-failover' -ScopeId 192.168.1.0 -LoadBalancePercent 50 -MaxClientLeadTime 1:00:00 -StateSwitchInterval 00:30:00 -AutoStateTransition $true -SharedSecret 'длинная случайная строка'
PS C:\> Get-DhcpServerv4Failover
Name : Office-failover
PartnerServer : dc2.corp.example.com
Mode : LoadBalance
LoadBalancePercent : 50
ServerRole :
ReservePercent :
MaxClientLeadTime : 01:00:00
StateSwitchInterval : 00:30:00
State : Normal
ScopeId : {192.168.1.0}
AutoStateTransition : True
EnableAuth : True
Параметры, смысл которых стоит понимать:
MCLT (Maximum Client Lead Time) — на сколько сервер может продлить аренду клиенту сверх того, что известно партнёру. Пока партнёр в сети, каждая аренда немедленно реплицируется, и MCLT не играет роли. Когда связь между серверами потеряна (состояние Communication Interrupted), сервер выдаёт аренды только на срок MCLT, час, чтобы при восстановлении связи партнёр не обнаружил адреса, занятые дольше, чем он думает. Поэтому во время разрыва клиенты продлевают аренду каждые полчаса — это нормально.
State Switch Interval — через сколько после потери связи сервер считает партнёра мёртвым и переходит в Partner Down, забирая себе весь пул. Без AutoStateTransition переход делают руками: Set-DhcpServerv4Failover -Name Office-failover -PartnerDown. Автоматический переход через 30 минут подходит для двух серверов в одной сети; для серверов в разных сайтах, где разрыв канала не означает смерть партнёра, лучше ручной.
Shared secret — ключ, которым подписываются сообщения между серверами (EnableAuth). Задаётся один раз при создании.
Что реплицируется: аренды, резервирования, исключения, опции области и политики. Что не реплицируется: настройки уровня сервера (опции сервера, учётная запись для DNS, фильтры). Их настраивают на обоих серверах отдельно. После изменения настроек области на одном сервере их нужно отправить партнёру явно:
PS C:\> Invoke-DhcpServerv4FailoverReplication -ComputerName dc1.corp.example.com -Name 'Office-failover' -Force
Оснастка напоминает об этом после каждого изменения; в скриптах про это забывают, и области начинают расходиться. Проверка состояния: Get-DhcpServerv4Failover на обоих серверах должен показывать State: Normal, а Get-DhcpServerv4ScopeStatistics — сходящиеся числа.
И вспомним опцию 6: после появления второго сервера DNS в ней должно быть два адреса — 192.168.1.10, 192.168.1.11. Failover этого не сделает.
Другие подсети
Клиент из подсети 192.168.2.0/24 шлёт Discover широковещательно, и до dc1 в 192.168.1.0/24 этот пакет не доходит: роутеры широковещание не пропускают. Нужен ретранслятор (relay agent) на роутере этой подсети: он принимает широковещательный запрос, вписывает в поле giaddr свой адрес в подсети клиента и отправляет серверу уже адресно. Сервер по giaddr понимает, из какой подсети пришёл запрос, и выбирает область — поэтому область для 192.168.2.0/24 должна существовать на сервере, хотя у него самого в этой подсети адреса нет. В сетевой серии это описано со стороны протокола; на роутере это ip helper-address 192.168.1.10 у Cisco, dhcp-relay у MikroTik, dhcrelay или isc-dhcp-relay на Linux, роль Routing and Remote Access с агентом DHCP Relay у Windows Server.
Обратная ситуация — две подсети на одном физическом сегменте (адресов не хватило, добавили второй диапазон поверх того же VLAN). Для неё суперобласть: Add-DhcpServerv4Superscope -SuperscopeName 'Office-both' -ScopeId 192.168.1.0, 192.168.100.0. Сервер будет считать обе области одним пулом для запросов с этого сегмента.
Смотрим руками
Кто что получил:
PS C:\> Get-DhcpServerv4Lease -ScopeId 192.168.1.0 | Format-Table IPAddress, ClientId, HostName, AddressState, LeaseExpiryTime -AutoSize
IPAddress ClientId HostName AddressState LeaseExpiryTime
--------- -------- -------- ------------ ---------------
192.168.1.31 00-11-22-33-44-55 printer-3 ActiveReservation
192.168.1.50 00-15-5d-01-02-10 ws1.corp.example.com Active 23.10.2026 9:01:55
192.168.1.51 a4-83-e7-1b-2c-3d lap-alice.corp.example.com Active 22.10.2026 17:40:12
192.168.1.52 Active 15.10.2026 10:11:00
Аренда без идентификатора и имени с AddressState: Active на короткий срок — это BAD_ADDRESS: сервер предложил адрес, клиент ответил Decline (адрес уже кем-то занят), и сервер пометил его как плохой на время аренды. Несколько таких подряд — признак второго DHCP-сервера в сети или статических адресов внутри области.
Статистика области и свободные адреса:
PS C:\> Get-DhcpServerv4ScopeStatistics -ScopeId 192.168.1.0
ScopeId Free InUse PercentageInUse Reserved Pending SuperscopeName
------- ---- ----- --------------- -------- ------- --------------
192.168.1.0 186 15 7.46 1 0
PS C:\> Get-DhcpServerv4FreeIPAddress -ScopeId 192.168.1.0 -NumAddress 3
192.168.1.53
192.168.1.54
192.168.1.55
Журнал аудита — текстовые файлы %SystemRoot%\System32\dhcp\DhcpSrvLog-Пн.log … -Вс.log, по одному на день недели, перезаписываются раз в неделю. Строки с кодами событий:
PS C:\> Get-Content C:\Windows\System32\dhcp\DhcpSrvLog-Thu.log | Select-Object -Last 6
10,10/15/26,09:01:55,Assign,192.168.1.50,ws1.corp.example.com,00155D010210,,...
30,10/15/26,09:01:55,DNS Update Request,192.168.1.50,ws1.corp.example.com,,,...
32,10/15/26,09:01:56,DNS Update Successful,192.168.1.50,ws1.corp.example.com,,,...
11,10/15/26,09:40:12,Renew,192.168.1.51,lap-alice.corp.example.com,A483E71B2C3D,,...
13,10/15/26,10:11:00,Conflict,192.168.1.52,,,,...
51,10/15/26,10:15:03,Authorization succeeded,,corp.example.com,,,...
| Код | Событие |
|---|---|
| 10, 11, 12 | адрес выдан, продлён, освобождён клиентом |
| 13 | конфликт: адрес уже занят (BAD_ADDRESS) |
| 14 | область исчерпана, запрос отклонён |
| 15 | отказ: политика, фильтр или область неактивна |
| 30, 31, 32 | запрос обновления DNS отправлен, не удался, удался |
| 50–57 | проверка авторизации: 50 — домен недоступен, 51 — авторизован, 52 — обновлён, 54 — не авторизован, сервер остановлен |
Коды 31 подряд при 30 — записи не регистрируются, и почти всегда причина в учётной записи для обновлений или в её отсутствии.
Обмен в пакетах. pktmon filter add -p 67 -p 68, затем ipconfig /release и ipconfig /renew на ws1:
No. Source Destination Protocol Info
1 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x3a7f2c1e
2 192.168.1.10 192.168.1.50 DHCP DHCP Offer - Transaction ID 0x3a7f2c1e
3 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x3a7f2c1e
4 192.168.1.10 192.168.1.50 DHCP DHCP ACK - Transaction ID 0x3a7f2c1e
В Discover от Windows-клиента — опция 61 (идентификатор клиента: MAC), 12 (имя хоста ws1), 81 (полное имя и флаги «S=1, зарегистрируй PTR»), 60 (MSFT 5.0), 55 (список запрашиваемых опций: 1, 3, 6, 15, 31, 33, 43, 44, 46, 47, 119, 121, 249, 252). В ACK — всё, что сервер смог выдать из запрошенного, плюс 51 (срок аренды), 58 и 59 (моменты продления T1 и T2: половина и 7/8 аренды), 81 с подтверждением регистрации. Опция 252 — адрес файла автонастройки прокси WPAD, и то, что Windows его запрашивает, — одна из причин, по которой имя wpad стоит в блок-листе DNS из прошлой части.
Авторизованные серверы в каталоге, напрямую:
PS C:\> Get-ADObject -SearchBase 'CN=NetServices,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com' -Filter 'objectClass -eq "dHCPClass"' -Properties dhcpServers | Select-Object Name, dhcpServers
Name dhcpServers
---- -----------
DhcpRoot {i192.168.1.10$rcid1$dc1.corp.example.com$...}
dc1.corp.example.com
Объект DhcpRoot с перечислением всех серверов и объект на каждый сервер. Это то, что Add-DhcpServerInDC создал, а служба DHCP проверяет при старте и каждый час.
Резервная копия всей конфигурации сервера одним файлом, пригодится при переносе роли на другой сервер в части 19:
PS C:\> Export-DhcpServer -ComputerName dc1.corp.example.com -File C:\Temp\dhcp-dc1.xml -Leases -Force
-Leases включает в экспорт и текущие аренды, так что новый сервер продолжит с того же места.
Адреса IPv4 розданы. У IPv6 устройство адресации другое — префикс приходит от роутера, идентификатор интерфейса машина придумывает сама, — и место DHCP в нём другое тоже.
Дальше — часть 9: DHCPv6. Два режима, stateful и stateless, и флаги M и O в Router Advertisement, которые их включают; DUID вместо MAC-адреса; области и опции IPv6 на сервере Windows; резервирования по DUID; почему failover для IPv6 не предусмотрен; и когда DHCPv6 вообще не нужен, потому что хватает SLAAC с RDNSS.
Оставить комментарий могут только зарегистрированные пользователи.
Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.