РЕДАКТИРОВАТЬ:
У нас следующая настройка: Пользователь приходит в здание, он получает адрес из диапазона для неизвестных клиентов (192.168.100.0/25) и может попасть только на наш сайт. Мы называем это анонимным диапазоном. Допустим, наш пользователь получил адрес 192.168.100.16 и не пройдет через локальную сеть.
Затем он должен пойти и зарегистрировать свой MAC-адрес, и ему будет назначен новый фиксированный IP-адрес из диапазона адресов 192.168.40.0/22. Конфигурация DHCP обновлена и перезагружена. Затем пользователь «попадает в Интернет», потому что этот диапазон не блокируется межсетевым экраном. Процедура ipconfig / release / refresh срабатывала каждый раз.
Что произошло на этой неделе: после того, как пользователь зарегистрирует свой MAC и перезагрузит DHCPD, он все еще получит адрес 192.168.100.16, что неверно, потому что он должен получить, скажем, 192.168.40.156 (его MAC и этот адрес зафиксированы в конфигурации). В результате он не может попасть в Интернет. При просмотре журнала daemon.log я вижу, что есть ЗАПРОС на адрес 192.168.100.16, и DHCP-сервер ACK подтверждает это. Один раз произошло в Windows 7 и один раз на планшете под управлением Android 3.0.
Такого никогда не было, и мы не можем понять, как это решить. Переустановка Windows помогает, но это просто глупо, не могу требовать этого от пользователей.
shared-network NET {
subnet 192.168.40.0 netmask 255.255.252.0 {
option routers 192.168.40.1;
...
host tomas3 { hardware ethernet cc:52:af:97:55:25; fixed-address tomas3.nat.b.c.d; }
...
}
range 192.168.100.2 192.168.100.126;
option routers 192.168.100.1;
allow unknown-clients;
}
}
Мы уже разобрались, в чем проблема. Мы использовали не фиксированный IPv4-адрес, а полное доменное имя. Мы заметили, что конфигурация сервера имен не перезагружалась из-за неправильного права доступа rndc. Таким образом, обратный поиск не дал действительного IPv4 и, следовательно, произошел сбой в конфигурации DHCP (в наш анонимный диапазон).
В окнах это:
ipconfig /release
ipconfig /renew