VPN blokeerib Windowsis kohaliku LAN-i: marsruut või kliendipoliitika?

Sinu enda laual olev printer, NAS või arendusmasin lakkavad vastamast hetkel, mil töö-VPN ühendub. Mõnikord parandab marsruudikäsk selle sekunditega; mõnikord on sama marsruut õige ja paketid kaovad ikkagi, mis tähendab, et vaatad teist probleemi sarnase sümptomiga. Otsus taandub kolmele küsimusele ja nende vale järjekord on põhjus, miks inimesed veedavad terve õhtu marsruute kustutades ja uuesti lisades.

Kolm küsimust enne ükskõik millist käsku

Esiteks: kas kohaliku prefiksi jaoks on kirje ja kas see osutab füüsilisele adapterile? Teiseks: kas klient saab ühendamisel lüüsilt kohaliku võrgu loa või keelu? Kolmandaks: kas sul on vaja ainult väljuvat juurdepääsu LAN-ile või peab ka miski internetis jõudma sinu masinal töötava teenuseni?

Esimene küsimus eraldab marsruutimistõrke filtreerimistõrkest. Teine ütleb, kas marsruudiparandus tohikski üldse toimida. Kolmas muudab parandust: marsruut parandab väljuva liikluse, samas kui kättesaamatu sissetulev teenus on tavaliselt kuulaja sidumise ja tagasitee probleem, mille marsruut hullemaks teeb.

Küsimus üks: marsruut, filter või nimi

Loe tabelit enne, kui midagi sinna lisad. Liidese indeks on oluline, sest iga allolev marsruudikäsk on selle külge ankurdunud:

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

Otse ühendatud alamvõrk säilitab tavaliselt lingil marsruudi ka tunneliajal, nii et kirje võib olemas olla ja liiklus ikkagi ebaõnnestuda. See kombinatsioon on pärast marsruutimist töötava filtri allkiri ja see on juhtum, kus teine, täpsem marsruut ei muuda mitte midagi.

Testi eraldi aadressi ja nime järgi. Kui ping 192.168.1.50 vastab ja net view 192.168.1.50 ei vasta, ei olnud marsruutimistabel kunagi probleem: tunnel muutis resolverit ja kohalik nimi ei lahendu enam. Selle jaoks marsruudi lisamine on raisatud töö.

Küsimus kaks: kas lüüs lubab juurdepääsu kohalikule LAN-ile?

Kommertsklient paigaldab rohkem kui marsruute. See saab ühendamisel poliitika ja see poliitika võib sisaldada selgesõnalist kohaliku võrgu luba. Cisco IPsec-i juurutustes kannab grupipoliitika split-tunnelingi seadet ja eraldi kohaliku LAN-i juurdepääsu lippu; kliendi märkeruut on taotlus, mille lüüs võib tagasi lükata. AnyConnectis juhib profiil split-i kaasamise ja väljajätmise nimekirju ning sama luba. Windows RRAS-is on ekvivalentideks profiili vaikelüüsi valik pluss serveri määratud staatilised marsruudid.

Kui lipp on väljas, on dokumenteeritud käitumine see, et klient blokeerib liikluse otse ühendatud alamvõrku, kuigi kehtiv, täpsem marsruut on olemas. Seetõttu võivad ka marsruudid, mis kliendile ei kuulu, kaduda sekundeid pärast nende lisamist: klient ehitab uuesti oleku, mille ehitamist talle öeldi, mitte ei võitle sinuga.

Kliendilogii salvestab otsuse ühendamisel ja selle lugemine on kiirem kui ükskõik milline katse masinas. Kui logi ütleb, et kohalik juurdepääs on blokeeritud, lõpeta: ükski käsurea parandus ei jää sellest ellu ja alles jäävad ainult poliitika muutmine, ressursile tunneli kaudu jõudmine või kliendi sulgemine virtuaalmasinasse ja hosti jätmine kohalikku võrku.

Küsimus kolm: millist suunda sa vajad?

Väljuv liiklus lähedase seadmeni on marsruutimisküsimus. Suuna LAN-i prefiks kohalikule lüüsile piisavalt madala metrikaga, et võita tunneli vaikemarsruut:

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

Teine vorm kinnitab ühe seadme, mida sa tahad, kui kogu nõue on üks aadress. netsh-i ekvivalent salvestab sama otsuse liidese nime, mitte indeksi järgi:

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

Marsruudikäsud ebaõnnestuvad Parameeter on vale, kui aadress ja mask ei ühti, näiteks hosti aadress /24-maskiga. Kasuta alamvõrgu marsruudi jaoks võrguaadressi ja ühe hosti jaoks hostimaski.

Sissetulev on teistsugune. Sama masina VNC- või SSH-server muutub kättesaamatuks, kui sissetuleva ühenduse vastused lahkuvad VPN-i lüüsi kaudu ega tule kunagi tagasi. Enne marsruutide puudutamist kontrolli, mida teenus kuulab:

netstat -ano | findstr :5900

Ühele konkreetsele aadressile seotud kuulaja ei vasta teisel liidesel. Selle sidumine kõigi liidestega on teadlik otsus, tehtud koos tulemüürireegliga, mis on piiratud võrguga, mida usaldad. Alles pärast seda taastab marsruudiparandus tagasitee.

Rakenda väikseim sobiv muudatus

Teine tavaline samm on tühistada „Kasuta vaikelüüsi kaugvõrgus“ IPv4-i täiustatud atribuutides. See hoiab internetiliikluse kohalikuna, kuid teeb korraga kaks asja: VPN lakkab olemast vaiketeekond ja klient lakkab saamast kaugvõrgu marsruute, sealhulgas multicast. Tühista see ja kaug-LAN kaob, kui server ei lükka konkreetseid kaugprefikseid, mida iga klient vajab.

See asümmeetria otsustab töö järjekorra. Kui kaugpool peab jääma täielikult kättesaadavaks, lükka kaug-alamvõrgud serverist ja jäta kohalik vaikeväärtus rahule. Kui sa ei saa serverit muuta, lisa püsiv marsruut kaugprefiksile tunneli määratud aadressi kaudu ja kontrolli route print abil, et prefiks osutab VPN-i liidesele, samal ajal kui vaikeväärtus osutab endiselt füüsilisele lüüsile.

Seejärel kinnita, et parandus peab vastu taasühendusele, sest mittepüsivad marsruudid surevad koos adapteriga ja skript, mis jookseb pärast igat ühendust, on nende jaoks aus koht. Testi samas seansis üht kohalikku seadet ja üht kaugressurssi, katkesta ühendus, ühenda uuesti ja testi jälle. Kui kohalik seade ikka ebaõnnestub, samal ajal kui marsruut tundub õige, mine tagasi teise küsimuse juurde: klient filtreerib ja vastus on poliitika muutmine, mitte teine võistlev marsruut.