Miért tör meg egy széles VPN-útvonal néhány nyilvános oldalt

A legtöbb oldal betöltődik, kettő vagy három időtúllépést kap, és a böngésző a kapcsolatot hibáztatja. A meghiúsuló oldalakban van valami közös, ami a működőkben nincs: a feloldott címeik egy olyan előtagba esnek, amelyet a VPN telepített. Egy elég széles útvonal, amely lefed egy nyilvános tartományt, olyan forgalmat fog el, amelyet az alagút soha nem volt hivatott szállítani, és a tünet webhelyproblémának látszik útválasztási döntés helyett.

Oldja fel a meghiúsuló nevet, majd nézze az útválasztási táblázatot, ne a böngészőt.

A címet hasonlítsa össze, ne az oldal nevét

Keresse meg azt a címet, amelyet az ügyfél valóban megpróbált, majd ellenőrizze, melyik útvonal illeszkedik hozzá. A 45.61.20.10 belsejében lévő cél a 45.0.0.0/8 alá esik, ha ez az előtag jelen van, akkor is, ha magának az oldalnak semmi köze az alagúthoz. A meghiúsuló cím és a telepített előtagok összehasonlítása kivonási feladat, nem találgatás.

A Windows mindkét félre közvetlenül válaszol, és egy lekérdezés megmutatja, melyik interfész és melyik következő ugrás nyerte meg a kiválasztást. Oldja fel a nevet kétszer, ha az oldal több címet ad vissza. Jegyezze fel mindegyiket a hozzá illeszkedő útvonallal. A különböző címek különböző válaszokat adhatnak, és közülük csak egy lehet a meghiúsuló eset.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

A legkonkrétabb illeszkedő előtagot olvassa, ne az első ismerősnek tűnő sort. A táblázatban lévő útvonal nem bizonyítja, hogy megnyerte a lekérdezést; a leghosszabb egyezés teszi ezt. Két előtag illeszkedhet egy címhez, és csak az egyik kapja meg a csomagot. A vesztes a táblázatban marad, és a listában ugyanolyan valósnak látszik.

Jegyezze fel az előtagot, annak interfészét és a feloldott címet. Ez a három érték a teljes diagnózis.

Derítse ki, ki telepítette az útvonalat

Az útvonalak négy helyről érkeznek: a natív VPN-profilból, egy felügyeleti házirendből, egy kapcsolódási szkriptből vagy egy teljesen más ügyfélből. Az élő bejegyzés törlése megerősítheti a jelentőségét, de a következő kapcsolat újra létrehozza a mentett konfigurációból, tehát a forrást kell megváltoztatni.

Először a profil útvonallistáját ellenőrizze, majd a felügyeleti házirendet, majd minden szkriptet, amely kapcsolódáskor fut. Ez a sorrend megfelel annak, milyen gyakran bizonyul felelősnek az egyik vagy a másik. Emellett egy rétegre korlátozza a változtatást három helyett.

Olvassa el figyelmesen a natív osztályalapú viselkedést

A natív Windows-profiloknak van egy dokumentált beállítása, NativeProfile/DisableClassBasedDefaultRoute, amely az interfész címéből származtatott automatikus útvonalat vezérli. A 45-tel kezdődő profilcím e viselkedés mellett 45.0.0.0/8 bejegyzést hozhat létre, és így egyetlen nyilvános cím elkap egy egész A-osztályú tartományt.

A tulajdonság neve félrevezető olvasatra csábít: true-ra állítva kikapcsolja a származtatást, false pedig bekapcsolja. Nem ugyanaz az objektum, mint az alapértelmezett útvonal, és nem vezérli azokat a harmadik féltől származó ügyfeleket, amelyek saját előtagokat telepítenek.

Ha a származtatás a bizonyított ok, javítsa a profilt a felügyeleti tulajdonosán keresztül, és adja meg kifejezetten a tervezett privát előtagokat. Ha egy szkript adta hozzá a bejegyzést, javítsa a szkriptet. Egy megmagyarázatlan széles útvonal másikkal való helyettesítése megváltoztatja a tünetet anélkül, hogy megválaszolná a kérdést.

Javítsa a forrást, majd ellenőrizze újra mindkét útvonalat

A változtatás után csatlakozzon újra, és ismételje meg a lekérdezést egy meghiúsuló nyilvános oldalra és egy olyan erőforrásra, amelynek az alagutat kell használnia. Az elsőnek most a fizikai interfészre kell feloldódnia, a másodiknak pedig továbbra is a VPN-t kell választania. Ne álljon meg az első sikerélmény el. Egy olyan javítás, amely a privát hozzáférést is megtöri, egy hibát cserélt egy másikra.

Ugyanakkor vizsgálja felül a kiszolgáló címtervét. A nyilvános térrel átfedő készlet újra és újra ezt a hibatípust okozza. Az üzemeltető által szándékosan választott tartomány más beszélgetést érdemel, nem automatikus újraszámozást.

Az MTU növelése vagy a DNS törlése nem javítja azt az előtagot, amely továbbra is az alagútba irányítja azt a címet. Először a kiválasztást tesztelje, majd az útvonalat.