169.254 через VPN: этот адрес никогда не был маршрутизируемым
Адрес link-local отбрасывается ещё до входа в туннель, поэтому добавление маршрутов лишь расширяет сбой. Выберите между исправлением подсети и мостом.
Вы добавляете маршрут, туннель поднимается, а ping на другую сторону всё равно умирает с полной потерей, а не с «network unreachable». Эта разница важна: она уводит взгляд от таблицы маршрутизации к самому адресу. Адрес 169.254 относится к link-local, и его область заканчивается на первом прыжке по замыслу.
Решение узкое: исправить подсеть на стороне сервера или расширить сегмент 2-го уровня. Даже более широкий маршрут лишь распространяет тот же сбой на большее число адресатов.
Адрес не без маршрута — он немаршрутизируемый
Адреса IPv4 link-local назначаются сами, когда ничего лучшего не отвечает; отсюда автоматическая частная адресация в Windows и запасной вариант в других системах. Диапазон используется на каждой связи одновременно, и поэтому работает: два узла в одном сегменте говорят без согласования.
Из-за этого же свойства маршрутизатор не должен пересылать такие пакеты между сетями. Получить пакет для link-local-получателя и отправить его через другой интерфейс означало бы неоднозначность: «локальное» отправителя и получателя — разные места. Нет поиска, который решил бы, какое имелось в виду. Пересылка здесь не политическая опция администратора; класс адресов это исключает.
Поэтому шлюз, прописывающий 169.254.1.10 доступным через туннель, просит ядро о том, что запрещает формат адреса. Пакет отбрасывается задолго до удалённого узла.
Почему туннель делает проблему области видимой
Интерфейс TUN переносит IP-пакеты между двумя сторонами и не имеет за собой общего сегмента. Нет широковещания, нет ARP для другой стороны и нет обнаружения соседей.
Симптомы совпадают точно. Маршрут есть в таблице, ping сообщает о полной потере, таблица соседей показывает неполную запись. Запись на туннеле показывает уходящий пакет, и это уводит людей к дальнему концу вместо класса адреса.
В Windows есть второй, внешне не связанный симптом с тем же корнем: у адаптера с одним link-local-адресом нет пригодного шлюза, поэтому профиль брандмауэра попадает в общедоступный. Туннель не причина; причина — адрес.
Решите тремя вопросами
Выбор между исправлением подсети и мостом зависит от трёх условий.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
Большинство случаев останавливается на первом вопросе. Узел с link-local-адресом обычно означает, что DHCP не ответил, кабель или VLAN неверны либо адрес введён вручную. Исправить это дешевле любой работы с туннелем и убирает проблему у каждого будущего клиента.
Проверьте сторону сервера. Запустите ip addr show и ip route на узле, а arp -n или route print -4 на клиенте, чтобы увидеть, существует ли префикс или так утверждает только старая запись.
Чего стоит мост, когда он и есть верный ответ
Объединение физического адаптера с адаптером TAP в мост делает удалённого клиента частью локального широковещательного домена.
Издержки реальны, и о них стоит сказать до согласия. Широковещательный трафик идёт через туннель, клиент открыт локальному сегменту для любых целей, и сервер теперь пересылает кадры вместо маршрутизации пакетов. Для лабораторного стенда это разумный обмен, для удалённого доступа — плохая настройка по умолчанию.
Нужны обе половины: мост на сервере и маршрут в профиле клиента. Один мост оставляет клиента гадать, а один маршрут не исправит класс адреса.