Razdeljen tunel v Windows: polje prehoda in manjkajoča predpona

Windows pošilja vse skozi tunel, dokler ne odkljukate enega polja, nato pa premalo, dokler ne dodate podomrežja. Oboje spada k isti spremembi.

Tunel sporoča, da je povezan, in wiki se še nalaga. Nato se prenos ustavi in skupna mapa na polici preneha odgovarjati. Tunel je opravil svoje delo, profil pa si je preprosto lastil vsak cilj.

Windows obravnava povezavo VPN kot odločitev o usmerjanju. Dokler ta odločitev ni zožena, se stroj obnaša, kot da se je preselil v pisarno.

Zakaj delujoč tunel deluje kot izpad

Profil, ki sme uporabljati oddaljeni prehod, namesti privzeto pot skozi tunel. Vsak cilj, ki ni na lokalni povezavi, nato odide skozi pisarniški požarni zid. Lokalne skupne mape prenehajo odgovarjati, ker njihov promet zdaj potuje na drugo celino in nazaj. Nič v stanju odjemalca tega ne odraža.

Simptomi so namerno zavajajoči. Razreševanje imen lahko še deluje, medtem ko skupna mapa poteče, ali obratno. Uporabnik poroča, da je VPN pokvarjen, odjemalec poroča, da je v redu, in obe trditvi sta točni.

Kljukica, skrita v pogovornem oknu IPv4

Nastavitev je nekaj pogovornih oken globlje. Odprite ncpa.cpl, z desno tipko kliknite povezavo, nato lastnosti IPv4, nato Napredno, in počistite možnost, ki povezavi dovoljuje, da postane oddaljeni privzeti prehod. To eno polje odloči, ali je profil poln tunel. Vse ostalo v profilu še vedno velja.

Primerjajte route print -4 pred ponovno povezavo in po njej. Vnos 0.0.0.0, ki je prej kazal na tunel, bi moral izginiti, podjetniške predpone pa bi morale ostati.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Spreminjanje metrike vmesnika ni nadomestilo. Metrika odloča le med dvema konkurenčnima privzetima potema, in odjemalec, ki ob vsaki povezavi znova namesti svojo privzeto pot, to tekmo zmaga ne glede na nastavljeno število.

Predpona, ki je nihče ni navedel

Razdeljen tunel izpostavi točno tiste predpone, ki so zapisane v profilu. Pisarniško podomrežje, dodano po pisanju profila, ostane nedosegljivo, medtem ko je tunel povsem zdrav. Poročilo potem prispe kot en pokvarjen strežnik in ne kot pokvarjen VPN.

Ročno dodana pot premosti vrzel, dokler se naslov prehoda ne spremeni. Zapis predpone v povezavi je trdnejši, ker predpona potem sledi povezavi namesto ugibanega naslova.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Preberite shranjen seznam in živo tabelo skupaj. Shranjena predpona lahko obstaja, medtem ko je tabela nikoli ne prejme, kar se zgodi, ko upravni agent filtrira poti po dvigu povezave. Zgodi se tudi obratno, ko pot v registru kaže na onemogočen vmesnik. Noben od obeh pogledov sam ne pove cele zgodbe.

Dokazovanje rezultata po ponovnem zagonu

Sledite v obe smeri in razrešite po imenu. Javna sled bi morala iti ven skozi ponudnika, notranja sled bi morala vstopiti v tunel, in notranji gostitelj bi moral odgovoriti po imenu in ne le po naslovu.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Ponovite po odklopu, ponovni povezavi in enem ponovnem zagonu. Predpona, ki preživi ročno ponovno povezavo in izgine po ponovnem zagonu, ni bila nikoli shranjena v profilu.

V preizkusu pustite tudi tiskalnik in NAS, ker je razdeljen tunel, ki odreže naprave ob prenosniku, rešil en problem tako, da je ustvaril manjšega in bolj motečega. Microsoftova referenca za Add-VpnConnectionRoute je mesto, kjer preverite črkovanje parametrov glede na različico svojega modula.

Sorodni članki