Windowsi VPN võtab kogu liikluse? Eemaldage selle vaikimisi marsruut

Tühjendage märkeruut „Kasuta kaugvõrgus vaikimisi lüüsi“, kustutage lükatud vaikimisi marsruut, lisage kontori eesliited tagasi ja kontrollige seejärel uuesti DNS-i ja IPv6-te.

Ühendate kontori VPN-iga ja iga leht brauseris hakkab käima läbi selle võrgu: failiserver on kiire, kõik muu on aeglane, filtreeritud või kadunud. Klient ei käitu valesti; profiil nõudis täistunnelit. Selle peatav lüliti on üks märkeruut dialoogis, mida moodne rakendus Seaded ei näita, ja lüüs saab igal ühendusel uuesti sõna. See juhend järgib järjekorda, mille Windowsi liides tegelikult esitab, ja käsitleb seejärel kontrolle, mis ikka veel ebaõnnestuvad, kui marsruutide tabel paistab korras.

Alustage adapteri atribuutidest, mitte seadetest

Rakendus Seaded loetleb profiili jaotises Võrk ja Internet ning seejärel VPN, kuid pakub ainult üldvalikuid. Otsus vaikimisi lüüsi kohta elab adapteril. Avage klassikaline adapteriloend Win+R ja ncpa.cpl abil, paremklõpsake VPN-ühendusel, valige Atribuudid, valige Internetiprotokoll versioon 4, valige uuesti Atribuudid ja seejärel Täpsemalt. Tühjendage Kasuta kaugvõrgus vaikimisi lüüsi märkeruut ja kinnitage väljumine kõigist kolmest dialoogist.

Ühendage enne testimist uuesti, sest märkeruut rakendub tunneli loomisel ja olemasolev sessioon hoiab tabelit, mille see ehitas. Kui adapter puudub, kui klient on lahti ühendatud, ühendage üks kord ja avage aken uuesti. Tarnija klient, mis paigaldab TAP- või Wintun-adapteri ilma IPv4 atribuudileheta, ei oma seda dialoogi üldse; nende puhul on sama otsus jagatud tunneli valik kliendi enda seadetes ja adapteri märkeruut on vale koht, kust otsida.

Sama muudatus PowerShelli kaudu

Windowsi VPN-hoidlas loodud profiili puhul saab seade skriptida, mida soovite, kui masin ehitatakse sageli uuesti üles:

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

See cmdlet jõuab ainult selle hoidla profiilideni. Kolmanda osapoole kliendi lisatud ühendus ei ilmu ja käsk ebaõnnestub nimeveaga, mis näeb välja nagu trükiviga. Pange tähele ka seda, mida lüliti ei tee: see takistab kliendil vaikimisi marsruudi paigaldamist, kuid ei eemalda marsruute, mida lüüs ühendamise ajal lükkab, nii et järgmine osa on paljudes võrkudes endiselt vajalik.

Kui lüüs lükkab vaikimisi marsruudi tagasi

Lugege esmalt tabelit. Kaks vaikimisi kirjet erinevate mõõdikutega tähendavad, et profiili muudatus toimis ja lükatud marsruut asendas selle ikkagi:

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

Kustutage tunnelile kuuluv vaikimisi marsruut ja jätke füüsiline alles. Kasutage kolmanda käsu liideseindeksit, mitte adapteri aliast, sest aliase edastavad skriptid katkevad niipea, kui kuvatav nimi muutub:

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

Kustutamine võtab kontori endaga kaasa, seega lisage ettevõtte eesliited tunneli lüüsi kaudu tagasi. See on rida, mille inimesed vahele jätavad, ja see on põhjus, miks pärast edukat jagatud tunneli muudatust järgneb «VPN lakkas töötamast»:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Miski sellest ei ela uuestiühendust üle, mis on aus käitumine, mitte viga: adapter ehitatakse uuesti ja klient rakendab uuesti seda, milles profiil ja lüüs kokku leppisid. Kui vaikimisi marsruut ilmub iga kord uuesti, on lüüs seadistatud jagatud tunnelit keelduma ja lükkab seda edasi või katkestab sessiooni. See on võrguoperaatori poliitika ja taotlus kuulub sinna, mitte kohalikku skripti, mis võitleb sellega üks kord ühenduse kohta.

Kontrollige uuesti DNS-i, IPv6-t ja mõõdikuid pärast ühte uuestiühendust

IPv4 vaikimisi marsruudi eemaldamine ei tõesta midagi teise perekonna ega nimede lahendamise kohta. Tunnel võib kanda IPv6-t, samal ajal kui IPv4 vaikimisi jääb kohalikuks, ja lükatud resolverite nimekiri võib hoida sisemised nimed töös, samal ajal kui seda kasutavad päringud lähevad teist teed. Kontrollige kõiki kolme, enne kui nimetate selle tehtuks:

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

Kui seisund taastub igal ühendusel, viige käsud ühendusepõhisesse toimingusse, selle asemel et tabelit käsitsi muuta: ühendussündmusel käivitatav ajastatud ülesanne või kliendi enda jagatud tunneli säte, kus see on olemas. Hoidke liideseindeksit muutujas ja otsige see käitusajal üles, sest see võib muutuda, kui adaptereid lisatakse või eemaldatakse.

Otsustage, millest loobusite

Kohalikku internetiliiklust kontor enam ei kontrolli ega filtreeri ning kõik, mis avaldatakse ainult tunneli kaudu, vajab nüüd oma marsruuti. Mõned organisatsioonid peavad jagatud tunnelit poliitika rikkumiseks, seega kinnitage see enne hallatava seadme muutmist; lükatud vaikimisi marsruut on mõnikord jõustamismehhanism, mitte õnnetus. Set-VpnConnectioni dokumentatsioon loetleb jagatud tunneli parameetri ja profiilitüübid, millele see kehtib.

Seejärel kontrollige kindlas järjekorras: kellele kuulub vaikimisi marsruut, tavaline sirvimine, üks ettevõtte host aadressi järgi, üks sisemine nimi ja samad neli pärast ühte uuestiühendust. Kui sirvimine töötab ja ettevõtte host ebaõnnestub, puudub eesliite marsruut, mitte eemaldatud vaikimisi marsruut, ja seda on palju odavam parandada kui profiili uuesti üles ehitada.

Seotud artiklid