Ĉu ligu la VPN per la gastiganto aŭ ene de la VM? Gvidilo por decidi

Konstrui la tunelon ene de la gasto kaj konstrui ĝin per la gastiganto ambaŭ ŝanĝas la adreson, kiun raportas retumilo, kaj tie la simileco finiĝas. Tunelo posedata de la gasto tenas siajn ŝlosilojn, sian defaŭltan vojon kaj sian solvilon ene de la kerno de la gasto, dum la gastiganto plusendas ĉifritajn pakaĵojn al unu malproksima adreso. Tunelo posedata de la gastiganto estas la spegula bildo: la kliento de la gastiganto tenas la sesion kaj aplikas vojojn kaj politikon, kaj la gasto pruntas tion, kio eliras. Elektu la malĝustan posedanton kaj ĉiu posta simptomo sendos vin al la malĝusta maŝino. Du komandoj solvas la demandon en proksimume unu minuto, kaj la resto de ĉi tiu gvidilo estas kion fari kun la respondo.

Decidu la posedanton antaŭ ol tuŝi la klienton

La regulo temas pri tio, kie la ĉifroteksto estas produktata, ne pri tio, kiu maŝino montras VPN-ikonon. Se la gasto produktas ĝin, la gasto bezonas funkciantan vojon al la VPN-servilo kaj nenion alian de la gastiganto. Se la gastiganto produktas ĝin, la gasto bezonas, ke la vojo tra la gastiganto postvivu ajnan politikon, kiun la kliento de la gastiganto trudas al loka trafiko.

Tri demandoj kutime elektas la lokigon por vi. Ĉu la trafiko de la gasto devas postvivi korporacian klienton ĉe la gastiganto? Tiam la tunelo apartenas al la gasto. Ĉu pluraj gastoj bezonas unu akreditivon kaj unu eliran adreson? Tiam ĝi apartenas al la gastiganto, kun plusendado starigita intence. Ĉu la trafiko de la gasto devas resti tute ekster la VPN de la gastiganto? Tiam tunelo en la gasto estas la sola aranĝo, kiu donas tion al vi per konstruo.

Notu la respondon kiel unu linion apud la VM-nomo: guest-owned aŭ host-owned. En laboratorio de ses maŝinoj tiu noto ŝparas pli da tempo ol iu ajn paŝo sube, ĉar ĝi malhelpas vin serĉi fuŝaĵon en tunelo, kiu neniam estis en la maŝino, al kiu vi ensalutis.

WSL1 kaj WSL2 estas kontraŭaj kazoj

WSL1 ne estas virtuala maŝino, do la demando pri lokigo plejparte vaporiĝas. Ĝiaj Linux-binaroj funkcias kontraŭ la reta stako de Vindozo tra traduka tavolo, kaj Linux-VPN-kliento havas neniujn sendependajn interfacojn por agordi. La aranĝo, kiu funkcias, estas tunelo ĉe la Vindozaj flanko, kie la distribuo uzas la rezulton sen posedi ion ajn.

WSL2 estas la malo. Ĝi funkciigas veran kernon en malpeza utila VM malantaŭ virtuala Hyper-V-komutilo, kaj ĝia adresspaco estas NAT-tradukata tra adaptilo ĉe la gastiganta flanko. Linux-kliento ene de la distribuo do kondutas kiel sur fizika Linux-skatolo: ĝi kreas tun0 aŭ wg0, instalas siajn proprajn vojojn, kaj funkcias. La malsukceso loĝas ĉe la gastiganta flanko. Kiam Vindoz-VPN-kliento konektiĝas kun politiko, kiu blokas trafikon sur lokaj retoj, ĝi traktas la subreton WSL2 kiel nefidindan lokan reton kaj tranĉas la NAT-vojon. La distribuo tiam perdas DNS kaj eliran aliron, dum ĝia propra tunelo ankoraŭ sanas: wg show raportas manpremon, ip route aspektas ĝuste, kaj curl pendas.

Kiun riparon vi povas uzi dependas de la Vindoz-versio. La pli malnova estas escepto en la kliento de la gastiganto por la WSL-subreto, aldonita sub la agordoj de loka reto aŭ dividita tunelo de la kliento. La pli nova, ĉe Vindoz-versioj 11, kiuj subtenas ĝin, estas spegula retumado: metu networkingMode=mirrored en la sekcion [wsl2] de %UserProfile%\.wslconfig, rulu wsl --shutdown, kaj la distribuo dividos la interfacojn de la gastiganto anstataŭ privata NAT-subreto. Spegula reĝimo ankaŭ ŝanĝas kiel kondutas localhost kaj envenantaj pordoj, do traktu ĝin kiel migradon, ne kiel ŝaltilon.

NAT, ponto, kaj kion la gastiganto povas vidi

Sub NAT, la tunelaj pakaĵoj de la gasto estas adresitaj al la publika adreso de la VPN-servilo kaj eliras tra la adaptilo de la gastiganto kiel ĉifrita UDP aŭ TCP. La gastiganto vidas unu fluon kaj ĝian bajtokalkulon, nenion pri la celoj interne. Sub ponta adaptilo la gasto havas sian propran identecon de tavolo 2 en la fizika LAN, prenas sian propran DHCP-luon, kaj aspektas al ajna MAC-bazita politiko kiel dua aparato. Neniu el la du reĝimoj lasas la gastiganton legi la ŝarĝon de la tunelo; la ponta gasto simple estas multe pli videbla al la reto ĉirkaŭ ĝi.

Estas ankaŭ suba limo al la izolado. Gasto ne povas kaŝi sin de la maŝino, kiu posedas ĝian memoron, kaj kiu ajn regas la gastiganton povas legi ŝlosilojn el la RAM de la gasto. Kion donas al vi tunelo en la gasto estas limo de enkursigo kaj limo kontraŭ malica programaro, ne protekto kontraŭ la persono, kiu tenas la tekkomputilon. La dokumentitaj adaptilaj reĝimoj indas teni malfermaj dum vi elektas, ĉar la reĝimo ŝanĝas kaj kion vidas la gastiganto kaj kion vidas la LAN.

Gvidilo: lokigu ĝin, agordu ĝin, pruvu ĝin

Rulu ĉi tiujn kvar kontrolojn laŭorde en freŝa ŝelo de la gasto, kaj haltu ĉe la unua, kiu malkongruas kun la posedanto, kiun vi notis.

1. ip route get 1.1.1.1 redonanta tun0 aŭ wg0 signifas posedon de la gasto, kaj eth0 kun privata sekva salto signifas posedon de la gastiganto.
2. resolvectl query example.com, aŭ legu /etc/resolv.conf tie, kie la gasto ne rulas solvilan servon. Tunelo, kiu portas trafikon sed ne DNS, estas la plej ofta duone agordita stato.
3. Komparu elirojn: curl -4 -s https://ifconfig.me en la gasto kontraŭ curl.exe -4 -s https://ifconfig.me ĉe la gastiganto. Malsamaj adresoj signifas, ke la gasto posedas la tunelon, kaj gastiganto en VPN kun gasto montranta la hejman provizanton estas la kazo, kie oni heredis nenion.
4. Ripetu ambaŭ kun -6. Tunelo nur por v4 likas v6, se la kliento ne blokas aŭ enkursigas ĝin, kaj multaj klientoj lasas v6 sur la fizika interfaco defaŭlte.

Por dezajno kun gastiganta pordego, kie pluraj gastoj dividas unu tunelon, la gastiganto devas plusendi kaj traduki. Sur Linux-gastiganto tio estas tri pecoj, kaj la gasto kviete reiras al sia ordinara vojo, kiam mankas iu el ili:

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

Ĉe la WireGuard-flanko la AllowedIPs de la gastiganta partnero devas inkluzivi la subreton de la gastoj, ekzemple 192.168.122.0/24, alie la revenaj pakaĵoj neniam alvenas kaj la agordo aspektas kiel fajroŝirma problemo. Vindoz-gastiganto atingas la saman rezulton per Interreta Konekta Kunuzado aŭ NAT-regulo sur la Hyper-V-komutilo, kaj bezonas la saman kontrolon de la revena vojo.

Kiam la aranĝo ankoraŭ malfermiĝas, ĉi tiu tabelo kovras la plej oftajn kazojn:

Du tuneloj, du gastoj, kaj la konfliktoj inter ili

Kiam vi bezonas du elirojn samtempe, la ŝablono, kiu teniĝas, estas unu tunelo por gasto. Ĉiu VM tenas sian propran defaŭltan vojon kaj solvilon, la gastiganto restas sur la ordinara reto, kaj la du tuneloj neniam disputas pri la sama enkursiga tabelo. Ponti du gastojn kune ankaŭ ne kunigas iliajn vojojn: la virtuala reto provizas vojon, kaj al ĉiu kliento ankoraŭ devas esti dirite, ke ĉi tiu loka trafiko rajtas preteriri la tunelon.

Ruli gastigantan tunelon kaj gastan tunelon kune estas laŭleĝe, kaj intenca nestado estas foje ĝuste tio, kion vi volas, kun la gasto eliranta tra sia propra tunelo kaj tiu tunelo eliranta tra tiu de la gastiganto. Kio igas ĝin interrompo estas, ke neniu notis, kiu finpunkto estu atingata tra kiu tavolo. Tenu du-kolumnan liston de celo kaj posedanto, kaj voja konflikto fariĝas serĉo anstataŭ posttagmezo da malkovrado.

Kontrolu, poste lasu la restarigon ĉe la posedanto

Testu el la interno de la gasto per freŝa aplikaĵa procezo: trafiko, nomsolvado, ambaŭ adresaj familioj, kaj kio okazas, kiam la tunelo falas. La VPN-ikono de la gastiganto diras nenion pri la kovrado de la gasto, kaj tio estas la plej ofta falsa konfirmo en ĉi tiu tuta kampo.

La restarigo apartenas ankaŭ al la posedanto. Tunelo posedata de la gasto restarigatas per la propra kliento de la gasto kaj la vojoj, kiujn ĝi skribis. Dezajno posedata de la gastiganto restarigatas per la starta sinsekvo de la gastiganto, kaj la plusendaj reguloj ne postvivas restartigon, se unuo aŭ starta tasko ne reaplikas ilin. Restarigita momentfoto estas surmeto, ne malfaro, ĉar ĝi revenigas malnovajn akreditivojn kaj malnovajn vojojn kune kun la disko. Antaŭ ol vi nomos la laboron finita, konfirmu, ke la posedanto ankoraŭ kongruas kun la linio, kiun vi notis, ke DNS kaj ambaŭ adresaj familioj solviĝas ene de la gasto, ke morta tunelo lasas uzeblan reton anstataŭ nigra truo, kaj ke restartigo aŭ momentfota restarigo reproduktas la saman staton.