Azure P2S: един Windows клиент губи маршрути след промяна на VNet

Два лаптопа се удостоверяват към един и същ Azure point-to-site шлюз и само единият достига до новосвързаната VNet. И двата показват Connected, така че удостоверяването не е разликата; разликата са маршрутите до местоназначението, които държат. Започнете от клиента, който се проваля, сравнете едно местоназначение и само след това решете дали пакетът на шлюза, или локалната таблица за маршрутизация е собственик на пропуска.

Започнете от клиента, който се проваля, не от шлюза

Потвърдете топологията, преди да обвинявате лаптопа. Проверете кои VNet са свързани към VNet на шлюза и дали новата мрежа е директно пиърирана, или се достига през отделен site-to-site тунел. Ако новата VNet изобщо не е свързана към VNet на шлюза, нито един клиентски пакет не може да маршрутизира до нея и работещият лаптоп е аномалията, която трябва да се обясни. Запишете отговора, защото той решава дали отстранявате проблем в клиент, или в шлюз.

След като топологията е наред, сложете двата лаптопа един до друг. Същият шлюз, същият адресен пул, същият протокол и същата версия на клиента са сравнението, което искате; всичко друго е втора променлива, която ще трябва да елиминирате по-късно.

Сравнете едно местоназначение с route print

Изберете разрешен IP на ресурс и сравнете двата лаптопа два пъти: изключени, после свързани. В Windows route print -4 изброява маршрути IPv4 с префикс на местоназначението, интерфейс, следващ хоп и метрика. Запишете реда, който действително ще спечели за това местоназначение, вместо да броите записи, съдържащи думата VPN.

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

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

TTL expired не е дефект в разпределението на маршрути

Ping, който връща TTL expired in transit, казва, че пакетът е изчерпал лимита си за хопове, което обикновено означава цикъл на препращане, а не счупен драйвер на VPN. Ping в Windows приема TTL до 255 и увеличаването на стойността не поправя цикъл; то само отлага същата грешка. Приемайте съобщението като симптом на пътя, а не като доказателство за разпределението на маршрути.

Използвайте tracert -4 10.24.1.10, за да видите къде пътят се повтаря. Ако същите два хопа се появяват отново и отново, търсете маршрут, който връща трафика, насочен към тунела, обратно в тунела или към локален рутер, който го препраща обратно.

Пресъздайте пакета на шлюза, който го притежава

Microsoft документира, че пакетите за Windows клиенти трябва да се изтеглят и инсталират отново след значими промени в топологията. Вземете текущия пакет от Azure шлюза, който обслужва този профил, след което го приложете с поддържания процес за този клиент. Подмяната на изпълним файл на несвързано VPN приложение не е същата операция като пресъздаването на настройки, специфични за шлюза. Повторното изтегляне на пакета е евтино; гадаенето за локални маршрути не е.

Свържете се отново и прочетете наново маршрута за първоначалното местоназначение. Пазете редовете преди и след заедно със записа за промяната, за да е резултатът по-точен от преинсталирах клиента.

Сценариите за маршрутизация на Azure P2S разделят директно пиърираните VNet от мрежи, достигани през други тунели, и нов пакет не може да направи пиъринга транзитивен. Някои Windows site-to-site или BGP сценарии също изискват ръчно конфигурирани отдалечени маршрути, така че обновяването на пакета не е универсален механизъм за разпределение на маршрути.

Оставете временния маршрут временен

Ръчен маршрут може да изолира липсващ клиентски маршрут, но го изградете от реалния дизайн: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, без флага за запазване, за да изчезне при рестартиране. Изберете индекса на интерфейса и следващия хоп от свързания VPN адаптер, а не от догадка.

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

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