Azure P2S: jednomu klientu Windows po změně VNet chybí trasy

Dva notebooky se ověřují u stejné brány Azure point-to-site a jen jeden dosáhne na nově připojenou VNet. Oba zobrazují Connected, takže ověřování není rozdíl; rozdílem jsou trasy k cíli, které drží. Začněte u klienta, který selhává, porovnejte jediný cíl a teprve potom rozhodněte, zda mezeru vlastní balíček brány, nebo místní směrovací tabulka.

Začněte u klienta, který selhává, ne u brány

Potvrďte topologii, než obviníte notebook. Zjistěte, které VNet jsou připojené k VNet brány a zda je nová síť propojená přímo, nebo dostupná přes samostatný tunel site-to-site. Pokud nová VNet není k VNet brány připojená vůbec, žádný klientský balíček tam nemůže směrovat a fungující notebook je anomálie, kterou je třeba vysvětlit. Odpověď si zapište, protože rozhoduje o tom, zda ladíte klienta, nebo bránu.

Když topologie sedí, postavte oba notebooky vedle sebe. Stejná brána, stejný fond adres, stejný protokol a stejná verze klienta jsou srovnání, které chcete; cokoli jiného je druhá proměnná, kterou budete muset později vyloučit.

Porovnejte jeden cíl pomocí route print

Vyberte povolenou IP adresu prostředku a porovnejte oba notebooky dvakrát: odpojené a potom připojené. V Windows vypisuje route print -4 trasy IPv4 s prefixem cíle, rozhraním, dalším skokem a metrikou. Zaznamenejte řádek, který by pro daný cíl skutečně vyhrál, místo počítání záznamů obsahujících slovo VPN.

Výběr probíhá nejprve podle nejdelšího prefixu a pak podle metriky, takže konkrétnější místní trasa může porazit trasu tunelu, aniž by vypadala špatně. Pokud je zamýšlený cíl uvnitř 10.24.0.0/16, zdravý klient ukazuje odpovídající trasu na rozhraní VPN, zatímco selhávající klient posílá stejnou adresu své výchozí bráně.

Konfliktní místní prefix může vyvolat stejný příznak. Než něco přidáte, rozhodněte, který ze dvou případů máte: žádnou trasu tunelu, nebo trasu tunelu, která prohrává s konkrétnější.

TTL expired není chyba distribuce tras

Ping, který vrací TTL expired in transit, říká, že paket vyčerpal svůj limit skoků, což obvykle znamená smyčku předávání, ne rozbitý ovladač VPN. Ping ve Windows přijímá TTL až 255 a zvýšení hodnoty smyčku neopraví; jen oddálí stejnou chybu. Berte zprávu jako příznak cesty, ne jako důkaz o distribuci tras.

Pomocí tracert -4 10.24.1.10 zjistěte, kde se cesta opakuje. Pokud se stejné dva skoky objevují znovu a znovu, hledejte trasu, která posílá provoz určený tunelu zpět do tunelu nebo do místního routeru, který ho vrací.

Vygenerujte balíček znovu na bráně, která ho vlastní

Microsoft dokumentuje, že klientské balíčky Windows je nutné po relevantních změnách topologie znovu stáhnout a nainstalovat. Vezměte aktuální balíček z brány Azure, která obsluhuje tento profil, a použijte ho podporovaným postupem pro daného klienta. Nahrazení spustitelného souboru nesouvisející VPN aplikace není stejná operace jako regenerace nastavení specifických pro bránu. Stáhnout balíček znovu je levné; hádat místní trasy není.

Připojte se znovu a znovu přečtěte trasu pro původní cíl. Uchovejte řádky před a po spolu se záznamem o změně, aby byl výsledek přesnější než reinstaloval jsem klienta.

Scénáře směrování Azure P2S oddělují přímo propojené VNet od sítí dostupných jinými tunely a nový balíček nemůže učinit propojení tranzitivním. Některé scénáře Windows site-to-site nebo BGP také vyžadují ručně nakonfigurované vzdálené trasy, takže obnovení balíčku není univerzální mechanismus distribuce tras.

Nechte dočasnou trasu dočasnou

Ruční trasa může izolovat chybějící klientskou trasu, ale stavějte ji ze skutečného návrhu: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bez trvalého příznaku, aby při restartu zmizela. Index rozhraní a další skok vyberte z připojeného adaptéru VPN, ne z odhadu.

Nenechávejte experimentální trasu jako trvalého konkurujícího vlastníka. Budoucí aktualizace profilu mohou přidat stejný prefix s jinou metrikou a ruční záznam pak tiše rozhodne, která cesta vyhraje. Krok odstranění zaznamenejte do změny.

Když je správná trasa aktivní, testujte cílovou aplikaci, ne ping. Pokud pakety dorazí do Azure, ale služba stále selhává, zkontrolujte skupinu zabezpečení sítě a zpětnou cestu, protože ty jsou oddělené od toho, zda se notebook prefix naučil.