VPN blokkeer plaaslike LAN op Windows: roete of kliëntbeleid?
Plaaslike LAN-toegang op Windows breek om twee verskillende redes: 'n ontbrekende roete, of 'n poortbeleid wat die subnet laat val. Drie kontroles sê watter.
'n Drukker, 'n NAS of 'n ontwikkelingsmasjien op jou eie lessenaar hou op antwoord die oomblik wanneer die werk-VPN koppel. Soms herstel 'n roeteopdrag dit binne sekondes; soms is dieselfde roete korrek en verdwyn die pakkette steeds, wat beteken jy kyk na 'n ander probleem met 'n soortgelyke simptoom. Die besluit kom neer op drie vrae, en om hulle in die verkeerde volgorde te vra, is hoekom mense 'n hele aand spandeer om roetes te verwyder en weer by te voeg.
Drie vrae voor enige opdrag
Eerste: is daar 'n inskrywing vir die plaaslike voorvoegsel, en wys dit na die fisiese adapter? Tweede: ontvang die kliënt tydens koppeling 'n toestemming of weiering vir die plaaslike netwerk van die poort? Derde: het jy net uitgaande toegang na die LAN nodig, of moet iets op die internet ook 'n diens bereik wat op jou masjien loop?
Die eerste vraag skei 'n roetefout van 'n filterfout. Die tweede sê vir jou of 'n roeteherstel hoegenaamd mag werk. Die derde verander die herstel: 'n roete herstel uitgaande verkeer, terwyl 'n onbereikbare inkomende diens gewoonlik 'n luisteraarbinding- en terugpadprobleem is wat 'n roete vererger.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
Vraag een: roete, filter of naam
Lees die tabel voordat jy iets daaraan byvoeg. Die koppelvlakindeks maak saak, want elke roeteopdrag hieronder is daaraan geanker:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric'n Direk gekoppelde subnet behou gewoonlik 'n skakelroete selfs terwyl die tonnel aktief is, so 'n inskrywing kan bestaan en verkeer kan steeds misluk. Daardie kombinasie is die kenmerk van 'n filter wat ná die roetering werk, en dit is die geval waar 'n tweede, meer spesifieke roete glad niks verander nie.
Toets apart op adres en op naam. As ping 192.168.1.50 antwoord en net view 192.168.1.50 nie, was die roetertabel nooit die probleem nie: die tonnel het die oplosser verander en die plaaslike naam los nie meer op nie. Om daarvoor 'n roete by te voeg, is vermorsde werk.
Vraag twee: laat die poort plaaslike LAN-toegang toe?
'n Kommersiële kliënt installeer meer as roetes. Dit kry 'n beleid tydens koppeling, en daardie beleid kan 'n eksplisiete plaaslike-netwerktoestemming insluit. In Cisco IPsec-ontplooiings dra die groepsbeleid die split-tonnelinstelling en 'n aparte plaaslike LAN-toegangsvlag; die merkie in die kliënt is 'n versoek wat die poort mag weier. In AnyConnect beheer die profiel die split-insluit- en -uitsluitlyste en dieselfde toestemming. Op Windows RRAS is die ekwivalente die verstekpoortopsie op die profiel plus die statiese roetes wat die bediener toeken.
Wanneer die vlag af is, is die gedokumenteerde gedrag dat die kliënt verkeer na die direk gekoppelde subnet blokkeer selfs al bestaan daar 'n geldige, meer spesifieke roete. Dit is ook hoekom roetes wat die kliënt nie besit nie, sekondes nadat jy hulle bygevoeg het kan verdwyn: die kliënt bou die toestand wat hy opdrag gekry het om te bou, weer op, en veg nie teen jou nie.
Die kliëntlog teken die besluit tydens koppeling aan, en om dit te lees is vinniger as enige eksperiment op die masjien. As die log sê plaaslike toegang is geblokkeer, stop: geen opdragreëlherstel oorleef dit nie, en die enigste paaie wat oorbly, is 'n beleidsverandering, die hulpbron deur die tonnel bereik, of die kliënt in 'n virtuele masjien toesluit en die gasheer op die plaaslike netwerk laat.
Vraag drie: watter rigting het jy nodig?
Uitgaande verkeer na 'n nabygeleë toestel is 'n roetevraag. Wys die LAN-voorvoegsel na die plaaslike poort met 'n metriek wat laag genoeg is om die tonnel se verstekroete te klop:
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 -pDie tweede vorm pen 'n enkele toestel vas, wat is wat jy wil hê wanneer een adres die hele vereiste is. Die netsh-ekwivalent teken dieselfde besluit per koppelvlaknaam eerder as indeks aan:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentRoeteopdragte misluk met Die parameter is verkeerd wanneer die adres en masker nie ooreenstem nie, byvoorbeeld 'n gasheeradres met 'n /24-masker. Gebruik die netwerkadres vir 'n subnetroete en 'n gasheermasker vir 'n enkele gasheer.
Inkomend is anders. 'n VNC- of SSH-bediener op dieselfde masjien word onbereikbaar wanneer antwoorde op 'n inkomende verbinding deur die VPN-poort verlaat en nooit terugkeer nie. Kyk waarop die diens luister voordat jy aan roetes raak:
netstat -ano | findstr :5900'n Luisteraar wat aan een spesifieke adres gebind is, sal nie op die ander koppelvlak antwoord nie. Om dit aan alle koppelvlakke te bind, is 'n doelbewuste besluit, geneem saam met 'n firewallreël wat op die netwerk wat jy vertrou, gemik is. Eers daarna herstel die roeteherstel die terugpad.
Pas die kleinste verandering toe wat pas
Die ander algemene stap is om “Gebruik verstekpoort op afgeleë netwerk” op die IPv4-gevorderde eienskappe af te merk. Dit hou internetverkeer plaaslik, maar dit doen twee dinge gelyktydig: die VPN hou op om die verstekpad te wees, en die kliënt hou op om roetes vir die afgeleë netwerk te ontvang, insluitend multicast. Merk dit af en die afgeleë LAN verdwyn tensy die bediener die spesifieke afgeleë voorvoegsels stoot wat elke kliënt nodig het.
Daardie asimmetrie bepaal die volgorde van werk. As die afgeleë kant ten volle bereikbaar moet bly, stoot afgeleë subnette vanaf die bediener en laat die plaaslike verstek alleen. As jy nie die bediener kan verander nie, voeg 'n blywende roete na die afgeleë voorvoegsel by deur die adres wat die tonnel toegeken het, en kyk met route print of die voorvoegsel na die VPN-koppelvlak wys terwyl die verstek steeds na die fisiese poort wys.
Bevestig dan dat die herstel 'n herkoppeling oorleef, want nie-blywende roetes sterf saam met die adapter en 'n script wat ná elke koppeling loop, is die eerlike plek daarvoor. Toets een plaaslike toestel en een afgeleë hulpbron in dieselfde sessie, ontkoppel, koppel weer en toets weer. As die plaaslike toestel steeds misluk terwyl die roete reg lyk, gaan terug na vraag twee: die kliënt filter, en die antwoord is 'n beleidsverandering eerder as 'n tweede mededingende roete.