Podijeljeni tunel na Windowsu: okvir pristupnika i prefiks koji nedostaje

Windows šalje sve kroz tunel dok ne poništite jedan okvir za potvrdu, a zatim premalo dok ne dodate podmrežu. Oboje pripada istoj izmjeni.

Tunel javlja da je povezan, a wiki se još učitava. Zatim se preuzimanje zaglavi i dijeljeni resurs na polici prestane odgovarati. Tunel je odradio svoj posao, a profil je jednostavno prisvojio svako odredište.

Windows tretira VPN vezu kao odluku o ruti. Dok se ta odluka ne suzi, računalo se ponaša kao da se preselilo u ured.

Zašto tunel koji radi izgleda kao prekid

Profil kojem je dopušteno korištenje udaljenog pristupnika instalira zadanu rutu kroz tunel. Svako odredište koje nije na lokalnoj vezi tada izlazi kroz uredski vatrozid. Lokalni dijeljeni resursi prestaju odgovarati jer njihov promet sada putuje na drugi kontinent i natrag. Ništa u stanju klijenta to ne odražava.

Simptomi su namjerno zbunjujući. Razrješavanje imena može još raditi dok dijeljeni resurs istekne, ili obrnuto. Korisnik prijavljuje VPN kao pokvaren, klijent prijavljuje sebe kao ispravnog, i obje su tvrdnje točne.

Okvir za potvrdu skriven u dijalogu IPv4

Postavka je nekoliko dijaloga duboko. Otvorite ncpa.cpl, desnom tipkom kliknite vezu, zatim svojstva IPv4, zatim Napredno, i poništite opciju koja vezi dopušta da postane udaljeni zadani pristupnik. Taj jedan okvir odlučuje je li profil puni tunel. Sve ostalo u profilu i dalje vrijedi.

Usporedite route print -4 prije i nakon ponovnog povezivanja. Unos 0.0.0.0 koji je prije pokazivao na tunel trebao bi nestati, a korporativni prefiksi bi trebali ostati.

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

Promjena metrike sučelja nije zamjena. Metrika odlučuje samo između dvije zadane rute koje se natječu, a klijent koji pri svakom povezivanju ponovno instalira svoju zadanu rutu pobjeđuje u tom natjecanju bez obzira na postavljeni broj.

Prefiks koji nitko nije naveo

Podijeljeni tunel izlaže upravo prefikse zapisane u profilu. Uredska podmreža dodana nakon što je profil napisan ostaje nedostupna dok je tunel potpuno zdrav. Izvještaj tada dolazi kao jedan pokvaren poslužitelj, a ne kao pokvaren VPN.

Ručno dodana ruta pokriva prazninu dok se adresa pristupnika ne promijeni. Zapisivanje prefiksa u vezi je čvršće, jer prefiks tada slijedi vezu umjesto pretpostavljene adrese.

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

Čitajte spremljeni popis i živu tablicu zajedno. Spremljeni prefiks može postojati dok ga tablica nikad ne primi, što se događa kada upravljački agent filtrira rute nakon što se veza uspostavi. Obrnuto se također događa, s rutom u registru koja pokazuje na adapter koji je isključen. Nijedan pogled sam ne govori cijelu priču.

Dokazivanje rezultata nakon ponovnog pokretanja

Pratite u oba smjera i razriješite po imenu. Javno praćenje treba izaći kroz davatelja usluge, unutarnje praćenje treba ući u tunel, a unutarnji host treba odgovoriti po imenu, a ne samo po adresi.

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

Ponovite nakon prekida, ponovnog povezivanja i jednog ponovnog pokretanja. Prefiks koji preživi ručno ponovno povezivanje i nestane nakon ponovnog pokretanja nikada nije bio spremljen u profil.

Zadržite i pisač i NAS u testu, jer podijeljeni tunel koji odsijeca uređaje pokraj prijenosnika riješio je jedan problem stvorivši manji i iritantniji. Microsoftova referenca za Add-VpnConnectionRoute mjesto je na kojem provjeravate pisanje parametara prema verziji svojeg modula.

Povezani članci