Защо таблицата с маршрути на VPN под Windows показва 0.0.0.0/1 и 128.0.0.0/1

Свържете се с VPN под Windows и отворете таблицата с маршрути — две записи се набиват на очи: 0.0.0.0/1 и 128.0.0.0/1. Това не е печатна грешка и те не заменят маршрута по подразбиране. Появата им зависи от една опция на профила, а двойката е начинът, по който се изгражда пълен тунел, а не функция на разделен тунел. Прочетете опцията, префикса и интерфейса заедно, преди да промените дори един ред.

Какво инсталира опцията за шлюз по подразбиране

Опцията на профила, която праща всичко през тунела, работи, като добавя тези два префикса. Махнете опцията и те изчезват, оставяйки маршрут, който покрива само подмрежата, отдадена на адаптера на тунела. Отметката управлява двойката; тя не пренаписва единствения маршрут по подразбиране. Затова след премахване на отметката таблицата изглежда като частично пренаписване, а не като изтриване.

0.0.0.0/1 покрива долната половина на IPv4 пространството, а 128.0.0.0/1 — горната, така че заедно покриват всяка юникаст адрес. Всеки от тях е по-конкретен от маршрут 0.0.0.0/0 по подразбиране, което означава, че съпоставянето по най-дълъг префикс праща обикновения трафик в тунела, докато физическият маршрут по подразбиране остава там, където е бил. Запазването на този маршрут не е козметика: пакетите, които обвиват шифрования полезен товар, са адресирани до публичния адрес на сървъра и трябва да излязат през физическия адаптер. Заменете маршрута по подразбиране, вместо да го разделяте, и транспортът на самия тунел ще се опита да влезе в тунела, което е цикъл, а не връзка.

Затова буквален 0.0.0.0/0, сочещ към VPN адаптера, заслужава спиране. Вграденият клиент обикновено не пише такъв, така че ръчен маршрут или конфигурация на друг клиент е променила таблицата зад гърба ви. Намерете го, преди да отстранявате проблеми по-надолу.

Разглобяването е по-евтино от запазването на шлюз

Разглобяването е практичният аргумент за два записа вместо един. Клиентът притежава точно два маршрута, докато е свързан, и ги изтрива при прекъсване, оставяйки каквото физическият адаптер държи в този момент. Клиент, който беше заменил единствения маршрут по подразбиране, щеше да трябва да помни предишния шлюз и след промяна на DHCP наема можеше да възстанови такъв, който вече не съществува. Два собствени записа не носят такова състояние.

Други клиенти стигат до същия дизайн. Профил на OpenVPN с redirect-gateway def1 инсталира тези два префикса, вместо да изтрие маршрута по подразбиране, а клиентът за Windows следва схемата по същата причина за маршрутизацията.

Затова и таблицата може да изглежда като пълен тунел, когато сте очаквали разделяне. Двойката е начинът, по който се изгражда пълният тунел, а не доказателство за грешка при разделен тунел. Ако профилът е настроен да използва отдалечения шлюз, всичко се маршрутизира, каквото и да успее да достигне едно локално приложение.

Най-дългият префикс печели преди всяка метрика

Дължината на префикса решава справката преди всяко друго поле. Метриката само разбива равенство между маршрути с еднакъв префикс, така че запис /1 бие маршрут /0 по подразбиране дори когато метриката му е по-лоша. Обвързването с интерфейс решава какво остава, когато два маршрута споделят префикс и Windows трябва да избере кой адаптер да изпрати пакета.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Таблицата на разделен тунел държи физическия маршрут по подразбиране, двата полумаршрута, маршрута за подмрежата на тунела и всеки офисен префикс, който сте добавили. Физическият маршрут по подразбиране може да е с по-ниска или по-висока метрика в зависимост от клиента и профила и докато двойката /1 съществува, тази разлика не променя нищо. Тя променя всичко в момента, в който двойката бъде премахната — тогава изплува застоял шлюз или грешен интерфейс. Четете цялата таблица, а не единствения ред, който сте очаквали да се промени.

Изберете един собственик за офисния префикс

За разделен тунел назовете само префикса, който трябва да минава през VPN, и изберете един начин да го притежавате. Насочването на маршрута към зададения адрес на тунела работи, докато този адрес се промени, докато обвързването с интерфейса оцелява при смяна на адреса, но се чупи, когато индексът бъде зададен наново след преизграждане на профила. Обвързаният с профила cmdlet избягва и двата проблема, с цената на нуждата от профила.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Cmdlet-ът обвързва префикса с посочения профил, така че маршрутът се появява с връзката и си тръгва с нея, което е желаното за управляван лаптоп. Постоянният маршрут надживява рестартирания и надживява профила, който го е породил — така оттеглен VPN оставя записи със години. Изберете един метод на префикс и запишете избора, защото постоянен маршрут плюс маршрут от профил за един и същ префикс създават дубликати, които са болезнени за разплитане при разглобяване. Кое и да изберете, собствеността трябва да е видима в тикета, а не само на машината.

Собствеността е въпросът, на който отговаря този раздел, а не синтаксисът. Двама собственици за един префикс е режимът на отказ, който си струва да се избягва.

Проверявайте с дестинация, не с уебсайт

Тествайте дестинацията, която трябва да премине през тунела, а не уебсайт, който отчита изходен адрес. Find-NetRoute връща избрания маршрут и адреса на източника, така че виждате дали офисният префикс или физическият маршрут по подразбиране е спечелил, и след това отваряте самия споделен ресурс.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Сайтът за изходен адрес е слаба проверка, защото DNS, IPv6 и прокси на браузъра могат да пратят тази заявка по различен път. IPv4 и IPv6 имат и отделни настройки в един и същ диалог и изчистването на една отметка оставя другото семейство незасегнато, така че машина с двоен стек може да носи IPv6 през тунела, докато IPv4 следва разделения маршрут. Проверете двете семейства, преди да наречете профила разделен. Ако маршрутът е правилен и услугата все още не работи, останалият слой е филтриране, а не маршрутизация.

Управлявана от клиента защитна стена може да блокира офис подмрежата при безупречна таблица с маршрути. Тази политика принадлежи на този, който е разпространил профила, а не на човека, който редактира маршрути.