A Windows VPN minden forgalmat elvisz? Távolítsa el az alapértelmezett útvonalat

Csatlakozik az irodai VPN-hez, és a böngésző minden oldala elkezd azon a hálózaton átmenni: a fájlszerver gyors, minden más lassú, szűrt vagy eltűnt. Az ügyfél nem viselkedik rosszul; a profil teljes alagutat kért. A kapcsoló, amely ezt leállítja, egyetlen jelölőnégyzet egy olyan párbeszédablakban, amelyet a modern Gépház alkalmazás nem mutat, és az átjárónak minden kapcsolatnál újra szava van. Ez a bemutató azt a sorrendet követi, amelyet a Windows felülete valóban mutat, majd azokat az ellenőrzéseket tárgyalja, amelyek akkor is elbuknak, amikor az útvonaltábla helyesnek látszik.

Kezdje az adapter tulajdonságaiban, ne a Gépházban

A Gépház alkalmazás a profilt a Hálózat és internet, majd a VPN alatt listázza, de csak általános beállításokat mutat. Az alapértelmezett átjáróról szóló döntés az adapteren él. Nyissa meg a klasszikus adapterlistát a Win+R és a ncpa.cpl használatával, kattintson jobb gombbal a VPN-kapcsolatra, válassza a Tulajdonságok, majd az Internetprotokoll 4-es verzió, ismét a Tulajdonságok, végül a Speciális lehetőséget. Törölje az Alapértelmezett átjáró használata a távoli hálózaton jelölését, és erősítse meg a kilépést mindhárom párbeszédablakból.

A tesztelés előtt csatlakozzon újra, mert a jelölőnégyzet az alagút létrehozásakor érvényesül, és a meglévő munkamenet megtartja az általa épített táblát. Ha az adapter hiányzik, miközben az ügyfél le van választva, csatlakozzon egyszer, és nyissa meg újra az ablakot. Az a szállítói ügyfél, amely IPv4-tulajdonságlap nélküli TAP- vagy Wintun-adaptert telepít, egyáltalán nem rendelkezik ezzel a párbeszédablakkal; számukra ugyanez a döntés az ügyfél saját beállításaiban található osztott alagút opció, és az adapter jelölőnégyzete a rossz hely a kereséshez.

Ugyanez a változtatás PowerShellből

A Windows VPN-tárban létrehozott profil esetében a beállítás szkriptelhető, ami pontosan az, amit szeretne, ha a gépet gyakran újratelepítik:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Ez a cmdlet csak az adott tár profiljait éri el. A harmadik féltől származó ügyfél által hozzáadott kapcsolat nem jelenik meg, és a parancs névhibával bukik el, amely elírásnak tűnik. Figyelje azt is, mit nem tesz meg a kapcsoló: megakadályozza, hogy az ügyfél alapértelmezett útvonalat telepítsen, de nem távolítja el azokat az útvonalakat, amelyeket az átjáró kapcsolódáskor lenyom, ezért a következő szakasz sok hálózaton továbbra is szükséges.

Amikor az átjáró visszanyomja az alapértelmezettet

Először olvassa el a táblát. Két alapértelmezett bejegyzés eltérő metrikával azt jelenti, hogy a profil módosítása működött, és a lenyomott útvonal mégis lecserélte:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Törölje az alagúthoz tartozó alapértelmezett útvonalat, és tartsa meg a fizikait. A harmadik parancs interfészindexét használja, ne az adapter álnevét, mert az álnevet átadó szkriptek azonnal eltörnek, amikor a megjelenített név megváltozik:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

A törlés magával viszi az irodát, ezért adja vissza a vállalati előtagokat az alagút átjáróján keresztül. Ez az a sor, amelyet az emberek kihagynak, és ez az oka, hogy «a VPN leállt» egy sikeres osztott alagút módosítás után következik:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Ebből semmi sem éli túl az újracsatlakozást, ami őszinte viselkedés, nem hiba: az adapter újraépül, és az ügyfél újra alkalmazza azt, amiben a profil és az átjáró megegyezett. Ha az alapértelmezett útvonal minden alkalommal visszatér, az átjáró úgy van beállítva, hogy elutasítsa az osztott alagutat, és továbbra is lenyomja, vagy eldobja a munkamenetet. Ez a hálózat üzemeltetőjének szabályzata, és a kérés oda tartozik, nem egy helyi szkripthez, amely kapcsolatonként egyszer harcol ellene.

Ellenőrizze újra a DNS-t, az IPv6-ot és a metrikákat egy újracsatlakozás után

Az IPv4 alapértelmezett útvonal eltávolítása semmit sem bizonyít a másik családról vagy a névfeloldásról. Az alagút vihet IPv6-ot, miközben az IPv4 alapértelmezett helyben marad, és egy lenyomott feloldólista működésben tarthatja a belső neveket, miközben az azt használó lekérdezések más úton járnak. Mindhármat ellenőrizze, mielőtt késznek nevezi:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Ha az állapot minden kapcsolatnál visszaáll, helyezze át a parancsokat kapcsolatonkénti műveletbe a tábla kézi szerkesztése helyett: a kapcsolódási eseményre indított ütemezett feladat, vagy az ügyfél saját osztott alagút beállítása, ahol van ilyen. Tartsa az interfészindexet változóban, és futáskor keresse meg, mert változhat, amikor adaptereket adnak hozzá vagy távolítanak el.

Döntse el, miről mondott le

A helyi internethasználatot már nem vizsgálja vagy szűri az iroda, és mindennek, amit csak az alagúton keresztül tesznek közzé, most saját útvonalra van szüksége. Egyes szervezetek az osztott alagutat szabályzat megsértésének tekintik, ezért ezt erősítse meg egy felügyelt eszköz módosítása előtt; a lenyomott alapértelmezett néha nem baleset, hanem a kikényszerítés mechanizmusa. A Set-VpnConnection dokumentációja felsorolja az osztott alagút paraméterét és azokat a profiltípusokat, amelyekre vonatkozik.

Ezután rögzített sorrendben ellenőrizze: kié az alapértelmezett útvonal, a szokásos böngészés, egy vállalati gazdagép cím szerint, egy belső név, és ugyanez a négy egyetlen újracsatlakozás után. Ha a böngészés működik, és a vállalati gazdagép elbukik, akkor az előtagútvonal hiányzik, nem az eltávolított alapértelmezett, és ezt sokkal olcsóbb javítani, mint a profilt újraépíteni.