Dividita tunelo en Windows: la pordega skatolo kaj la mankanta prefikso

La tunelo raportas sin konektita kaj la vikio ankoraŭ ŝarĝiĝas. Tiam elŝuto haltas kaj la kunhavo sur la breto ĉesas respondi. La tunelo faris sian taskon, kaj la profilo simple postulis ĉiun celon.

Windows traktas VPN-konekton kiel itineran decidon. Ĝis tiu decido mallarĝiĝos, la maŝino kondutas kvazaŭ ĝi translokiĝis al la oficejo.

Kial funkcianta tunelo sentiĝas kiel interrompo

Profilo rajtigita uzi la malproksiman pordegon instalas implicitan itineron tra la tunelo. Ĉiu celo, kiu ne estas sur la loka ligo, tiam eliras tra la fajroŝirmilo de la oficejo. Lokaj kunhavoj ĉesas respondi, ĉar ilia trafiko nun vojaĝas al alia kontinento kaj reen. Nenio en la stato de la kliento spegulas tion.

La simptomoj estas konfuzaj intence. Noma solvado eble ankoraŭ funkcias dum la kunhavo tempas for, aŭ la malo. Uzanto raportas la VPN kiel rompitan, la kliento raportas sin kiel bonan, kaj ambaŭ asertoj estas ĝustaj.

La markobutono kaŝita en la IPv4-dialogo

La agordo troviĝas kelkajn dialogojn profunde. Malfermu ncpa.cpl, dekstre alklaku la konekton, poste IPv4-ecojn, poste Altprogresintajn, kaj malŝaltu la opcion, kiu lasas la konekton fariĝi la malproksima implicita pordego. Tiu unu skatolo decidas, ĉu la profilo estas plena tunelo. Ĉio alia en la profilo ankoraŭ validas.

Komparu route print -4 antaŭ kaj post la rekonekto. La ero 0.0.0.0, kiu antaŭe indikis la tunelon, devus malaperi, kaj la entreprenaj prefiksoj devus ankoraŭ esti tie.

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

Ŝanĝi la metrikon de la interfaco ne estas anstataŭaĵo. Metriko nur decidas inter du konkurantaj implicitaj itineroj, kaj kliento, kiu reinstallas sian propran implicitan itineron ĉe konekto, gajnas tiun konkuradon kiel ajn la nombro estas agordita.

La prefikso, kiun neniu listigis

Dividita tunelado malkaŝas ĝuste la prefiksojn registritajn en la profilo. Oficeja subreto aldonita post kiam la profilo estis skribita restas neatingebla dum la tunelo estas tute sana. La raporto tiam alvenas kiel unu rompita servilo anstataŭ rompita VPN.

Mane aldonita itinero kovras la breĉon ĝis la pordega adreso ŝanĝiĝos. Registri la prefikson en la konekto estas pli firma, ĉar la prefikso tiam sekvas la konekton anstataŭ divenitan adreson.

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

Legu la konservitan liston kaj la vivan tabelon kune. Konservita prefikso povas ekzisti dum la tabelo neniam ricevas ĝin, kio okazas kiam administra agento filtas itinerojn post kiam la konekto leviĝas. La malo ankaŭ okazas, kun registra itinero indikanta al adaptilo, kiu estas malaktiva. Neniu el la du vidoj sola rakontas la tutan historion.

Pruvi la rezulton post restarto

Spuru en ambaŭ direktojn kaj solvu laŭ nomo. Publika spuro devus eliri tra la provizanto, interna spuro devus eniri la tunelon, kaj interna gastiganto devus respondi laŭ nomo, ne nur laŭ adreso.

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

Ripetu post malkonekto, rekonekto kaj unu restarto. Prefikso, kiu postvivas manan rekonekton kaj malaperas post restarto, neniam estis konservita en la profilo.

Tenu ankaŭ la printilon kaj la NAS en la testo, ĉar dividita tunelo, kiu fortranĉas la aparatojn apud la tekkomputilo, solvis unu problemon kreante pli malgrandan kaj pli ĝenan. La referenco de Microsoft pri Add-VpnConnectionRoute estas la loko, kie vi kontrolu la literumon de parametroj kontraŭ via modula versio.