Hindi maabot ang lokal na network habang nakakonekta ang VPN? Apat na pagsusuri

Bumangon ang tunnel, lumitaw ang intranet, at huminto ang printer sa pagsagot. Walang nasira sa LAN; binago ng client ang landas na ginagamit nito para sa mga address na hindi na nito itinuturing na lokal. Sundin ang apat na pagsusuri sa ibaba nang sunod-sunod at huminto kapag may isang nagpakita ng konkretong pagkakaiba, dahil ang parehong sintomas ay may apat na karaniwang sanhi at isa lamang sa mga ito ang naaayos sa pamamagitan ng pagbabago sa VPN.

Una, tingnan ang talahanayan ng ruta na inilagay ng client

Buksan ang talahanayan ng ruta ng client habang nakakonekta ang VPN. Sa Linux gamitin ang ip route, sa Windows ang route print o Get-NetRoute, at sa macOS ang netstat -rn. Hinahanap mo ang default na ruta sa tunnel at kung ano ang nangyari sa pisikal na default.

Ang full-tunnel client ay madalas nagdadagdag ng dalawang kalahating-default na ruta, 0.0.0.0/1 at 128.0.0.0/1, sa halip na palitan ang 0.0.0.0/0. Nananatiling nakikita ang orihinal na default ngunit natatalo sa bawat paghahanap, kaya maaaring magmukhang buo ang talahanayan habang lumilipat ang lahat ng trapiko sa labas ng subnet. Kung may opsyon ang VPN client para sa split tunnel at pinapayagan ng patakaran, iyon ang pinakamalinis na pag-aayos.

Kung kailangang manatiling default ang tunnel, i-pin ang lokal na subnet sa halip. Sa Linux pinapangalanan ng ruta ang pisikal na interface at gateway; sa Windows magdagdag ng -p upang maging permanente at basahin ang numero ng interface mula sa route print sa halip na hulaan ito:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Ang naka-pin na ruta ay tumatagal lamang hangga't hindi nagbabago ang address na pinapangalanan nito. Ang laptop na nakakakuha ng bagong numero para sa Wi-Fi adapter sa bawat koneksyon ay muling lalabag sa tuntunin, kaya suriin ang address ng interface bago magpasya na nabigo ang pag-aayos.

Pangalawa, tiyakin na ang address ay lokal na noong una

Kung ang destinasyon ay nasa loob ng konektadong subnet, hindi kailanman nalalapat ang default ng tunnel at hindi ang VPN ang sanhi. Ang printer sa 192.168.1.40 sa client na may 192.168.1.0/24 ay gumagamit ng konektadong ruta; kung nabigo ang address na iyon, tingnan ang device, switch o firewall ng client at hindi ang VPN.

Ang kaso na nakakalito ay isang pampublikong address para sa lokal na server. Mula sa loob ng LAN, ang maabot ang WAN address ng router at makabalik ay nangangailangan ng hairpin NAT, at maraming router ay hindi ito ipinapatupad para sa port forwarding. Subukan ang pribadong address katabi ng pampubliko. Kung gumagana ang pribado at hindi ang pampubliko, inilantad lamang ng VPN ang isang limitasyon ng NAT na dati nang naroon.

Ang hostname ay nagpapalala nito. Kung ang lokal na pangalan ay niresolba na ngayon sa pampublikong address, patuloy na susubukan ng client ang landas na hindi makakabalik. Gamitin ang pribadong address para sa pagsubok, pagkatapos ay ayusin ang pangalan sa halip na magdagdag ng isa pang port forwarding.

Pangatlo, tingnan kung sino ang sumasagot sa mga pangalan ngayon

Ang corporate resolver ay alam ang intranet at karaniwang walang alam tungkol sa hostname ng NAS, pangalan ng Bonjour ng printer o lokal na alias ng router. Kapag itinulak ng VPN ang mga DNS server nito, humihinto ang pagresolba ng mga pangalang iyon kahit naabot pa rin ang mga address nito. Itanong nang direkta ang pangalan at ihambing ang sagot sa address na alam mong taglay ng device.

Sa Linux, ipinapakita ng resolvectl query nas.local kung aling resolver ang sumagot. Sa Windows, pinangalanan ng nslookup nas.local ang server, at ipinapakita ng ipconfig /all ang pagkakasunod-sunod ng mga resolver. Kung ang lokal na suffix ay pinangangasiwaan na ngayon ng corporate resolver, ibalik ang suffix na iyon sa lokal na resolver o gamitin ang IP address para sa device.

Ang pagtuklas ay hiwalay na antas. Ang mDNS at broadcast ay hindi tumatawid sa rutadong tunnel, kaya maaaring maabot ang device sa pamamagitan ng address habang nananatiling hindi nakikita ang pangalan. Niresolba ito ng reflector o lokal na entry ng DNS; hindi ng ruta.

Pang-apat, suriin kung ang kabilang makina ay nasa VPN din

Kapag ang makinang gusto mong maabot ay nagpapatakbo rin ng VPN client, maaaring dumating ang session mo habang lumalabas ang sagot nito sa kabilang tunnel. Nagbubunga ito ng koneksyong nagtatayo at pagkatapos ay natigil, o pagtatangkang RDP at SSH na nag-time out nang walang error sa panig mo. Suriin ang talahanayan ng ruta at default na landas ng kabilang host bago sisihin ang client mo.

Suriin din ang address na pinakikinggan ng serbisyo. Ang listener na nakatali lamang sa address ng tunnel ay tumatanggap ng koneksyon mula sa VPN at tinatanggihan ang mula sa LAN, kahit perpekto ang routing. Iyon ay configuration ng serbisyo, hindi landas ng network, at karaniwan ito sa mga management interface na ikinandado sa address ng VPN.

Panatilihin ang landas ng pamamahala na hindi umaasa sa tunnel: isang static na ruta na pinapangalanan ang iyong pinagmulang network, isa pang interface na nakakabit sa LAN, o isang console na ganap na lumalampas sa tunnel. Ang pagdidisenyo ng landas na iyon pagkatapos bumagsak ang session ay mas mahirap kaysa idagdag ito bago ang susunod na koneksyon.

Ilapat ang pag-aayos na tumutugma sa pagsusuring nabigo

Kung nagpakita ang talahanayan ng ruta ng kalahating-default na pagkuha, piliin ang split tunnel kapag pinapayagan ng patakaran at ang naka-pin na lokal na ruta kapag hindi. Kung ang address ay naging pampubliko, ilipat ang pagsubok at pangalan sa pribadong address. Kung nagpalit ng kamay ang resolver, limitahan sa lokal na suffix o gamitin ang address. Kung ang kabilang host ay nasa tunnel, ayusin ang landas ng pagbabalik nito o ang pagkakatali ng listener.

Baguhin ang isang bagay, pagkatapos ay ulitin ang parehong pagsusuri. Ang rutang idinagdag para sa maling subnet, suffix ng resolver na may typo at naka-pin na ruta sa interface na nakakakuha ng bagong numero ay mukhang orihinal na sira. Ang pag-uulit ang naghihiwalay ng pag-aayos sa pagkakataon.

Isulat ang ruta, address at resolver na gumana habang nakakonekta ang VPN. Babaguhin ng susunod na muling pagkonekta ang kahit isa sa mga ito, at ginagawa ng tala ang susunod na pagkaantala na isang maikling paghahambing sa halip na bagong imbestigasyon.