169.254 през VPN: адресът никога не е бил маршрутизируем
Дестинация от локален за връзката тип се отхвърля, преди да стигне до тунела, така че добавянето на маршрути само разширява отказа. Изберете между поправка на подмрежата и мост.
Добавяте маршрута, тунелът се вдига, а ping към другата страна все още умира с пълна загуба, а не с «network unreachable». Тази разлика е важна, защото отмества погледа от таблицата за маршрутизация към самия адрес. Дестинация 169.254 е локална за връзката, а обхватът ѝ по проект свършва на първия хоп, не заради грешна конфигурация.
Решението, което следва, е тясно и си струва да се вземе изрично: поправяне на подмрежата от страна на сървъра или разширяване на сегмента от слой 2, за да стане адресът отново локално смислен. Всичко останало, включително добавянето на по-широк маршрут, само прави същия отказ валиден за повече дестинации.
Адресът не е без маршрут — той е немаршрутизируем
IPv4 адресите, локални за връзката, се самоназначават, когато нищо по-добро не отговори; оттам идва автоматичното частно адресиране в Windows и съответният резервен вариант в други системи. Диапазонът се използва на всяка връзка едновременно и точно затова работи: два хоста в един сегмент могат да говорят без никаква координация.
Заради същото свойство рутерът не бива да препраща такива пакети между мрежи. Да получиш пакет, адресиран до локална за връзката дестинация, и да го изпратиш през друг интерфейс, би създало двусмислие, защото «локално» при подателя и «локално» при получателя са различни места. Няма справка, която да реши кое от двете е имал предвид подателят. Препращането тук не е политически избор, който администраторът може да включи; класът адреси го изключва.
Затова шлюз, който инсталира 169.254.1.10 като достижим през тунела, иска от ядрото нещо, което форматът на адреса забранява. Пакетът се отхвърля много преди да стигне до отдалечения хост и никаква точност на маршрута не променя този резултат.
Защо тунелът прави проблема с обхвата видим
Интерфейс TUN пренася IP пакети между двама партньори и няма споделен сегмент зад себе си. Няма broadcast, няма ARP за другата страна и няма откриване на съседи, което да превърне локална за връзката дестинация в адрес от каналния слой. Дори препращането да беше разрешено, клиентът няма как да научи кой партньор трябва да отговори.
Симптомите се подреждат точно, щом знаете какво да търсите. Маршрутът е в таблицата, ping съобщава пълна загуба вместо недостижима мрежа, а таблицата на съседите показва непълен или неуспешен запис за дестинацията. Снимка на тунела показва пакета да излиза и това насочва хората към далечния край, а не към класа на адреса.
В Windows има втори, на пръв поглед несвързан симптом със същия корен: адаптер само с локален за връзката адрес няма използваем шлюз, затова идентификацията на мрежата не може да класифицира връзката и профилът на защитната стена попада в public. Тунелът не е причината; адресът е.
Решете с три въпроса
Изборът между поправка на подмрежата и мост върху връзката зависи от три условия и всяко от тях може да го реши, преди да отворите конфигурационен файл.
| 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 |
Повечето случаи спират на първия въпрос. Хост с локален за връзката адрес обикновено значи, че DHCP не е отговорил, кабелът или VLAN е грешен, или някой е въвел адреса на ръка. Поправката е по-евтина от всяка работа по тунела и премахва проблема за всеки бъдещ клиент, не само за този. Оставя и работещ DHCP диапазон, което е това, което всъщност искахте.
Проверете страната на сървъра, преди да предполагате каквото и да е. Изпълнете ip addr show и ip route на хоста, а arp -n или route print -4 на клиента, за да видите дали префиксът изобщо съществува или само стар запис твърди това.
Какво струва мостът, когато е правилният отговор
Мост между физически адаптер и TAP адаптер прави отдалечения клиент част от локалния broadcast домейн. Тогава broadcast и откриването на съседи работят и локалният за връзката адрес отново има смисъл, защото клиентът наистина е локален за тази връзка.
Разходите са реални и трябва да се кажат, преди някой да се съгласи. Broadcast трафикът пресича тунела, клиентът е изложен на локалния сегмент за всякакви цели, не само за услугите, които му трябват, а сървърът вече трябва да препраща кадри вместо да маршрутизира пакети. Това е разумна размяна за лабораторна маса или устройство без маршрутизируем път за конфигурация и лоша настройка по подразбиране за отдалечен достъп.
Когато правите мост, трябват и двете половини: мостът на сървъра и маршрут в профила на клиента, който казва кои дестинации са от другата страна. Само мост оставя клиента да гадае, а само маршрут не може да поправи клас адрес.