VPN blokira lokalni LAN v sistemu Windows: pot ali politika odjemalca?

Tiskalnik, NAS ali razvojni stroj na lastni mizi prenehajo odgovarjati v trenutku, ko se poveže službeni VPN. Včasih en ukaz poti to popravi v sekundah; včasih je ista pot pravilna in paketi vseeno izginejo, kar pomeni, da gledate drugo težavo s podobnim simptomom. Odločitev se skrči na tri vprašanja, in prav napačen vrstni red je razlog, da ljudje preživijo cel večer z brisanjem in ponovnim dodajanjem poti.

Tri vprašanja pred vsakim ukazom

Prvič: ali obstaja vnos za lokalno predpono in ali kaže na fizični vmesnik? Drugič: ali odjemalec ob povezavi prejme dovoljenje ali zavrnitev lokalnega omrežja od prehoda? Tretjič: ali potrebujete samo odhodni dostop do LAN, ali mora tudi nekaj na internetu doseči storitev, ki teče na vašem računalniku?

Prvo vprašanje loči napako usmerjanja od napake filtriranja. Drugo pove, ali sme popravek poti sploh delovati. Tretje spremeni popravilo: pot popravi odhodni promet, medtem ko je nedosegljiva vhodna storitev običajno težava vezave poslušalca in povratne poti, ki jo pot še poslabša.

Vprašanje prvo: pot, filter ali ime

Preberite tabelo, preden ji kaj dodate. Indeks vmesnika je pomemben, ker je vsak ukaz poti spodaj zasidran vanj:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Neposredno povezana podmreža običajno ohrani pot na povezavi tudi ob aktivnem tunelu, zato lahko vnos obstaja, promet pa vseeno ne uspe. Ta kombinacija je podpis filtra, ki teče po usmerjanju, in to je primer, ko druga, natančnejša pot ne spremeni popolnoma ničesar.

Preizkusite ločeno po naslovu in po imenu. Če ping 192.168.1.50 odgovori in net view 192.168.1.50 ne, tabela usmerjanja nikoli ni bila težava: tunel je zamenjal razreševalnik in lokalno ime se ne razrešuje več. Dodajanje poti za to je zapravljeno delo.

Vprašanje drugo: ali prehod dovoljuje dostop do lokalnega LAN?

Komercialni odjemalec namesti več kot poti. Ob povezavi prejme politiko, in ta politika lahko vsebuje izrecno dovoljenje lokalnega omrežja. V namestitvah Cisco IPsec skupinska politika nosi nastavitev split-tunneling in ločeno zastavico dostopa do lokalnega LAN; potrditveno polje v odjemalcu je zahteva, ki jo prehod lahko zavrne. V AnyConnect profil nadzoruje sezname vključitve in izključitve razdelitve ter isto dovoljenje. V sistemu Windows RRAS sta ustreznika možnost privzetega prehoda v profilu in statične poti, ki jih dodeli strežnik.

Ko je zastavica izklopljena, je dokumentirano vedenje, da odjemalec blokira promet do neposredno povezane podmreže, čeprav obstaja veljavna, natančnejša pot. Zato lahko tudi poti, ki jih odjemalec ne poseduje, izginejo sekunde po tem, ko jih dodate: odjemalec znova gradi stanje, ki mu je bilo naročeno, in se ne bori proti vam.

Dnevnik odjemalca zabeleži odločitev ob povezavi, in branje je hitrejše od katerega koli poskusa na računalniku. Če dnevnik pravi, da je lokalni dostop blokiran, se ustavite: noben popravek iz ukazne vrstice tega ne preživi, in ostanejo le sprememba politike, doseg vira skozi tunel ali zaprtje odjemalca v virtualnem stroju in pustitev gostitelja v lokalnem omrežju.

Vprašanje tretje: katero smer potrebujete?

Odhodni promet do bližnje naprave je vprašanje usmerjanja. Usmerite predpono LAN na lokalni prehod z metriko, dovolj nizko, da premaga privzeto pot tunela:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Druga oblika pripne eno napravo, kar želite, ko je en naslov celotna zahteva. Ustreznik netsh zabeleži isto odločitev po imenu vmesnika namesto po indeksu:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Ukazi poti ne uspejo s Parameter ni pravilen, ko se naslov in maska ne ujemata, na primer naslov gostitelja z masko /24. Za pot podmreže uporabite omrežni naslov, za enega gostitelja pa masko gostitelja.

Vhodni promet je drugačen. Strežnik VNC ali SSH na istem računalniku postane nedosegljiv, ko odgovori na vhodno povezavo odidejo skozi prehod VPN in se nikoli ne vrnejo. Preden se dotaknete poti, preverite, na čem storitev posluša:

netstat -ano | findstr :5900

Poslušalec, vezan na en določen naslov, ne bo odgovoril na drugem vmesniku. Vezati ga na vse vmesnike je zavestna odločitev, sprejeta skupaj s pravilom požarnega zidu, omejenim na omrežje, ki mu zaupate. Šele po tem popravek poti obnovi povratno pot.

Uporabite najmanjšo spremembo, ki ustreza

Druga pogosta poteza je odkljukati »Uporabi privzeti prehod v oddaljenem omrežju« v naprednih lastnostih IPv4. To ohrani internetni promet lokalno, a naredi dvoje hkrati: VPN preneha biti privzeta pot in odjemalec preneha prejemati poti za oddaljeno omrežje, vključno z multicast. Odkljukajte in oddaljeni LAN izgine, razen če strežnik potisne določene oddaljene predpone, ki jih potrebuje vsak odjemalec.

Ta asimetrija odloča o vrstnem redu dela. Če mora oddaljena stran ostati popolnoma dosegljiva, potisnite oddaljene podmreže s strežnika in pustite lokalno privzeto pri miru. Če strežnika ne morete spremeniti, dodajte trajno pot do oddaljene predpone prek naslova, ki ga je dodelil tunel, in z route print preverite, da predpona kaže na vmesnik VPN, medtem ko privzeta še vedno kaže na fizični prehod.

Nato potrdite, da popravek preživi ponovno povezavo, ker netrajne poti umrejo z vmesnikom in skript, ki se zažene po vsaki povezavi, je zanje pošteno mesto. Preizkusite eno lokalno napravo in en oddaljeni vir v isti seji, prekinite povezavo, jo znova vzpostavite in preizkusite še enkrat. Če lokalna naprava še vedno ne uspe, medtem ko je pot videti pravilna, se vrnite k drugemu vprašanju: odjemalec filtrira, in odgovor je sprememba politike, ne druga konkurenčna pot.