Spustiť VPN na hostiteľovi alebo vo vnútri VM? Rozhodovacia príručka

Postaviť tunel vnútri hosta a postaviť ho na hostiteľovi oba menia adresu, ktorú hlási prehliadač, a tam sa podobnosť končí. Tunel patriaci hostovi si drží svoje kľúče, svoju predvolenú trasu a svoj resolver v jadre hosta, zatiaľ čo hostiteľ preposiela šifrované pakety na jednu vzdialenú adresu. Tunel patriaci hostiteľovi je zrkadlový obraz: klient hostiteľa drží reláciu a uplatňuje trasy a politiku a hosť si požičiava to, čo vyjde. Zvoľte nesprávneho vlastníka a každý ďalší príznak vás pošle na nesprávny stroj. Dva príkazy rozhodnú otázku zhruba za minútu a zvyšok tejto príručky je, čo s odpoveďou urobiť.

Rozhodnite o vlastníkovi, skôr než sa dotknete klienta

Pravidlo je o tom, kde vzniká šifrovaný text, nie o tom, ktorý stroj zobrazuje ikonu VPN. Ak ho vytvára hosť, hosť potrebuje funkčnú trasu na server VPN a nič iné od hostiteľa. Ak ho vytvára hostiteľ, hosť potrebuje, aby cesta cez hostiteľa prežila akúkoľvek politiku, ktorú klient hostiteľa uvalí na miestnu prevádzku.

Tri otázky zvyčajne vyberú umiestnenie za vás. Musí prevádzka hosta prežiť podnikového klienta na hostiteľovi? Potom tunel patrí do hosta. Potrebuje niekoľko hostov jedny prihlasovacie údaje a jednu výstupnú adresu? Potom patrí na hostiteľa, s preposielaním nastaveným zámerne. Má prevádzka hosta zostať úplne mimo VPN hostiteľa? Potom je tunel v hostovi jediné usporiadanie, ktoré to dáva samotnou konštrukciou.

Zapíšte odpoveď ako jeden riadok vedľa názvu VM: guest-owned alebo host-owned. V laboratóriu šiestich strojov tá poznámka ušetrí viac času než ktorýkoľvek krok nižšie, pretože vám zabráni hľadať poruchu v tuneli, ktorý nikdy nebol v stroji, na ktorý ste sa prihlásili.

WSL1 a WSL2 sú opačné prípady

WSL1 nie je virtuálny stroj, takže otázka umiestnenia väčšinou vyprchá. Jeho linuxové binárky bežia proti sieťovému zásobníku Windows cez prekladovú vrstvu a linuxový klient VPN nemá nezávislé rozhrania na nastavenie. Funguje usporiadanie s tunelom na strane Windows, pri ktorom distribúcia výsledok používa bez toho, aby čokoľvek vlastnila.

WSL2 je opak. Spúšťa skutočné jadro v odľahčenej pomocnej VM za virtuálnym prepínačom Hyper-V a jeho adresný priestor sa prekladá cez adaptér na strane hostiteľa. Preto sa linuxový klient v distribúcii správa ako na fyzickom linuxovom stroji: vytvorí tun0 alebo wg0, nainštaluje vlastné trasy a funguje. Zlyhanie žije na strane hostiteľa. Keď sa klient VPN pre Windows pripojí s politikou, ktorá blokuje prevádzku v miestnych sieťach, považuje podsieť WSL2 za nedôveryhodnú miestnu sieť a preruší cestu NAT. Distribúcia potom stratí DNS a odchádzajúci prístup, zatiaľ čo jej vlastný tunel je stále zdravý: wg show hlási podanie ruky, ip route vyzerá správne a curl visí.

Ktorú opravu môžete použiť, závisí od zostavy Windows. Staršia je výnimka v klientovi hostiteľa pre podsieť WSL, pridaná v nastaveniach miestnej siete alebo rozdeleného tunela klienta. Novšia, na zostavách Windows 11, ktoré ju podporujú, je zrkadlové sieťovanie: vložte networkingMode=mirrored do sekcie [wsl2] súboru %UserProfile%\.wslconfig, spustite wsl --shutdown a distribúcia bude zdieľať rozhrania hostiteľa namiesto súkromnej podsiete NAT. Zrkadlový režim mení aj správanie localhostu a prichádzajúcich portov, takže k nemu pristupujte ako k migrácii, nie ako k prepínaču.

NAT, most a čo hostiteľ vidí

Pod NAT sú pakety tunela hosta adresované na verejnú adresu servera VPN a odchádzajú cez adaptér hostiteľa ako šifrované UDP alebo TCP. Hostiteľ vidí jeden tok a počet jeho bajtov, nič o cieľoch vnútri. Pod mostovým adaptérom má hosť vlastnú identitu vrstvy 2 vo fyzickej LAN, berie si vlastný DHCP prenájom a pre každú politiku založenú na MAC vyzerá ako druhé zariadenie. Ani jeden režim nedovoľuje hostiteľovi čítať užitočné zaťaženie tunela; mostový hosť je jednoducho oveľa viditeľnejší pre sieť okolo seba.

Izolácia má tiež spodnú hranicu. Hosť sa nemôže skryť pred strojom, ktorý vlastní jeho pamäť, a kto ovláda hostiteľa, môže čítať kľúče z RAM hosta. Tunel v hostovi vám dáva hranicu smerovania a hranicu proti škodlivému softvéru, nie ochranu pred človekom, ktorý drží notebook. Dokumentované režimy adaptéra sa oplatí mať otvorené, kým vyberáte, pretože režim mení to, čo vidí hostiteľ aj čo vidí LAN.

Príručka: umiestnite, nastavte, dokážte

Spustite tieto štyri kontroly v poradí v čerstvej hostovej shell a zastavte sa pri prvej, ktorá sa nezhoduje so zapísaným vlastníkom.

1. ip route get 1.1.1.1, ktoré vracia tun0 alebo wg0, znamená vlastníctvo hosta, a eth0 so súkromným ďalším skokom znamená vlastníctvo hostiteľa.
2. resolvectl query example.com, alebo si prečítajte /etc/resolv.conf tam, kde hosť nespúšťa službu resolvera. Tunel, ktorý nesie prevádzku, ale nie DNS, je najčastejší napoly nastavený stav.
3. Porovnajte výstupy: curl -4 -s https://ifconfig.me v hostovi proti curl.exe -4 -s https://ifconfig.me na hostiteľovi. Rôzne adresy znamenajú, že tunel vlastní hosť, a hostiteľ vo VPN s hosťom, ktorý ukazuje domáceho poskytovateľa, je prípad, keď sa nič nezdedilo.
4. Zopakujte oboje s -6. Tunel iba pre v4 prepúšťa v6, ak ho klient nezablokuje alebo nesmeruje, a mnohí klienti nechávajú v6 na fyzickom rozhraní predvolene.

Pri návrhu s hostiteľskou bránou, kde niekoľko hostov zdieľa jeden tunel, musí hostiteľ preposielať a prekladať. Na linuxovom hostiteľovi sú to tri časti a hosť sa ticho vráti na svoju obyčajnú trasu, keď niektorá chýba:

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

Na strane WireGuardu musí AllowedIPs hostiteľského partnera obsahovať podsieť hostov, napríklad 192.168.122.0/24, inak návratové pakety nikdy nedorazia a nastavenie vyzerá ako problém s firewallom. Windows hostiteľ dosiahne rovnaký výsledok cez Zdieľanie pripojenia na internet alebo pravidlo NAT na prepínači Hyper-V a potrebuje rovnakú kontrolu návratovej cesty.

Keď je usporiadanie ešte otvorené, táto tabuľka pokrýva najčastejšie prípady:

Dva tunely, dvaja hostia a konflikty medzi nimi

Keď potrebujete dva výstupy naraz, vzor, ktorý vydrží, je jeden tunel na hosta. Každá VM si drží svoju predvolenú trasu a resolver, hostiteľ zostáva v obyčajnej sieti a dva tunely sa nikdy nehádajú o tú istú smerovaciu tabuľku. Most medzi dvoma hosťami ani nezlieva ich trasy: virtuálna sieť poskytuje cestu a každému klientovi treba stále povedať, že táto miestna prevádzka môže tunel obísť.

Spúšťať tunel hostiteľa a tunel hosta spolu je legitímne a zámerné vnorenie je niekedy presne to, čo chcete, pričom hosť vychádza vlastným tunelom a ten tunel vychádza tunelom hostiteľa. Prestojom to robí to, že nikto nezapísal, ktorý koncový bod sa má cez ktorú vrstvu dosiahnuť. Veďte zoznam dvoch stĺpcov s cieľom a vlastníkom a konflikt trás sa stane vyhľadaním namiesto popoludnia objavovania.

Overte a potom nechajte obnovu vlastníkovi

Testujte zvnútra hosta čerstvým procesom aplikácie: prevádzka, preklad mien, obe rodiny adries a čo sa stane, keď tunel padne. Ikona VPN na hostiteľovi nič nehovorí o pokrytí hosta, a to je najčastejšie falošné potvrdenie v celej tejto oblasti.

Obnova patrí tiež vlastníkovi. Tunel patriaci hostovi sa obnovuje vlastným klientom hosta a trasami, ktoré zapísal. Návrh patriaci hostiteľovi sa obnovuje postupnosťou zavádzania hostiteľa a pravidlá preposielania neprežijú reštart, ak ich znova neuplatní unit alebo úloha pri štarte. Obnovený snapshot je nasadenie, nie vrátenie, pretože prináša späť staré prihlasovacie údaje a staré trasy spolu s diskom. Skôr než prácu vyhlásite za hotovú, potvrďte, že vlastník stále zodpovedá zapísanému riadku, že DNS a obe rodiny adries sa v hostovi prekladajú, že mŕtvy tunel necháva použiteľnú sieť namiesto čiernej diery a že reštart alebo obnova snapshotu reprodukuje ten istý stav.