Patakbuhin ang VPN sa host o sa loob ng VM? Gabay sa pagpapasya

Ang pagtatayo ng tunnel sa loob ng bisita at ang pagtatayo nito sa host ay parehong nagbabago ng address na iniuulat ng browser, at doon nagtatapos ang pagkakatulad. Ang tunnel na pag-aari ng bisita ay nagtatago ng mga susi nito, ng default nitong ruta at ng resolver nito sa loob ng kernel ng bisita, habang ang host ay nagpapasa ng naka-encrypt na mga packet sa isang malayong address. Ang tunnel na pag-aari ng host ay ang salamin nito: hawak ng kliyente ng host ang session at inilalapat ang mga ruta at patakaran, at ang bisita ay humihiram ng lumalabas. Pumili ka ng maling may-ari at bawat susunod na sintomas ay maghahatid sa iyo sa maling makina. Dalawang utos ang nagtatapos ng tanong sa halos isang minuto, at ang natitirang bahagi ng gabay na ito ay kung ano ang gagawin sa sagot.

Magpasiya sa may-ari bago mo hawakan ang kliyente

Ang tuntunin ay tungkol sa kung saan ginagawa ang ciphertext, hindi tungkol sa kung aling makina ang nagpapakita ng icon ng VPN. Kung ang bisita ang gumagawa nito, kailangan ng bisita ng gumaganang ruta patungo sa VPN server at wala nang iba pa mula sa host. Kung ang host ang gumagawa nito, kailangan ng bisita na ang landas sa host ay makalampas sa anumang patakarang ipinapataw ng kliyente ng host sa lokal na trapiko.

Tatlong tanong ang kadalasang pumipili ng pagkakalagay para sa iyo. Kailangan bang lumampas ang trapiko ng bisita sa isang corporate client sa host? Kung gayon ang tunnel ay nasa loob ng bisita. Kailangan ba ng ilang bisita ng isang kredensyal at isang labasan na address? Kung gayon ito ay nasa host, na may pasadyang pagsasaayos ng pagpapasa. Dapat bang manatiling ganap na labas ng VPN ng host ang trapiko ng bisita? Kung gayon ang tunnel sa bisita ang tanging kaayusan na nagbibigay niyon sa pamamagitan ng mismong pagbuo.

Isulat ang sagot sa isang linya sa tabi ng pangalan ng VM: guest-owned o host-owned. Sa laboratoryo na may anim na makina, ang talaang iyon ay nagtitipid ng mas maraming oras kaysa sa alinmang hakbang sa ibaba, dahil pinipigilan ka nitong siyasatin ang tunnel na kailanman ay wala sa makinang pinasukan mo.

Ang WSL1 at WSL2 ay magkasalungat na kaso

Ang WSL1 ay hindi isang virtual machine, kaya ang tanong ng pagkakalagay ay kadalasang sumisingaw. Ang mga binary ng Linux nito ay tumatakbo laban sa network stack ng Windows sa pamamagitan ng isang layer ng pagsasalin, at ang kliyente ng VPN sa Linux ay walang malayang interface na isasaayos. Ang gumagana ay isang tunnel sa panig ng Windows, na ginagamit ng distribusyon ang resulta nang walang pag-aari ng anuman.

Ang WSL2 ay kabaligtaran. Nagpapatakbo ito ng tunay na kernel sa isang magaan na utility VM sa likod ng virtual switch ng Hyper-V, at ang address space nito ay isinasalin sa NAT sa pamamagitan ng adapter sa panig ng host. Kaya ang kliyente ng Linux sa loob ng distribusyon ay kumikilos na parang nasa pisikal na Linux box: gumagawa ito ng tun0 o wg0, naglalagay ng sariling mga ruta, at gumagana. Ang pagkabigo ay naninirahan sa panig ng host. Kapag kumonekta ang kliyente ng VPN sa Windows na may patakarang humaharang sa trapiko sa mga lokal na network, itinuturing nitong hindi mapagkakatiwalaang lokal na network ang subnet ng WSL2 at pinuputol ang landas ng NAT. Pagkatapos ay nawawala sa distribusyon ang DNS at ang labas na pag-access habang ang sarili nitong tunnel ay malusog pa: nag-uulat ang wg show ng handshake, mukhang tama ang ip route, at nag-hang ang curl.

Kung aling lunas ang magagamit mo ay nakasalalay sa build ng Windows. Ang mas matanda ay isang pagbubukod sa kliyente ng host para sa subnet ng WSL, na idinaragdag sa ilalim ng mga setting ng lokal na network o hati na tunnel ng kliyente. Ang mas bago, sa mga build ng Windows 11 na sumusuporta nito, ay ang mirrored networking: ilagay ang networkingMode=mirrored sa seksyong [wsl2] ng %UserProfile%\.wslconfig, patakbuhin ang wsl --shutdown, at ibabahagi ng distribusyon ang mga interface ng host sa halip na pribadong subnet ng NAT. Binabago rin ng mirrored mode ang pag-uugali ng localhost at ng mga papasok na port, kaya ituring itong paglilipat at hindi switch.

NAT, tulay at ano ang nakikita ng host

Sa ilalim ng NAT, ang mga packet ng tunnel ng bisita ay itinutuon sa pampublikong address ng VPN server at lumalabas sa adapter ng host bilang naka-encrypt na UDP o TCP. Isang daloy at ang bilang ng byte nito ang nakikita ng host, wala tungkol sa mga destinasyon sa loob. Sa ilalim ng nakatulay na adapter, may sariling pagkakakilanlan sa layer 2 ang bisita sa pisikal na LAN, kumukuha ng sariling DHCP lease, at mukhang pangalawang aparato sa anumang patakarang nakabatay sa MAC. Wala sa dalawang mode ang nagpapahintulot sa host na basahin ang payload ng tunnel; ang nakatulay na bisita ay mas nakikita lamang ng network sa paligid nito.

May sahig din ang paghihiwalay. Hindi makapagtatago ang bisita mula sa makinang nagmamay-ari ng memorya nito, at sinumang kumokontrol sa host ay makababasa ng mga susi mula sa RAM ng bisita. Ang ibinibigay ng tunnel sa bisita ay hangganan ng routing at hangganan laban sa malware, hindi proteksyon mula sa taong may hawak ng laptop. Sulit na buksan ang mga dokumentadong mode ng adapter habang pumipili ka, dahil binabago ng mode ang nakikita ng host at ang nakikita ng LAN.

Gabay: ilagay, isaayos, patunayan

Patakbuhin ang apat na pagsusuring ito nang sunud-sunod sa isang sariwang shell ng bisita, at huminto sa una na hindi tumutugma sa may-aring isinulat mo.

1. ip route get 1.1.1.1 na nagbabalik ng tun0 o wg0 ay nangangahulugang pag-aari ng bisita, at eth0 na may pribadong susunod na hakbang ay nangangahulugang pag-aari ng host.
2. resolvectl query example.com, o basahin ang /etc/resolv.conf kung saan walang serbisyo ng resolver na pinapatakbo ang bisita. Ang tunnel na nagdadala ng trapiko ngunit hindi DNS ay ang pinakakaraniwang kalahating-naayos na kalagayan.
3. Ihambing ang mga labasan: curl -4 -s https://ifconfig.me sa bisita laban sa curl.exe -4 -s https://ifconfig.me sa host. Iba't ibang address ang ibig sabihin ay pag-aari ng bisita ang tunnel, at ang host na nasa VPN na may bisitang nagpapakita ng ISP ng bahay ang kaso kung saan walang namana.
4. Ulitin ang dalawa gamit ang -6. Ang tunnel na v4 lamang ay naglalabas ng v6 maliban kung haharangin o iruruta ito ng kliyente, at maraming kliyente ang nag-iiwan ng v6 sa pisikal na interface bilang default.

Sa disenyong gateway sa host, kung saan maraming bisita ang nagbabahagi ng isang tunnel, kailangang magpasa at magsalin ng host. Sa host na Linux, tatlong piraso iyon, at tahimik na bumabalik ang bisita sa karaniwang ruta nito kapag may nawawalang isa sa kanila:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Sa panig ng WireGuard, dapat isama ng AllowedIPs ng partner ng host ang subnet ng mga bisita, halimbawa 192.168.122.0/24, kung hindi ay hindi kailanman darating ang mga pabalik na packet at ang setup ay magmumukhang problema sa firewall. Naabot ng host na Windows ang parehong resulta sa Internet Connection Sharing o panuntunan ng NAT sa switch ng Hyper-V, at kailangan din ng parehong pagsusuri ng pabalik na landas.

Kapag bukas pa ang layout, sinasaklaw ng talahanayang ito ang pinakakaraniwang kaayusan:

Dalawang tunnel, dalawang bisita, at ang mga hidwaan sa pagitan nila

Kapag kailangan mo ng dalawang labasan nang sabay, ang pattern na tumatagal ay isang tunnel bawat bisita. Pinapanatili ng bawat VM ang sariling default na ruta at resolver, nananatili ang host sa karaniwang network, at hindi kailanman nag-aaway ang dalawang tunnel sa iisang routing table. Ang pagtulay sa dalawang bisita ay hindi rin nagsasama ng kanilang mga ruta: nagbibigay ng landas ang virtual network, at kailangan pa ring sabihin sa bawat kliyente na maaaring laktawan ng lokal na trapikong ito ang tunnel.

Ang pagpapatakbo ng tunnel ng host at tunnel ng bisita nang magkasama ay lehitimo, at ang sadyang pagniniyong ay kung minsan siyang eksaktong gusto mo, lumalabas ang bisita sa sariling tunnel nito at lumalabas ang tunnel na iyon sa tunnel ng host. Ang ginagawa nitong pagkaantala ay walang nakasulat kung aling dulo ang dapat abutin sa aling layer. Magtago ng listahang may dalawang hanay ng destinasyon at may-ari, at ang hidwaan ng ruta ay nagiging paghahanap sa halip na isang hapon ng pagtuklas.

I-verify, pagkatapos ay iwanan ang pagbawi sa may-ari

Subukan mula sa loob ng bisita gamit ang sariwang proseso ng aplikasyon: trapiko, resolusyon ng pangalan, parehong pamilya ng address, at ano ang nangyayari kapag bumagsak ang tunnel. Walang sinasabi ang icon ng VPN ng host tungkol sa saklaw ng bisita, at iyon ang pinakakaraniwang maling kumpirmasyon sa buong larangang ito.

Ang pagbawi ay pag-aari din ng may-ari. Ang tunnel na pag-aari ng bisita ay naibabalik ng sariling kliyente ng bisita at ng mga rutang isinulat nito. Ang disenyong pag-aari ng host ay naibabalik ng pagkakasunod-sunod ng boot ng host, at ang mga tuntunin ng pagpapasa ay hindi nakakalampas sa reboot maliban kung ilalapat muli ng unit o gawain sa pagsisimula. Ang naibalik na snapshot ay isang deployment, hindi isang undo, dahil ibinabalik nito ang lumang kredensyal at lumang ruta kasama ng disk. Bago mo sabihing tapos na ang gawain, kumpirmahin na tumutugma pa rin ang may-ari sa linyang isinulat mo, na nalulutas ang DNS at parehong pamilya ng address sa loob ng bisita, na ang patay na tunnel ay nag-iiwan ng magagamit na network sa halip na itim na butas, at na ang reboot o pagbawi ng snapshot ay nagpaparami ng parehong kalagayan.