Ta ekzekutojmë VPN-në në host apo brenda VM-së? Udhëzues vendimi

Ndërtimi i tunelit brenda mysafirit dhe ndërtimi i tij në host ndryshojnë të dy adresën që raporton shfletuesi, dhe aty mbaron ngjashmëria. Një tunel në pronësi të mysafirit mban çelësat e tij, rrugën e tij të parazgjedhur dhe zgjidhësin e tij brenda kernelit të mysafirit, ndërsa hosti përcjell paketa të kriptuara drejt një adrese të vetme të largët. Një tunel në pronësi të hostit është imazhi pasqyrë: klienti i hostit mban sesionin dhe zbaton rrugë e politikë, dhe mysafiri huazon atë që del. Zgjidhni pronarin e gabuar dhe çdo simptomë e mëvonshme ju dërgon te makina e gabuar. Dy komanda e zgjidhin çështjen për rreth një minute, dhe pjesa tjetër e këtij udhëzuesi është çfarë të bëni me përgjigjen.

Vendosni pronarin përpara se të prekni klientin

Rregulli ka të bëjë me vendin ku prodhohet teksti i kriptuar, jo me atë se cila makinë shfaq një ikonë VPN. Nëse e prodhon mysafiri, mysafirit i duhet një rrugë funksionale drejt serverit VPN dhe asgjë tjetër nga hosti. Nëse e prodhon hosti, mysafirit i duhet që rruga përmes hostit t'i mbijetojë çdo politike që klienti i hostit imponon mbi trafikun lokal.

Tri pyetje zakonisht e zgjedhin vendosjen për ju. A duhet trafiku i mysafirit t'i mbijetojë një klienti korporativ në host? Atëherë tuneli është brenda mysafirit. A kanë nevojë disa mysafirë për një kredencial të vetëm dhe një adresë të vetme daljeje? Atëherë është në host, me përcjelljen e konfiguruar qëllimisht. A duhet trafiku i mysafirit të qëndrojë plotësisht jashtë VPN-së së hostit? Atëherë një tunel në mysafir është i vetmi rregullim që jua jep këtë nga vetë ndërtimi.

Shkruajeni përgjigjen në një rresht pranë emrit të VM-së: guest-owned ose host-owned. Në një laborator me gjashtë makina ai shënim kursen më shumë kohë sesa çdo hap më poshtë, sepse ju pengon të diagnostikoni një tunel që nuk ishte kurrë në makinën ku jeni futur.

WSL1 dhe WSL2 janë raste të kundërta

WSL1 nuk është makinë virtuale, ndaj pyetja e vendosjes në pjesën më të madhe avullon. Binaret e tij Linux ekzekutohen kundrejt stivës së rrjetit të Windows përmes një shtrese përkthimi, dhe një klient VPN Linux nuk ka ndërfaqe të pavarura për t'u konfiguruar. Ajo që funksionon është një tunel në anën e Windows, me shpërndarjen që përdor rezultatin pa zotëruar asgjë.

WSL2 është e kundërta. Ekzekuton një kernel të vërtetë në një VM ndihmëse të lehtë pas një ndërprerësi virtual Hyper-V, dhe hapësira e adresave përkthehet me NAT përmes një përshtatësi në anën e hostit. Prandaj një klient Linux brenda shpërndarjes sillet si në një kuti Linux fizike: krijon tun0 ose wg0, instalon rrugët e veta dhe funksionon. Dështimi banon në anën e hostit. Kur një klient VPN i Windows lidhet me një politikë që bllokon trafikun në rrjetet lokale, e trajton nënrrjetin WSL2 si rrjet lokal jo i besuar dhe e pret rrugën NAT. Shpërndarja atëherë humbet DNS dhe aksesin dalës, ndërsa tuneli i saj është ende i shëndetshëm: wg show raporton shtrëngim duarsh, ip route duket korrekt, dhe curl varet.

Cila rregullim mund të përdorni varet nga ndërtimi i Windows. Më i vjetri është një përjashtim në klientin e hostit për nënrrjetin WSL, i shtuar nën cilësimet e rrjetit lokal ose të tunelit të ndarë të klientit. Më i riu, në ndërtimet e Windows 11 që e mbështesin, është rrjetëzimi i pasqyruar: vendosni networkingMode=mirrored në seksionin [wsl2] të %UserProfile%\.wslconfig, ekzekutoni wsl --shutdown, dhe shpërndarja ndan ndërfaqet e hostit në vend të një nënrrjeti privat NAT. Modaliteti i pasqyruar ndryshon edhe sjelljen e localhost dhe e porteve hyrëse, ndaj trajtojeni si migrim dhe jo si çelës.

NAT, urë dhe çfarë mund të shohë hosti

Nën NAT, paketat e tunelit të mysafirit adresohen drejt adresës publike të serverit VPN dhe dalin përmes përshtatësit të hostit si UDP ose TCP i kriptuar. Hosti sheh një rrjedhë të vetme dhe numrin e bajteve të saj, asgjë për destinacionet brenda saj. Nën një përshtatës me urë mysafiri ka identitetin e vet të shtresës 2 në LAN-in fizik, merr qiranë e vet DHCP, dhe për çdo politikë të bazuar në MAC duket si pajisje e dytë. Asnjëri modalitet nuk lejon hostin të lexojë ngarkesën e tunelit; mysafiri me urë është thjesht shumë më i dukshëm për rrjetin përreth.

Izolimi ka gjithashtu një dysheme. Një mysafir nuk mund t'i fshihet makinës që zotëron memorjen e tij, dhe kushdo që kontrollon hostin mund të lexojë çelësa nga RAM-i i mysafirit. Ajo që ju jep një tunel në mysafir është një kufi rrugëtimi dhe një kufi kundër malware, jo mbrojtje nga personi që mban laptopin. Ja vlen t'i mbani hapur modalitetet e dokumentuara të përshtatësit ndërsa zgjidhni, pasi modaliteti ndryshon si atë që sheh hosti ashtu edhe atë që sheh LAN-i.

Udhëzues: vendoseni, konfiguroni, provojeni

Ekzekutoni këto katër kontrolle sipas radhës në një shell të ri të mysafirit dhe ndaloni te i pari që nuk përputhet me pronarin që shënuat.

1. ip route get 1.1.1.1 që kthen tun0 ose wg0 do të thotë pronësi e mysafirit, dhe eth0 me një kërcim tjetër privat do të thotë pronësi e hostit.
2. resolvectl query example.com, ose lexoni /etc/resolv.conf aty ku mysafiri nuk ekzekuton asnjë shërbim zgjidhësi. Një tunel që transporton trafik por jo DNS është gjendja gjysmë e konfiguruar më e zakonshme.
3. Krahasoni daljet: curl -4 -s https://ifconfig.me në mysafir kundrejt curl.exe -4 -s https://ifconfig.me në host. Adresa të ndryshme do të thonë se mysafiri zotëron tunelin, dhe një host në VPN me një mysafir që tregon ISP-në e shtëpisë është rasti ku asgjë nuk u trashëgua.
4. Përsëritini të dyja me -6. Një tunel vetëm v4 rrjedh v6, përveç nëse klienti e bllokon ose e rrugëton, dhe shumë klientë e lënë v6 në ndërfaqen fizike si parazgjedhje.

Në një dizajn me portë në host, ku disa mysafirë ndajnë një tunel, hosti duhet të përcjellë dhe të përkthejë. Në një host Linux ato janë tri pjesë, dhe mysafiri bie në heshtje përsëri në rrugën e tij të thjeshtë kur mungon ndonjëra:

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

Në anën e WireGuard, AllowedIPs i partnerit të hostit duhet të përfshijë nënrrjetin e mysafirëve, për shembull 192.168.122.0/24, përndryshe paketat e kthimit nuk arrijnë kurrë dhe konfigurimi duket si problem i murit të zjarrit. Një host Windows e arrin të njëjtin rezultat me Ndarjen e Lidhjes në Internet ose me një rregull NAT në ndërprerësin Hyper-V, dhe ka nevojë për të njëjtin kontroll të rrugës së kthimit.

Kur skema është ende e hapur, kjo tabelë mbulon rregullimet më të shpeshta:

Dy tunele, dy mysafirë dhe konfliktet mes tyre

Kur ju duhen dy dalje njëherësh, modeli që qëndron është një tunel për mysafir. Çdo VM mban rrugën e vet të parazgjedhur dhe zgjidhësin e vet, hosti qëndron në rrjetin e zakonshëm, dhe dy tunelet nuk grindën kurrë për të njëjtën tabelë rrugëtimi. Lidhja e dy mysafirëve me urë nuk i bashkon as rrugët e tyre: rrjeti virtual ofron një rrugë, dhe çdo klienti ende duhet t'i thuhet se ky trafik lokal mund ta anashkalojë tunelin.

Ekzekutimi i një tuneli host dhe një tuneli mysafir bashkë është i ligjshëm, dhe folezimi i qëllimshëm ndonjëherë është pikërisht ajo që dëshironi, me mysafirin që del përmes tunelit të vet dhe ai tunel që del përmes atij të hostit. Ajo që e kthen në ndërprerje është se askush nuk shënoi cila pikë fundore duhet të arrihet përmes cilit shtresë. Mbani një listë me dy kolona me destinacion dhe pronar, dhe një konflikt rrugësh bëhet një kërkim në vend të një pasditeje zbulimi.

Verifikoni, pastaj lëreni rikuperimin te pronari

Testoni nga brenda mysafirit me një proces të ri aplikacioni: trafik, zgjidhje emrash, të dyja familjet e adresave dhe çfarë ndodh kur tuneli bie. Ikona VPN e hostit nuk thotë asgjë për mbulimin e mysafirit, dhe ky është konfirmimi i rremë më i zakonshëm në gjithë këtë fushë.

Rikuperimi i përket gjithashtu pronarit. Një tunel në pronësi të mysafirit rikthehet nga klienti vetë i mysafirit dhe rrugët që ai shkroi. Një dizajn në pronësi të hostit rikthehet nga sekuenca e nisjes së hostit, dhe rregullat e përcjelljes nuk i mbijetojnë një rindezjeje nëse një njësi ose një detyrë nisjeje nuk i zbaton përsëri. Një pamje e rikthyer është një vendosje, jo një zhbërje, sepse kthen kredenciale të vjetra dhe rrugë të vjetra bashkë me diskun. Përpara se ta shpallni punën të kryer, konfirmoni që pronari ende përputhet me rreshtin që shënuat, që DNS dhe të dyja familjet e adresave zgjidhen brenda mysafirit, që një tunel i vdekur lë një rrjet të përdorshëm në vend të një vrime të zezë, dhe që një rindezje ose rikthim i pamjes riprodhon të njëjtën gjendje.