Käivitada VPN hostis või VM-i sees? Otsustusjuhend

Tunneli ehitamine külalise sees ja selle ehitamine hostis muudavad mõlemad aadressi, mida brauser teatab, ja sealt sarnasus lõpeb. Külalisele kuuluv tunnel hoiab oma võtmed, oma vaiketee ja oma resolveri külalise tuumas, samal ajal kui host edastab krüpteeritud paketid ühele kaugemale aadressile. Hostile kuuluv tunnel on peegelpilt: hosti klient hoiab seanssi ning rakendab marsruute ja poliitikat, ja külaline laenab selle, mis välja tuleb. Valige vale omanik ja iga hilisem sümptom saadab teid vale masina juurde. Kaks käsku otsustavad küsimuse umbes minutiga, ja ülejäänud osa sellest juhendist on see, mida vastusega teha.

Otsustage omanik enne, kui klienti puudutate

Reegel käib selle kohta, kus šifreeritud tekst tekib, mitte selle kohta, milline masin VPN-i ikooni näitab. Kui selle toodab külaline, vajab külaline töötavat marsruuti VPN-serverini ja mitte midagi muud hostist. Kui selle toodab host, peab külalise tee läbi hosti vastu pidama igale poliitikale, mille hosti klient kohalikule liiklusele peale paneb.

Kolm küsimust valivad paigutuse tavaliselt teie eest. Kas külalise liiklus peab üle elama hostis oleva ettevõtte kliendi? Siis kuulub tunnel külalisesse. Kas mitmel külalisel on vaja üht mandaati ja üht väljundiaadressi? Siis kuulub see hosti, edastamine on meelega seadistatud. Kas külalise liiklus peaks jääma hosti VPN-ist täiesti välja? Siis on külalise tunnel ainus lahendus, mis annab selle konstruktsiooni järgi.

Kirjutage vastus ühe reana VM-i nime kõrvale: guest-owned või host-owned. Kuue masinaga laboris säästab see märge rohkem aega kui ükski allpool olev samm, sest see takistab teil otsida viga tunnelist, mida polnud kunagi masinas, millesse te sisse logisite.

WSL1 ja WSL2 on vastandlikud juhtumid

WSL1 ei ole virtuaalmasin, seega paigutusküsimus enamasti haihtub. Selle Linuxi binaarid töötavad Windowsi võrgupinu vastu tõlkekihi kaudu ja Linuxi VPN-kliendil pole iseseisvaid liideseid, mida seadistada. Toimiv lahendus on tunnel Windowsi poolel, kus distributsioon kasutab tulemust ilma midagi omades.

WSL2 on vastupidi. See käitab tõelist tuuma kerges utiliit-VM-is Hyper-V virtuaallüliti taga ja selle aadressiruum NAT-itakse hostipoolse adapteri kaudu. Seetõttu käitub distributsiooni sees olev Linuxi klient nagu füüsilisel Linuxi masinal: see loob tun0 või wg0, paigaldab oma marsruudid ja töötab. Rike elab hosti poolel. Kui Windowsi VPN-klient ühendub poliitikaga, mis blokeerib liiklust kohalikes võrkudes, kohtleb see WSL2 alavõrku ebausaldusväärse kohaliku võrguna ja lõikab NAT-tee läbi. Seejärel kaotab distributsioon DNS-i ja väljamineva juurdepääsu, samal ajal kui selle enda tunnel on veel terve: wg show teatab kätlemisest, ip route näeb õige välja ja curl ripub.

Millist parandust saate kasutada, sõltub Windowsi buildist. Vanem on hosti kliendis WSL-i alavõrgu erand, mis lisatakse kliendi kohaliku võrgu või jagatud tunneli seadete alla. Uuem, seda toetavatel Windows 11 buildidel, on peegeldatud võrk: pange networkingMode=mirrored faili %UserProfile%\.wslconfig jaotisse [wsl2], käivitage wsl --shutdown, ja distributsioon jagab hosti liideseid eraseisva NAT-alavõrgu asemel. Peegeldatud režiim muudab ka localhosti ja sissetulevate portide käitumist, seega käsitlege seda migratsioonina, mitte lülitina.

NAT, sild ja mida host näeb

NAT-i all suunatakse külalise tunnelipaketid VPN-serveri avalikule aadressile ja need väljuvad hosti adapteri kaudu krüpteeritud UDP või TCP-na. Host näeb üht voogu ja selle baidiarvu, mitte midagi sees olevate sihtkohtade kohta. Sillaadapteri all on külalisel oma 2-kihiline identiteet füüsilises LAN-is, ta võtab oma DHCP-rendi ja näeb MAC-põhise poliitika jaoks välja nagu teine seade. Kumbki režiim ei lase hostil tunneli sisu lugeda; sillatud külaline on lihtsalt ümbritsevale võrgule palju nähtavam.

Isolatsioonil on ka alumine piir. Külaline ei saa peituda masina eest, millele kuulub tema mälu, ja kes hosti kontrollib, saab külalise RAM-ist võtmeid lugeda. Külalise tunnel annab teile marsruutimise piiri ja pahavara piiri, mitte kaitset sülearvutit hoidva inimese eest. Dokumenteeritud adapterirežiimid tasub valides lahti hoida, sest režiim muudab nii seda, mida host näeb, kui seda, mida LAN näeb.

Juhend: paiguta, seadista, tõesta

Käivitage need neli kontrolli järjekorras värskes külalise shellis ja peatuge esimese juures, mis ei nõustu kirja pandud omanikuga.

1. ip route get 1.1.1.1, mis tagastab tun0 või wg0, tähendab külalise omandit, ja eth0 eraseisva järgmise hüppega tähendab hosti omandit.
2. resolvectl query example.com, või lugege /etc/resolv.conf seal, kus külaline ei käita resolveri teenust. Tunnel, mis kannab liiklust, aga mitte DNS-i, on kõige tavalisem pooleldi seadistatud olek.
3. Võrrelge väljundeid: curl -4 -s https://ifconfig.me külalises versus curl.exe -4 -s https://ifconfig.me hostis. Erinevad aadressid tähendavad, et tunnel kuulub külalisele, ja host VPN-is, kus külaline näitab kodust teenusepakkujat, on juhtum, kus midagi ei päritud.
4. Korrake mõlemat -6-ga. Ainult v4 tunnel lekitab v6, kui klient seda ei blokeeri või marsruudi, ja paljud kliendid jätavad v6 vaikimisi füüsilisele liidesele.

Hosti lüüsi lahenduse puhul, kus mitu külalist jagavad üht tunnelit, peab host edastama ja tõlkima. Linuxi hostis on need kolm osa ja külaline langeb vaikselt tagasi oma tavalisele marsruudile, kui mõni neist puudub:

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

WireGuardi poolel peab hosti partneri AllowedIPs sisaldama külaliste alavõrku, näiteks 192.168.122.0/24, muidu ei jõua tagasipaketid kunagi kohale ja seadistus näeb välja nagu tulemüüri probleem. Windowsi host saavutab sama tulemuse Internet Connection Sharinguga või NAT-reegliga Hyper-V lülitil ja vajab sama tagasitee kontrolli.

Kui paigutus on veel lahtine, katab see tabel kõige sagedasemad lahendused:

Kaks tunnelit, kaks külalist ja nendevahelised konfliktid

Kui vajate korraga kaht väljundit, peab vastu muster üks tunnel külalise kohta. Iga VM hoiab oma vaikemarsruuti ja resolverit, host jääb tavalisele võrgule ja kaks tunnelit ei vaidle kunagi sama marsruutimistabeli pärast. Kahe külalise sillaga ühendamine ei ühenda nende marsruute: virtuaalvõrk annab tee ja igale kliendile tuleb ikka öelda, et see kohalik liiklus võib tunnelist mööda minna.

Hosti tunneli ja külalise tunneli koos käitamine on seaduslik ja meelega pesastamine on mõnikord täpselt see, mida soovite, kus külaline väljub oma tunnelist ja see tunnel väljub hosti tunnelist. Katkestuseks muudab selle see, et keegi ei kirjutanud üles, millisele lõpp-punktile millise kihi kaudu jõuda. Hoidke kahe veeruga nimekirja sihtkohast ja omanikust ning marsruudikonflikt muutub otsinguks tervikliku avastamise päeva asemel.

Kontrollige ja jätke taastamine omaniku juurde

Testige külalise seest värske rakenduse protsessiga: liiklus, nimede lahendamine, mõlemad aadressiperekonnad ja mis juhtub, kui tunnel katkeb. Hosti VPN-i ikoon ei ütle külalise katvuse kohta midagi ja see on kogu selles valdkonnas kõige tavalisem vale kinnitus.

Taastamine kuulub samuti omanikule. Külalisele kuuluv tunnel taastatakse külalise enda kliendi ja tema kirjutatud marsruutidega. Hostile kuuluv lahendus taastatakse hosti alglaadimise järjestusega ja edastusreeglid ei ela üle taaskäivitust, kui neid ei rakenda uuesti unit või käivitustöö. Taastatud hetktõmmis on juurutus, mitte tagasivõtmine, sest see toob koos kettaga tagasi vanad mandaadid ja vanad marsruudid. Enne kui töö lõpetatuks nimetate, kinnitage, et omanik vastab endiselt kirja pandud reale, et DNS ja mõlemad aadressiperekonnad lahendatakse külalise sees, et surnud tunnel jätab musta augu asemel kasutatava võrgu ja et taaskäivitus või hetktõmmise taastamine annab sama oleku.