Короткий ответ

Адрес из 169.254.0.0/16 — это APIPA, не «случайный DHCP». Клиент отправил Discover, не получил валидный Offer/Ack и сам назначил link-local. До смены драйвера NIC проверьте: линк (кабель, порт, VLAN), что Discover вообще уходит в нужный сегмент, что DHCP-сервер жив и отвечает, что пул не исчерпан и нет NAK от чужого сервера.

Рабочая подсеть в примерах: 10.0.10.0/24, шлюз 10.0.10.1, DNS 10.0.10.2. APIPA никогда не даст маршрут до шлюза и интернета. Сначала верните L2 и DHCP, потом смотрите NAT.

Симптомы и как отличить

Типичная картина:

  • Windows: ipconfig /all показывает Autoconfiguration IPv4 Address вида 169.254.x.x, маска 255.255.0.0, Default Gateway пустой;
  • Ubuntu: ip -br addr — 169.254.x.x/16 на eth0/ens160, ip route без default via 10.0.10.1;
  • значок сети «без доступа» или «подключено, без интернета»;
  • соседние ПК в том же кабинете с адресами 10.0.10.x работают.

Отличия:

Что видноЭто не APIPA из‑за DHCPКуда смотреть
Есть 10.0.10.x, нет интернеташлюз, NAT, DNSЕсть IP, но нет интернета
Два узла с одним 10.0.10.xконфликтКонфликт IP-адресов
Адрес есть, ping до шлюза есть, сайты не открываютсяDNS/прокси/фильтрПинг идет, сайт не открывается
Только этот ПК, линк Downкабель, порт, Wi‑Fiэтот материал
Много ПК сразу получили 169.254DHCP-сервер, scope, VLANDHCP scope закончился

Windows иногда показывает APIPA параллельно с «настоящим» IPv4, если аренда ещё не получена. Смотрите, какой адрес preferred, а не первый попавшийся в выводе.

Возможные причины

От более частых к редким:

  1. Нет линка: кабель, повреждённый патч-корд, порт access в чужом VLAN, Wi‑Fi без ассоциации.
  2. DHCP-сервер недоступен: выключен, слушает другой интерфейс, firewall режет UDP/67–68.
  3. Клиент в access-порту без VLAN, где DHCP не обслуживается; или native VLAN транка не тот.
  4. Scope исчерпан, сервер молчит или шлёт NAK.
  5. Конкурирующий (rogue) DHCP: домашний роутер, чужой Hyper-V/VMware NAT, телефон с USB-tethering.
  6. На клиенте статический APIPA «закреплён» вручную или остался от ICS/мобильного хотспота.
  7. Драйвер/VMXNET3/virtio после миграции VM: линк есть в гипервизоре, в госте — нет DHCP.
  8. Фильтр на коммутаторе: DHCP snooping без trust на uplink, storm control режет бродкасты.

Диагностика

Фиксируйте вывод в каталог заявки. Подставляйте свои имена интерфейсов.

1. Подтвердить APIPA, а не «просто нет сети»

Windows:

ipconfig /all
Get-NetIPConfiguration -Detailed
Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin
Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MacAddress

PrefixOrigin : WellKnown / адрес 169.254.* при PrefixOrigin не Dhcp — это APIPA. Dhcp с адресом 10.0.10.x — другая задача.

Ubuntu 22.04/24.04:

ip -br link
ip -br addr
ip route
nmcli device show
resolvectl status

2. Линк и VLAN до DHCP

Ping на шлюз при APIPA почти всегда бесполезен: нет маршрута. Проверяйте L2.

Test-NetConnection 10.0.10.1
Get-NetAdapterStatistics
ethtool eth0
ping -c 4 -W 1 10.0.10.1

Link detected: no — не ходите в DHCP-сервер, чините кабель/порт. Если линк есть, а ping на 10.0.10.1 даёт «Destination Host Unreachable» с собственного 169.254 — это ожидаемо.

На коммутаторе (если есть доступ): порт клиента должен быть access VLAN той же L2-сети, где DHCP helper/сервер. Trunk без native/allowed нужного VLAN даёт ту же картину, что «кабель вставлен, DHCP нет». См. не работает VLAN.

3. Уходит ли Discover

Windows (админская сессия, на проблемном NIC):

# Сброс аренды, чтобы увидеть новые Discover
ipconfig /release
ipconfig /renew

Параллельно с зеркала порта или на DHCP-сервере:

sudo tcpdump -n -i eth0 udp port 67 or port 68

Ожидание: BOOTP/DHCP, Request from <MAC> и ответ сервера 10.0.10.2 (или шлюз-relay 10.0.10.1). Есть Discover, нет Offer — сервер/relay/snooping. Нет даже Discover — клиент, драйвер, фильтр исходящего UDP.

4. Состояние DHCP-сервера и пула

На сервере Windows DHCP:

Get-DhcpServerv4Scope
Get-DhcpServerv4FreeIPAddress -ComputerName DC01 -ScopeId 10.0.10.0 -NumAddress 5
Get-DhcpServerv4Lease -ComputerName DC01 -ScopeId 10.0.10.0 | Where-Object IPAddress -eq '10.0.10.10'

AddressesFree : 0 — не APIPA «магии», а закончившийся scope.

Ubuntu isc-dhcp-server / Kea: смотрите dhcpd -t, журнал dhcpd/kea-dhcp4, leases. Не правьте dhcpd.leases вручную на работающем процессе.

5. Чужой DHCP

Get-NetIPConfiguration
# DefaultGateway и DNS, которые клиент *хотел бы* получить, видны только после успешного Ack
arp -a
Get-NetNeighbor -AddressFamily IPv4

Если сосед внезапно получил шлюз 192.168.0.1 при вашей схеме 10.0.10.1 — в сегменте второй сервер. Ищите MAC источника Offer в tcpdump. Не отключайте «навсегда» Windows Firewall: для проверки достаточно временного правила на UDP/68 на клиенте, затем верните профиль.

Решение

Сценарий A. Один ПК, линк Down

Замените патч-корд, порт, SFP. На VM проверьте, что vNIC подключён к нужному port group/bridge, не в «Isolated». После появления линка:

ipconfig /renew
Get-NetIPAddress -AddressFamily IPv4
sudo dhclient -v eth0
# или на Ubuntu с netplan/NetworkManager:
sudo nmcli device reapply eth0

Сценарий B. Discover есть, Offer нет, пул жив

Проверьте DHCP relay на 10.0.10.1 (ip helper / dhcp-relay) и snooping: uplink к серверу — trust. Верните клиенту тот VLAN, где scope 10.0.10.0/24. Не добавляйте второй scope «на всякий случай» поверх существующего — получите конфликт адресов.

Сценарий C. Scope пуст

Освободите устаревшие резервации, уменьшите lease на новом пуле только после оценки, расширьте диапазон без пересечения со статикой. Подробно — статья про исчерпание scope. Не включайте 169.254 в исключения «как временный пул».

Сценарий D. Rogue DHCP

Изолируйте порт нарушителя. На корпоративном DHCP включите DHCP snooping + (где поддерживается) DHCP Guard на Hyper-V. Не «лечите» APIPA статическим 10.0.10.10 на всех машинах — размажете конфликт.

Сценарий E. Статика случайно стоит 169.254

Windows: адаптер → IPv4 → «Получить IP автоматически». Ubuntu netplan: уберите ручной 169.254 из addresses:.

# /etc/netplan/01-netcfg.yaml — пример, не копируйте вслепую на сервер
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses: [10.0.10.2]
sudo netplan try

Как проверить, что проблема устранена

На том же ПК:

ipconfig /all
Test-NetConnection 10.0.10.1
Test-NetConnection 10.0.10.2 -Port 53
ping -n 4 10.0.10.1
nslookup contoso.example 10.0.10.2
ip -br addr
ip route
ping -c 4 10.0.10.1
traceroute -n 10.0.10.2
resolvectl query contoso.example

Ожидание: IPv4 из 10.0.10.0/24, маска /24, шлюз 10.0.10.1, DNS 10.0.10.2, PrefixOrigin : Dhcp. Lease на сервере соответствует MAC клиента. Повторите после перезагрузки — APIPA часто возвращается, если линк поднимается позже службы DHCP-клиента; тогда смотрите задержку линка и «медиа disconnected» в журнале.

Если не помогло

  • Линк есть, Discover нет: отключите временно сторонние «сетевые фильтры» VPN-клиента (не Windows Defender навсегда). Проверьте, что не выбран адаптер Bluetooth/vEthernet Default Switch.
  • Offer приходит, Ack нет: сравните предлагаемый IP с уже живущим в ARP — неверная запись ARP и конфликт.
  • Только Wi‑Fi даёт APIPA, кабель — норма: изоляция клиентов на точке, гостевой VLAN без DHCP.
  • Dual-stack: IPv6 RA работает, IPv4 APIPA — пользователи открывают сайты по AAAA, а «диагностика IPv4» кажется сломанной. Смотрите именно IPv4-маршрут.
  • Кластер/heartbeat NIC специально в APIPA — не трогайте второй адаптер без схемы.

Профилактика

  • Мониторинг свободных адресов scope и числа NAK.
  • DHCP snooping, отдельный VLAN для пользователей, helper только на SVI 10.0.10.1.
  • Резервирования для серверов, статика вне пула.
  • На гипервизоре запрет подмены DHCP с VM.
  • Документируйте, какой сервер отвечает в 10.0.10.0/24 — один primary, не «два независимых dhcpd».

FAQ

Это сломанный интернет или сломанный DHCP?

APIPA означает: до DHCP-сервера клиент не договорился. Интернет мог бы работать при статике 10.0.10.x и живом NAT. Сначала аренда, потом проверка шлюза и DNS.

Можно ли прописать 10.0.10.50 вручную и идти дальше?

Как временный обход на одном ПК — да, если адрес свободен (проверьте ARP). Как массовое решение — нет: вы скроете мёртвый DHCP и получите конфликты.

Почему ping 127.0.0.1 работает, а 10.0.10.1 нет?

Локальный стек жив. До шлюза нет L3-пути с 169.254.0.0/16. Это не «пинг запрещён на роутере».

Нужно ли отключать IPv6, чтобы пропал 169.254?

Нет. 169.254.x.x — IPv4 link-local. IPv6 fe80:: — норма. Отключение IPv6 «навсегда» не лечит DHCP и ломает современные ОС.

Windows показывает 169.254 и 10.0.10.10 сразу. Какой настоящий?

Смотрите Get-NetIPAddress и SkipAsSource, маршрут 0.0.0.0/0. Если default через 10.0.10.1 — рабочий адрес DHCP; APIPA может быть на втором интерфейсе (vEthernet, VPN). Не renew «все адаптеры подряд» на сервере.

Как отличить исчерпанный пул от мёртвого сервера?

В tcpdump: NAK или отсутствие Offer при живом Discover. На сервере — AddressesFree и журнал. Методика трёх инструментов: ping, tracert, nslookup.