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 у міст робить віддаленого клієнта частиною локального широкомовного домену.
Витрати реальні, і про них варто сказати до згоди. Широкомовний трафік іде через тунель, клієнт відкритий локальному сегменту для будь-яких цілей, і сервер тепер пересилає кадри замість маршрутизації пакетів. Для лабораторного стенда це розумний обмін, для віддаленого доступу — погане типове налаштування.
Потрібні обидві половини: міст на сервері й маршрут у профілі клієнта. Один міст залишає клієнта здогадуватися, а один маршрут не виправить клас адреси.