Hinaharang ng VPN ang lokal na LAN sa Windows: ruta o patakaran ng kliyente?
Nasira ang access sa lokal na LAN sa Windows dahil sa dalawang magkaibang dahilan: nawawalang ruta, o patakaran ng gateway na nagtatapon ng subnet. Tatlong pagsusuri ang nagsasabi kung alin.
Ang printer, NAS o development machine sa sarili mong mesa ay humihinto sa pagtugon sa sandaling kumonekta ang VPN ng trabaho. Minsan isang utos ng ruta lang ang nag-aayos nito sa ilang segundo; minsan tama ang parehong ruta at nawawala pa rin ang mga packet, ibig sabihin ay ibang problema ito na may katulad na sintomas. Bumababa ang desisyon sa tatlong tanong, at ang pagtatanong sa maling pagkakasunod-sunod ang dahilan kung bakit inuubos ng mga tao ang isang gabi sa pagbubura at pagdaragdag muli ng mga ruta.
Tatlong tanong bago ang anumang utos
Una: mayroon bang entry para sa lokal na prefix, at itinuturo ba nito ang pisikal na adapter? Ikalawa: tumatanggap ba ang kliyente ng pahintulot o pagtanggi sa lokal na network mula sa gateway kapag kumokonekta? Ikatlo: kailangan mo lang ba ng palabas na access sa LAN, o may isang bagay sa internet na kailangan ding makarating sa isang serbisyong tumatakbo sa iyong makina?
Inihihiwalay ng unang tanong ang sira sa rutahan mula sa sira sa pagsasala. Sinasabi ng ikalawa kung pinapayagan kahit paano ang pagwawasto ng ruta. Binabago ng ikatlo ang pag-aayos: ang ruta ay nag-aayos ng palabas na trapiko, habang ang hindi maabot na papasok na serbisyo ay karaniwang problema sa pagbigkis ng tagapakinig at sa daang pabalik na pinapalala ng ruta.
| 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 |
Tanong isa: ruta, filter o pangalan
Basahin ang talahanayan bago magdagdag ng kahit ano. Mahalaga ang index ng interface, dahil ang bawat utos ng ruta sa ibaba ay nakaangkla rito:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricAng direktang konektadong subnet ay karaniwang nagpapanatili ng on-link na ruta kahit nakataas ang tunnel, kaya may entry at maaari pa ring mabigo ang trapiko. Ang kombinasyong iyon ay ang lagda ng isang filter na tumatakbo pagkatapos ng rutahan, at ito ang kaso kung saan ang pangalawa at mas tiyak na ruta ay walang binabago.
Subukan nang hiwalay ayon sa address at ayon sa pangalan. Kung tumutugon ang ping 192.168.1.50 at hindi ang net view 192.168.1.50, hindi kailanman naging problema ang talahanayan ng rutahan: binago ng tunnel ang resolver at hindi na nalulutas ang lokal na pangalan. Ang pagdaragdag ng ruta para diyan ay sayang na trabaho.
Tanong dalawa: pinapayagan ba ng gateway ang access sa lokal na LAN?
Nag-i-install ang isang komersyal na kliyente ng higit pa sa mga ruta. Tumatanggap ito ng patakaran kapag kumokonekta, at ang patakarang iyon ay maaaring may tahasang pahintulot sa lokal na network. Sa mga deployment ng Cisco IPsec, dinadala ng patakaran ng grupo ang setting ng split-tunneling at isang hiwalay na bandila para sa access sa lokal na LAN; ang checkbox sa kliyente ay isang kahilingan na maaaring tanggihan ng gateway. Sa AnyConnect, kinokontrol ng profile ang mga listahan ng pagsasama at pagbubukod ng split at ang parehong pahintulot. Sa Windows RRAS, ang mga katumbas ay ang opsyon ng default na gateway sa profile at ang mga static na ruta na ibinibigay ng server.
Kapag patay ang bandila, ang nakadokumentong gawi ay hinaharang ng kliyente ang trapiko papunta sa direktang konektadong subnet kahit may balido at mas tiyak na ruta. Ito rin ang dahilan kung bakit ang mga rutang hindi pag-aari ng kliyente ay maaaring mawala ilang segundo pagkatapos mong idagdag ang mga ito: muling itinatayo ng kliyente ang estadong inutusang itayo, hindi ito nakikipaglaban sa iyo.
Itinatala ng log ng kliyente ang desisyon kapag kumokonekta, at ang pagbasa nito ay mas mabilis kaysa sa anumang eksperimento sa makina. Kung sinasabi ng log na naka-block ang lokal na access, huminto: walang pagwawasto sa command line ang makakalampas doon, at ang natitirang mga daan ay pagbabago ng patakaran, pag-abot sa resource sa pamamagitan ng tunnel, o pagkulong sa kliyente sa isang virtual machine at pag-iwan sa host sa lokal na network.
Tanong tatlo: anong direksyon ang kailangan mo?
Ang palabas na trapiko patungo sa kalapit na device ay tanong ng rutahan. Itutok ang prefix ng LAN sa lokal na gateway na may sukatan na sapat na mababa para talunin ang default na ruta ng tunnel:
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 -pAng ikalawang anyo ay nagpupirmi ng isang device, at iyon ang gusto mo kapag isang address lang ang buong pangangailangan. Itinatala ng katumbas ng netsh ang parehong desisyon sa pangalan ng interface kaysa sa index:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentNabibigo ang mga utos ng ruta sa Mali ang parameter kapag hindi tugma ang address at mask, halimbawa isang address ng host na may mask na /24. Gamitin ang network address para sa ruta ng subnet at host mask para sa isang host.
Iba ang papasok. Ang VNC o SSH server sa parehong makina ay nagiging hindi maabot kapag lumalabas ang mga sagot sa papasok na koneksyon sa gateway ng VPN at hindi na bumabalik. Suriin kung ano ang pinakikinggan ng serbisyo bago hawakan ang mga ruta:
netstat -ano | findstr :5900Ang tagapakinig na nakatali sa isang partikular na address ay hindi tutugon sa kabilang interface. Ang pagtali nito sa lahat ng interface ay sinadyang desisyon, ginawa kasama ng panuntunan ng firewall na limitado sa network na pinagkakatiwalaan mo. Pagkatapos lang nito naibabalik ng pag-aayos ng ruta ang daang pabalik.
Ilapat ang pinakamaliit na pagbabagong akma
Ang isa pang karaniwang hakbang ay ang pag-alis ng tsek sa “Gamitin ang default na gateway sa malayong network” sa mga advanced na katangian ng IPv4. Pinapanatili nitong lokal ang trapiko sa internet, ngunit gumagawa ng dalawang bagay nang sabay: hindi na ang VPN ang default na daan, at hindi na tumatanggap ang kliyente ng mga ruta para sa malayong network, kasama ang multicast. Alisin ito at mawawala ang malayong LAN maliban kung itinutulak ng server ang mga partikular na malayong prefix na kailangan ng bawat kliyente.
Ang asimetriyang iyon ang nagtatakda ng pagkakasunod-sunod ng trabaho. Kung dapat manatiling ganap na maabot ang malayong panig, itulak ang malalayong subnet mula sa server at iwanan ang lokal na default. Kung hindi mo mababago ang server, magdagdag ng permanenteng ruta sa malayong prefix sa address na ibinigay ng tunnel, at suriin gamit ang route print na ang prefix ay tumuturo sa interface ng VPN habang ang default ay tumuturo pa rin sa pisikal na gateway.
Pagkatapos, tiyakin na ang pag-aayos ay nakakaligtas sa muling pagkonekta, dahil ang mga rutang hindi permanente ay namamatay kasama ng adapter at ang isang script na tumatakbo pagkatapos ng bawat koneksyon ang tapat na lugar para sa kanila. Subukan ang isang lokal na device at isang malayong resource sa parehong sesyon, idiskonekta, kumonekta muli at subukan muli. Kung nabibigo pa rin ang lokal na device habang mukhang tama ang ruta, bumalik sa tanong dalawa: nagsasala ang kliyente, at ang sagot ay pagbabago ng patakaran at hindi pangalawang karibal na ruta.