Вместо Ubuntu временно установил Raspbian. Там isc-dhcp-client, у которого логика работы слега отличается от встроенного в systemd клиента. И тут всё встало на свои места...
Подключаемся к сети и шлём широковещательный (255.255.255.255) запрос о присвоении адреса, получении DNS, маршрутов и другой информации:
Feb 3 19:17:59 server dhclient[295]: Listening on LPF/eth1/1c:1e:1e:f2:0f:19
Feb 3 19:17:59 server dhclient[295]: Sending on LPF/eth1/1c:1e:1e:f2:0f:19
Feb 3 19:17:59 server dhclient[295]: Sending on Socket/fallback
Feb 3 19:17:59 server dhclient[295]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
Feb 3 19:18:03 server dhclient[295]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb 3 19:18:03 server dhclient[295]: DHCPOFFER of 10.16.192.220 from 10.16.192.1
Feb 3 19:18:03 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 255.255.255.255 port 67
Благополучно получаем все необходимые данные и устанавливаем время аренды:
Feb 3 19:18:03 server dhclient[295]: DHCPACK of 10.16.192.220 from 10.16.192.1
Feb 3 19:18:04 server dhclient[295]: bound to 10.16.192.220 -- renewal in 1579 seconds.
Через 1579 секунд, DHCP-клиент должен послать запрос на обновление аренды на адрес DHCP-сервера, который он получил на предыдущем шаге. Это и происходит:
Feb 3 19:44:23 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
И вот тут клиент должен получить уведомление, что время аренды продлено. А что же происходит на самом деле? А на самом деле происходит вот что:
Feb 3 19:44:28 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb 3 19:44:41 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb 3 19:44:49 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
...
Feb 3 20:03:52 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb 3 20:04:00 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb 3 20:04:10 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Вплоть до истечения счётчика T2 клиент будет отчаянно долбить по выданному адресу и не получать ответ потому, что ему выдали неправильный адрес DHPC-сервера.
Далее разные DHCP-клиенты могут вести себя по-разному. Вообще, не получив ответа, далее должен следовать широковещательный запрос на rebinding, а сам rebinding в итоге сопровождается разрывом соединения, так как время аренды истекло и клиент обязан освободить адрес. Но isc-dhcp-client, логи которого я здесь привожу, в качестве отчаянного шага, перед разрывом соединения всё-таки пытается сделать последнюю попытку продлить время аренды и посылает широковещательный запрос в сеть:
Feb 3 20:04:23 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 255.255.255.255 port 67
И вот тут откуда-то из подсети снова откликается DHCP-сервер, который мы всё это время искали по адресу 78.107.63.106, но которого там нет, потому что админы неправильно настроили оборудование:
Feb 3 20:04:23 server dhclient[295]: DHCPACK of 10.16.192.220 from 10.16.192.1
Feb 3 20:04:23 server dhclient[295]: bound to 10.16.192.220 -- renewal in 3563 seconds.
И на 3563 секунды всё успокаивается. А потом всё начинается вновь.
Что-либо доказать службе техподдержки провайдера бесполезно. Они заладили, что они проверили линию и оборудование и с ними всё в порядке. И в доказательство говорят, что у всех остальных всё работает. Вот что с ними поделать?
Думаю теперь, как можно решить проблему по-другому. Нужно как-то заставить DHCP-клиент игнорировать подсунутый ему IP DHCP-сервера и вместо него подставлять 255.255.255.255.Вот только не уверен, что это возможно и что это вообще будет работать. Ещё лучше каким-то образом выяснить реальный адрес DHCP-сервера и подставлять его. Я пытался снять tcpdump в процессе широковещаетльного запроса, но там полезной информации не нашлось:
10:09:20.983078 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
10.16.192.220.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 1c:1e:1e:f2:0f:19 (oui Unknown), length 300, xid 0x3e9c0b18, secs 3319, Flags [none]
Client-IP 10.16.192.220
Client-Ethernet-Address 1c:1e:1e:f2:0f:19 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Hostname Option 12, length 8: "cityacee"
Parameter-Request Option 55, length 13:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP
Client-ID Option 61, length 19: hardware-type 255, 1e:f2:0f:19:00:01:00:01:25:cb:01:f9:1c:1e:1e:f2:0f:19
10:09:20.993471 IP (tos 0xc0, ttl 30, id 26946, offset 0, flags [DF], proto UDP (17), length 336)
10.16.192.1.bootps > 10.16.192.220.bootpc: BOOTP/DHCP, Reply, length 308, hops 1, xid 0x3e9c0b18, Flags [none]
Client-IP 10.16.192.220
Your-IP 10.16.192.220
Gateway-IP 10.16.192.1
Client-Ethernet-Address 1c:1e:1e:f2:0f:19 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: cnr306-msk-virt.corbina.net
Lease-Time Option 51, length 4: 7200
Subnet-Mask Option 1, length 4: 255.255.248.0
BR Option 28, length 4: 255.255.255.255
Default-Gateway Option 3, length 4: 10.16.192.1
Domain-Name Option 15, length 7: "beeline"
Domain-Name-Server Option 6, length 8: hdns1.corbina.net,hdns2.corbina.net
MTU Option 26, length 2: 576
Hostname Option 12, length 8: "cityacee"
А можно ли как-то средствами iptables или иным способом заменить обращение к адресу 78.107.63.106 на ширововещательный запрос?