Azure P2S: jednému klientovi Windows po zmene VNet chýbajú trasy

Dva notebooky sa overujú na tej istej bráne Azure point-to-site a len jeden dosiahne novo pripojenú VNet. Oba zobrazujú Connected, takže overovanie nie je rozdiel; rozdielom sú trasy k cieľu, ktoré držia. Začnite u klienta, ktorý zlyháva, porovnajte jediný cieľ a až potom rozhodnite, či medzeru vlastní balík brány alebo miestna smerovacia tabuľka.

Začnite u klienta, ktorý zlyháva, nie u brány

Potvrďte topológiu, kým obviníte notebook. Zistite, ktoré VNet sú pripojené k VNet brány a či je nová sieť prepojená priamo alebo dostupná cez samostatný tunel site-to-site. Ak nová VNet nie je k VNet brány pripojená vôbec, žiadny klientsky balík tam nemôže smerovať a fungujúci notebook je anomália, ktorú treba vysvetliť. Odpoveď si zapíšte, pretože rozhoduje o tom, či ladíte klienta alebo bránu.

Keď topológia sedí, postavte oba notebooky vedľa seba. Rovnaká brána, rovnaký fond adries, rovnaký protokol a rovnaká verzia klienta sú porovnanie, ktoré chcete; čokoľvek iné je druhá premenná, ktorú budete musieť neskôr vylúčiť.

Porovnajte jeden cieľ pomocou route print

Vyberte povolenú IP adresu prostriedku a porovnajte oba notebooky dvakrát: odpojené a potom pripojené. Vo Windows vypisuje route print -4 trasy IPv4 s prefixom cieľa, rozhraním, ďalším skokom a metrikou. Zaznamenajte riadok, ktorý by pre daný cieľ skutočne vyhral, namiesto počítania záznamov obsahujúcich slovo VPN.

Výber prebieha najprv podľa najdlhšieho prefixu a potom podľa metriky, takže konkrétnejšia miestna trasa môže poraziť trasu tunela bez toho, aby vyzerala nesprávne. Ak je zamýšľaný cieľ v 10.24.0.0/16, zdravý klient ukazuje zodpovedajúcu trasu na rozhraní VPN, zatiaľ čo zlyhávajúci klient posiela rovnakú adresu svojej predvolenej bráne.

Konfliktný miestny prefix môže vyvolať rovnaký príznak. Predtým, než niečo pridáte, rozhodnite, ktorý z dvoch prípadov máte: žiadnu trasu tunela, alebo trasu tunela, ktorá prehráva s konkrétnejšou.

TTL expired nie je chyba distribúcie trás

Ping, ktorý vracia TTL expired in transit, hovorí, že balík vyčerpal svoj limit skokov, čo zvyčajne znamená slučku preposielania, nie pokazený ovládač VPN. Ping vo Windows prijíma TTL až 255 a zvýšenie hodnoty slučku neopraví; len oddiali rovnakú chybu. Berte správu ako príznak cesty, nie ako dôkaz o distribúcii trás.

Pomocou tracert -4 10.24.1.10 zistite, kde sa cesta opakuje. Ak sa tie isté dva skoky objavujú znova a znova, hľadajte trasu, ktorá posiela prevádzku určenú tunelu späť do tunela alebo do miestneho smerovača, ktorý ju vracia.

Znova vygenerujte balík na bráne, ktorá ho vlastní

Microsoft dokumentuje, že klientske balíky Windows treba po relevantných zmenách topológie znova stiahnuť a nainštalovať. Získajte aktuálny balík z brány Azure, ktorá obsluhuje tento profil, a potom ho použite podporovaným postupom pre daného klienta. Nahradenie spustiteľného súboru nesúvisiacej aplikácie VPN nie je rovnaká operácia ako opätovné vygenerovanie nastavení špecifických pre bránu. Znova stiahnuť balík je lacné; hádať miestne trasy nie.

Znova sa pripojte a znova prečítajte trasu pre pôvodný cieľ. Uchovajte riadky pred a po spolu so záznamom o zmene, aby bol výsledok presnejší než preinštaloval som klienta.

Scenáre smerovania Azure P2S oddeľujú priamo prepojené VNet od sietí dostupných inými tunelmi a nový balík nemôže urobiť prepojenie tranzitívnym. Niektoré scenáre Windows site-to-site alebo BGP vyžadujú aj ručne nastavené vzdialené trasy, takže obnovenie balíka nie je univerzálny mechanizmus distribúcie trás.

Nechajte dočasnú trasu dočasnou

Ručná trasa môže izolovať chýbajúcu klientsku trasu, ale stavajte ju zo skutočného návrhu: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bez trvalého príznaku, aby pri reštarte zmizla. Index rozhrania a ďalší skok vyberte z pripojeného adaptéra VPN, nie z odhadu.

Nenechávajte experimentálnu trasu ako trvalého konkurujúceho vlastníka. Budúce aktualizácie profilu môžu pridať rovnaký prefix s inou metrikou a ručný záznam potom potichu rozhodne, ktorá cesta vyhrá. Krok odstránenia zaznamenajte do zmeny.

Keď je správna trasa aktívna, testujte cieľovú aplikáciu, nie ping. Ak balíky dorazia do Azure, ale služba stále zlyháva, skontrolujte skupinu zabezpečenia siete a spätnú cestu, pretože tie sú oddelené od toho, či sa notebook prefix naučil.