Hogyan távolítsuk el a Windows VPN által hagyott elavult útvonalat
Keresse meg a valóban elavult bejegyzést, nézze meg az eltávolítását a megfelelő házirendtárral szemben, és erősítse meg, hogy a keresés a várt interfészt választja.
A munkamenet órákkal ezelőtt véget ért, az adapter eltűnt, az útvonal mégis ott van a táblázatban, és a 42-es interfészre mutat. A sor törlése egyetlen parancs; annak eldöntése, hogy ez a megfelelő sor, négy ellenőrzést igényel. Az útvonaltáblázat közös, ezért a széles körű eltávolítás kiveszi azokat az útvonalakat is, amelyeket más kapcsolatok még használnak, köztük azt, amelyik az alagutat viszi. Az alábbi lépések mindegyike szűkíti a célpontot, amíg már csak egy bejegyzés illeszkedhet.
1. Döntse el, hogy a bejegyzés elavult vagy szándékos
Az a bejegyzés, amely túlélt egy újraindítást, valahol le lett írva, és az a hely általában döntés, nem baleset. Az osztott alagút olyan útvonalaktól függ, amelyek pontosan úgy néznek ki, mint a maradékok, és egy előtagot az alagúton átküldő házirend egyetlen listában megkülönböztethetetlen egy elavult bejegyzéstől. Kérdezze meg, mikor jelent meg az útvonal: amelyik csak az alagút fennállása alatt létezik, az ügyfél konfigurációjához tartozik, tehát a tisztító parancs nem megfelelő eszköz. Távolítson el egy szándékos útvonalat, és a következő kapcsolat ott hibázik, ahol senki sem figyeli.
A végpont útvonala külön figyelmeztetést érdemel. Amikor az ügyfél hosztútvonalat ad a VPN-kiszolgálóhoz, hogy a titkosított csomagok a helyi kapcsolaton keresztül elérjék, ennek az útvonalnak a törlése a következő újracsatlakozáskor összeomlasztja az alagutat, és a tünet kiszolgálóhibaként olvasható. Hasonlítsa össze a célt azzal a címmel, amelyre az ügyfél csatlakozik, mielőtt bármihez nyúlna: egyetlen nyilvános cím, amely megfelel a VPN-kiszolgálónak, a külső útvonal, nem szemét.
2. Jegyezze fel a bejegyzést azonosító négy mezőt
Egy előtag önmagában nem azonosító, mert két interfész is tarthat útvonalakat ugyanahhoz a célhoz. Jegyezze fel a cél-előtagot, az interfész indexét, a következő ugrást és a házirendtárat, mert ez a négy érték pontosan egy bejegyzést ír le. Egyetlen lista mindet megadja:
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetricA metrika szerinti rendezés kiemeli azokat az útvonalakat, amelyeket a gép valóban előnyben részesít, és a maradék általában itt ül. Hasonlítsa össze a bejegyzést, amíg az alagút fennáll, majd újra, miután leesett: az az útvonal, amely az adapterrel együtt távozik, az ügyfélé volt, és amelyik marad, azt valami más írta. A házirendtár az a mező, amelyet az emberek kihagynak, és ez magyarázza az újramegjelenést, mert az aktív tárból eltávolított bejegyzés a következő házirend-frissítés után visszatér. Jegyezze fel a négy értéket, mielőtt bármit futtat, ami megváltoztatja az állapotot.
3. Nézze meg az eltávolítást, majd távolítson el egy bejegyzést
A Remove-NetRoute ugyanazt az előtagot és interfészindexet fogadja el, amelyet a Get-NetRoute kiírt, és van előnézeti kapcsolója, így semmit sem kell kitalálni. Futtassa a párt ebben a sorrendben:
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42Az előnézet kiírja az objektumot, amelyet törölne, ezért hasonlítsa össze az előtagot, az interfészt és a következő ugrást a jegyzeteivel, mielőtt elengedi a kapcsolót. Egyik sor sem ér el állandó bejegyzést, mert az aktív tár az alapértelmezett; adja hozzá a -PolicyStore PersistentStore kapcsolót, amikor az azonosított útvonal ott él, különben az eltávolítás működni látszik, és a bejegyzés a következő házirend-frissítéskor visszatér. Tartson fenn sávon kívüli helyreállítási utat, amikor a munkamenet távoli, mert a saját kapcsolatát vivő útvonal törlése megszakítja azt. Soha ne nyúljon a táblázatot törlő parancs után.
4. Keresse meg, melyik összetevő teszi vissza
A törlés nem javítás, amíg a tulajdonos még mindig az útvonal telepítésére van beállítva. A tulajdonos általában három közül egy: a VPN-ügyfél profilja az osztott alagút listájával, egy parancsfájl vagy ütemezett feladat, amely bejelentkezéskor útvonalakat ad hozzá, vagy a gépre alkalmazott tartományi házirend. Először a profilt ellenőrizze, mert minden csatlakozáskor lefut:
Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStoreAz állandó bejegyzések bármi csatlakoztatása nélkül láthatók, ezért az az útvonal, amely VPN-munkamenet nélkül visszatér egy újraindítás után, szinte mindig abban a tárban vagy egy indítóparancsfájlban él. Javítsa ott a tulajdonost, és a kézi törlés ellenőrzéssé válik kezelés helyett.
5. Ellenőrizze a keresést, a szomszédokat és a feljegyzést
A tiszta eredmény nem az, hogy az útvonal eltűnt; hanem egy keresés, amely most a várt interfészt választja. Kérdezze meg a géptől, hová menne az érintett előtag felé tartó csomag, mert a maradék még mindig a halott indexet nevezi meg, míg a tiszta válasz a kapcsolaton lévő interfészt vagy a helyes átjárót nevezi meg. A Find-NetRoute erre egy címre ad választ egyszerre:
Find-NetRoute -RemoteIPAddress 10.20.4.7Ezután teszteljen egy szomszédot: válasszon egy második előtagot, amelyre az osztott alagútnak még szüksége van, és erősítse meg, hogy a keresése változatlan, mert egy útvonallal többet kivenni az a hiba, amelyre ez a tisztítás csábít. Indítsa újra az eredetileg sikertelen alkalmazást, és jegyezze fel, melyik összetevő birtokolja most az előtagot. A Microsoft Get-NetRoute dokumentációja felsorolja azokat a mezőket, amelyeket a második lépésben felírt. Hat hónap múlva ez a feljegyzés az, ami megakadályozza, hogy ugyanazt a bejegyzést kétszer diagnosztizálják.