Azure P2S: egy Windows-ügyfélnél eltűnnek az útvonalak egy VNet-változás után

Két laptop ugyanahhoz az Azure point-to-site átjáróhoz hitelesít, és csak az egyik éri el az újonnan csatlakoztatott VNetet. Mindkettő Connected állapotot mutat, tehát a hitelesítés nem a különbség; a célútvonalak azok. Kezdje a hibázó ügyfélnél, hasonlítson össze egyetlen célt, és csak utána döntse el, hogy a rést az átjárócsomag vagy a helyi útvonaltábla birtokolja.

A hibázó ügyfélnél kezdje, ne az átjárónál

Erősítse meg a topológiát, mielőtt a laptopot hibáztatná. Ellenőrizze, mely VNetek kapcsolódnak az átjáró VNetjéhez, és hogy az új hálózat közvetlenül peerelt-e, vagy külön site-to-site alagúton érhető el. Ha az új VNet egyáltalán nem kapcsolódik az átjáró VNetjéhez, egyetlen ügyfélcsomag sem tud oda irányítani, és a működő laptop a magyarázandó anomália. Írja le a választ, mert ez dönti el, ügyfelet vagy átjárót hibakeres-e.

Ha a topológia rendben van, állítsa a két laptopot egymás mellé. Ugyanaz az átjáró, ugyanaz a címkészlet, ugyanaz a protokoll és ugyanaz az ügyfélverzió az összehasonlítás, amit szeretne; minden más egy második változó, amelyet később ki kell zárnia.

Hasonlítson össze egy célt a route print segítségével

Válasszon egy engedélyezett erőforrás-IP-t, és hasonlítsa össze mindkét laptopot kétszer: leválasztva, majd csatlakoztatva. Windowson a route print -4 IPv4-útvonalakat listáz cél-előtaggal, interfésszel, következő ugrással és metrikával. Jegyezze fel azt a sort, amely valóban nyerne az adott célhoz, ahelyett hogy a VPN szót tartalmazó bejegyzéseket számolná.

A kiválasztás először a leghosszabb előtag, majd a metrika szerint történik, így egy konkrétabb helyi útvonal legyőzheti az alagút útvonalát anélkül, hogy hibásnak tűnne. Ha a kívánt cél a 10.24.0.0/16-on belül van, az egészséges ügyfél egyező útvonalat mutat a VPN-interfészen, míg a hibázó ügyfél ugyanazt a címet az alapértelmezett átjárójának küldi.

Egy ütköző helyi előtag ugyanazt a tünetet okozhatja. Mielőtt bármit hozzáadna, döntse el, melyik a két eset közül: egyáltalán nincs alagútútvonal, vagy az alagútútvonal veszít egy konkrétabbal szemben.

A TTL expired nem útvonal-elosztási hiba

Az a ping, amely TTL expired in transit ad vissza, azt jelzi, hogy a csomag elfogyasztotta ugrási keretét, ami általában továbbítási hurkot jelent, nem törött VPN-illesztőprogramot. A Windows ping legfeljebb 255-ös TTL-t fogad el, és az érték emelése nem javítja a hurkot; csak ugyanazt a hibát késlelteti. Kezelje az üzenetet az útvonal tüneteként, nem az útvonal-elosztásra vonatkozó bizonyítékként.

Használja a tracert -4 10.24.1.10 parancsot, hogy lássa, hol ismétlődik az útvonal. Ha ugyanaz a két ugrás jelenik meg újra és újra, keressen olyan útvonalat, amely az alagútba tartó forgalmat visszaküldi az alagútba vagy egy helyi routerbe, amely visszatovábbítja.

Azon az átjárón generálja újra a csomagot, amelyik birtokolja

A Microsoft dokumentálja, hogy a Windows-ügyfélcsomagokat a releváns topológiaváltozások után újra le kell tölteni és telepíteni. Szerezze be az aktuális csomagot az Azure-átjárótól, amely ezt a profilt kiszolgálja, majd alkalmazza az adott ügyfél támogatott eljárásával. Egy nem kapcsolódó VPN-alkalmazás futtatható fájljának cseréje nem ugyanaz a művelet, mint az átjáróspecifikus beállítások újragenerálása. A csomag újratöltése olcsó; a helyi útvonalakra való találgatás nem az.

Csatlakozzon újra, és olvassa újra az eredeti cél útvonalát. Őrizze meg az előtte és utána sorokat a változásrekorddal, hogy az eredmény pontosabb legyen, mint hogy újratelepítettem az ügyfelet.

Az Azure P2S útválasztási forgatókönyvek elválasztják a közvetlenül peerelt VNeteket a más alagutakon elérhető hálózatoktól, és egy új csomag nem tudja tranzitívvá tenni a peerelést. Egyes Windows site-to-site vagy BGP forgatókönyvek kézzel beállított távoli útvonalakat is igényelnek, ezért a csomagfrissítés nem univerzális útvonal-elosztási mechanizmus.

Hagyja ideiglenesnek az ideiglenes útvonalat

Egy kézi útvonal elkülönítheti a hiányzó ügyfélútvonalat, de a valódi tervezésből építse fel: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, a tartós jelző nélkül, hogy újraindításkor eltűnjön. Az interfészindexet és a következő ugrást a csatlakoztatott VPN-adapterből válassza, nem találgatásból.

Ne hagyjon egy kísérleti útvonalat állandó versengő tulajdonosként. A jövőbeli profilfrissítések ugyanazt az előtagot más metrikával adhatják hozzá, és akkor a kézi bejegyzés csendben eldönti, melyik útvonal nyer. Jegyezze fel az eltávolítás lépését a változásba.

Amikor a helyes útvonal aktív, a célalkalmazást tesztelje ping helyett. Ha a csomagok elérik az Azure-t, de a szolgáltatás továbbra is hibázik, ellenőrizze a hálózati biztonsági csoportot és a visszautat, mert ezek függetlenek attól, hogy a laptop megtanulta-e az előtagot.