VPN blokkeart lokaal LAN op Windows: rûte of kliïntbelied?
Lokale LAN-tagong op Windows brekt om twa ferskillende redenen: in ûntbrekkende rûte, of in gatewaybelied dat it subnet falle lit. Trije kontrôles sizze hokker.
In printer, in NAS of in ûntwikkelingsmasine op jo eigen buro hâldt op mei antwurdzjen op it stuit dat de wurk-VPN ferbynt. Soms makket in rûte-opdracht it yn sekonden klear; soms is deselde rûte korrekt en ferdwine de pakketten dochs, wat betsjut dat jo nei in oar probleem sjogge mei in soartgelikens symptoom. De beslissing komt del op trije fragen, en se yn 'e ferkearde folchoarder stelle is wêrom't minsken in hiele jûn besteegje oan it fuortheljen en wer tafoegjen fan rûtes.
Trije fragen foar elk kommando
Earst: is der in ynfier foar it lokale foarheaksel, en wiist dy nei de fysike adapter? Twadde: krijt de kliïnt by it ferbinen in tastimming of in wegering foar it lokale netwurk fan 'e gateway? Tredde: hawwe jo allinnich útgeande tagong ta de LAN nedich, of moat iets op it ynternet ek in tsjinst berikke dy't op jo masine draait?
De earste fragen skiedt in rûteflater fan in filterflater. De twadde fertelt oft in rûte-reparaasje uberhaupt wurkje mei. De tredde feroaret de reparaasje: in rûte reparearret útgeand ferkear, wylst in net berikbere ynkommende tsjinst meastentiids in probleem is mei it binen fan de lústerder en de weromwei, dat in rûte slimmer makket.
| 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 |
Fraach ien: rûte, filter of namme
Lês de tabel foardat jo der eat oan tafoegje. De ynterface-yndeks is fan belang, want elk rûte-kommando hjirûnder is dêroan ferankere:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricIn direkt ferbûn subnet hâldt normaal in on-link-rûte sels as de tunnel oan is, dus in ynfier kin bestean en it ferkear kin dochs mislearje. Dy kombinaasje is de hantekening fan in filter dat nei it rûtsjen rint, en dat is it gefal wêr't in twadde, mear spesifike rûte hielendal neat feroaret.
Test apart op adres en op namme. As ping 192.168.1.50 antwurdet en net view 192.168.1.50 net, wie de rûtetabel nea it probleem: de tunnel feroare de resolver en de lokale namme wurdt net mear oplost. In rûte dêrfoar tafoegje is fergriemd wurk.
Fraach twa: lit de gateway tagong ta it lokale LAN?
In kommersjele kliïnt ynstallearret mear as rûtes. Hy krijt by it ferbinen in belied, en dat belied kin in eksplisite tastimming foar it lokale netwurk befetsje. Yn Cisco IPsec-ynstallaasjes draacht it groepsbelied de split-tunneling-ynstelling en in aparte flagge foar tagong ta it lokale LAN; it kontrôlefakje yn 'e kliïnt is in fersyk dat de gateway wegerje kin. Yn AnyConnect regelet it profyl de split-ynslút- en útslútlisten en deselde tastimming. Op Windows RRAS binne de ekwivalinten de standertgateway-opsje yn it profyl plus de statyske rûtes dy't de server tawiist.
As de flagge út is, is it dokumintearre gedrach dat de kliïnt ferkear nei it direkt ferbûne subnet blokkeart, ek al bestiet der in jildige, mear spesifike rûte. Dat is ek wêrom't rûtes dy't de kliïnt net besit sekonden nei it tafoegjen ferdwine kinne: de kliïnt bout de steat wer op dy't him sein is te bouwen, en fjochtet net tsjin jo.
It kliïntlogboek registrearret de beslissing by it ferbinen, en it lêzen dêrfan is flugger as hokker eksperimint dan ek op 'e masine. As it logboek seit dat lokale tagong blokkearre is, stop dan: gjin ien kommandorigel-reparaasje oerlibbet dat, en de iennige oerbleaune paden binne in beliedswiziging, it berikken fan 'e helpboarne fia de tunnel, of it opsluten fan 'e kliïnt yn in firtuele masine en it host op it lokale netwurk litten.
Fraach trije: hokker rjochting hawwe jo nedich?
Utgeand ferkear nei in tichtby lizzend apparaat is in rûtefraach. Rjochtsje it LAN-foarheaksel op 'e lokale gateway mei in metryk dy't leech genôch is om de standertrûte fan 'e tunnel te ferslaan:
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 -pDe twadde foarm spikert ien apparaat fêst, dat is wat jo wolle as ien adres de hiele eask is. It netsh-ekwivalint registrearret deselde beslissing op ynterfacenamme ynstee fan yndeks:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentRûte-kommando's mislearje mei De parameter is ferkeard as it adres en it masker net oerienkomme, bygelyks in hostadres mei in /24-masker. Brûk it netwurkadres foar in subnetrûte en in hostmasker foar ien host.
Ynkommend is oars. In VNC- of SSH-server op deselde masine wurdt net berikber as antwurden op in ynkommende ferbining fia de VPN-gateway fuortgean en nea weromkomme. Kontrolearje wêr't de tsjinst nei lústeret foardat jo rûtes oanreitsje:
netstat -ano | findstr :5900In lústerder dy't oan ien bepaald adres bûn is, sil net antwurdzje op 'e oare ynterface. It binen oan alle ynterfaces is in bewuste beslissing, nommen tegearre mei in firewallregel dy't beheind is ta it netwurk dat jo fertrouwe. Pas dêrnei stellt de rûte-reparaasje de weromwei wer.
Pas de lytste wiziging ta dy't past
De oare gewoane beweging is it fuortheljen fan it fekje by “Standertgateway brûke op it fjirde netwurk” yn 'e avansearre eigenskippen fan IPv4. It hâldt ynternetferkear lokaal, mar docht twa dingen tagelyk: de VPN is net langer it standertpaad, en de kliïnt krijt gjin rûtes mear foar it fjirde netwurk, ynklusyf multicast. Helje it fekje fuort en de fjirde LAN ferdwynt, útsein as de server de spesifike fjirde foarheaksels triuwt dy't elke kliïnt nedich hat.
Dy asymmetry beslútet de folchoarder fan it wurk. As de fjirde kant folslein berikber bliuwe moat, triuw dan fjirde subnets fan 'e server en lit de lokale standert gewurde. As jo de server net feroarje kinne, foegje in permaninte rûte ta nei it fjirde foarheaksel fia it adres dat de tunnel tawiisde, en kontrolearje mei route print dat it foarheaksel nei de VPN-ynterface wiist wylst de standert noch nei de fysike gateway wiist.
Befêstigje dan dat de reparaasje in werferbining oerlibbet, want net-permaninte rûtes stjerre mei de adapter en in skript dat nei elke ferbining rint is it earlike plak dêrfoar. Test ien lokaal apparaat en ien fjirde helpboarne yn deselde sesje, ferbrek, ferbyn wer en test opnij. As it lokale apparaat noch mislearret wylst de rûte goed liket, gean werom nei fraach twa: de kliïnt filteret, en it antwurd is in beliedswiziging ynstee fan in twadde konkurrearjende rûte.