VPN na hostiteli, nebo uvnitř VM? Rozhodovací příručka

Stavět tunel uvnitř hosta a stavět ho na hostiteli mění v obou případech adresu, kterou prohlížeč hlásí, a právě tam podobnost končí. Tunel patřící hostovi drží své klíče, svou výchozí trasu a svůj resolver uvnitř jádra hosta, zatímco hostitel přeposílá šifrované pakety na jednu vzdálenou adresu. Tunel patřící hostiteli je zrcadlový obraz: klient na hostiteli drží relaci a uplatňuje trasy a politiku a host si půjčuje, co vyjde. Zvolte špatného vlastníka a každý další příznak vás pošle na špatný stroj. Dva příkazy rozhodnou otázku za zhruba minutu a zbytek této příručky je, co s odpovědí udělat.

Rozhodněte o vlastníkovi, než se dotknete klienta

Pravidlo je o tom, kde vzniká šifrovaný text, ne o tom, který stroj ukazuje ikonu VPN. Pokud ho vytváří host, potřebuje host funkční trasu na server VPN a nic dalšího z hostitele. Pokud ho vytváří hostitel, potřebuje host, aby cesta přes hostitele přežila jakoukoli politiku, kterou klient na hostiteli uvalí na místní provoz.

Tři otázky obvykle vyberou umístění za vás. Musí provoz hosta přežít podnikového klienta na hostiteli? Pak tunel patří do hosta. Potřebuje několik hostů jedny přihlašovací údaje a jednu výstupní adresu? Pak patří na hostitele, s přeposíláním nastaveným záměrně. Má provoz hosta zůstat zcela mimo VPN hostitele? Pak je tunel v hostovi jediné uspořádání, které vám to dá samotnou konstrukcí.

Zapište odpověď jako jeden řádek vedle jména VM: guest-owned nebo host-owned. V laboratoři šesti strojů ta poznámka ušetří víc času než kterýkoli krok níže, protože vám zabrání hledat závadu v tunelu, který nikdy nebyl ve stroji, na který jste se přihlásili.

WSL1 a WSL2 jsou opačné případy

WSL1 není virtuální stroj, takže otázka umístění většinou vyprchá. Jeho linuxové binárky běží proti síťovému zásobníku Windows přes překladovou vrstvu a linuxový klient VPN nemá nezávislá rozhraní k nastavení. Funguje uspořádání s tunelem na straně Windows, kdy distribuce výsledek používá, aniž by cokoli vlastnila.

WSL2 je opak. Spouští skutečné jádro v odlehčené pomocné VM za virtuálním přepínačem Hyper-V a jeho adresní prostor se překládá přes adaptér na straně hostitele. Linuxový klient uvnitř distribuce se proto chová jako na fyzickém linuxovém stroji: vytvoří tun0 nebo wg0, nainstaluje vlastní trasy a funguje. Selhání žije na straně hostitele. Když se klient VPN pro Windows připojí s politikou, která blokuje provoz v místních sítích, považuje podsíť WSL2 za nedůvěryhodnou místní síť a přeruší cestu NAT. Distribuce pak ztratí DNS a odchozí přístup, zatímco její vlastní tunel je stále zdravý: wg show hlásí handshake, ip route vypadá správně a curl visí.

Kterou opravu můžete použít, závisí na sestavení Windows. Starší je výjimka v klientovi na hostiteli pro podsíť WSL, přidaná v nastavení místní sítě nebo rozděleného tunelu klienta. Novější, na sestaveních Windows 11, která ji podporují, je zrcadlové síťování: vložte networkingMode=mirrored do sekce [wsl2] souboru %UserProfile%\.wslconfig, spusťte wsl --shutdown a distribuce bude sdílet rozhraní hostitele místo privátní podsítě NAT. Zrcadlový režim mění i chování localhostu a příchozích portů, takže k němu přistupujte jako k migraci, ne jako k přepínači.

NAT, most a co hostitel vidí

Pod NAT jsou pakety tunelu hosta adresovány na veřejnou adresu serveru VPN a odcházejí přes adaptér hostitele jako šifrované UDP nebo TCP. Hostitel vidí jeden tok a počet jeho bajtů, nic o cílech uvnitř něj. Pod mostovým adaptérem má host vlastní identitu vrstvy 2 ve fyzické LAN, bere si vlastní DHCP lease a pro každou politiku založenou na MAC vypadá jako druhé zařízení. Ani jeden režim nedovolí hostiteli číst užitečné zatížení tunelu; mostový host je prostě mnohem viditelnější pro síť kolem sebe.

Existuje i spodní hranice izolace. Host se nemůže schovat před strojem, který vlastní jeho paměť, a kdo ovládá hostitele, může číst klíče z RAM hosta. Tunel v hostovi vám dává hranici směrování a hranici pro škodlivý software, ne ochranu před člověkem, který drží notebook. Dokumentované režimy adaptéru stojí za to mít otevřené, když vybíráte, protože režim mění jak to, co vidí hostitel, tak to, co vidí LAN.

Příručka: umístěte, nastavte, dokažte

Spusťte tyto čtyři kontroly v pořadí v čerstvém shellu hosta a zastavte se u první, která se neshoduje s vlastníkem, kterého jste si zapsali.

1. ip route get 1.1.1.1, které vrací tun0 nebo wg0, znamená vlastnictví hosta, a eth0 se soukromým dalším skokem znamená vlastnictví hostitele.
2. resolvectl query example.com, nebo si přečtěte /etc/resolv.conf tam, kde host nespouští službu resolveru. Tunel, který nese provoz, ale ne DNS, je nejčastější napůl nastavený stav.
3. Porovnejte výstupy: curl -4 -s https://ifconfig.me v hostovi proti curl.exe -4 -s https://ifconfig.me na hostiteli. Různé adresy znamenají, že tunel vlastní host, a hostitel ve VPN s hostem, který ukazuje domácího poskytovatele, je případ, kdy se nic nedědilo.
4. Zopakujte obojí s -6. Tunel pouze pro v4 propouští v6, pokud ho klient nezablokuje nebo nesměruje, a mnoho klientů nechává v6 na fyzickém rozhraní ve výchozím stavu.

U návrhu s hostitelskou bránou, kde několik hostů sdílí jeden tunel, musí hostitel přeposílat a překládat. Na linuxovém hostiteli jsou to tři kusy a host se tiše vrátí ke své obyčejné trase, když některý chybí:

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 straně WireGuardu musí AllowedIPs hostitelského protějšku obsahovat podsíť hostů, například 192.168.122.0/24, jinak návratové pakety nikdy nedorazí a nastavení vypadá jako problém firewallu. Windows hostitel dosáhne stejného výsledku přes Sdílení připojení k internetu nebo pravidlo NAT na přepínači Hyper-V a potřebuje stejnou kontrolu zpětné cesty.

Když je uspořádání ještě otevřené, tato tabulka pokrývá nejčastější případy:

Dva tunely, dva hosté a konflikty mezi nimi

Když potřebujete dva výstupy naráz, vzor, který vydrží, je jeden tunel na hosta. Každá VM si drží svou výchozí trasu a resolver, hostitel zůstává v obyčejné síti a oba tunely se nikdy nehádají o stejnou směrovací tabulku. Propojení dvou hostů mostem také neslévá jejich trasy: virtuální síť poskytuje cestu a každému klientovi se stále musí říct, že tento místní provoz smí tunel obejít.

Spouštět tunel hostitele a tunel hosta společně je legitimní a záměrné vnoření je někdy přesně to, co chcete, přičemž host vychází svým vlastním tunelem a ten tunel vychází tunelem hostitele. Přerušením to dělá to, že nikdo nezapsal, přes kterou vrstvu se má které koncové body dosáhnout. Veďte seznam o dvou sloupcích s cílem a vlastníkem a konflikt tras se stane vyhledáváním místo odpoledne objevování.

Ověřte a pak nechte obnovu na vlastníkovi

Testujte zevnitř hosta čerstvým procesem aplikace: provoz, překlad jmen, obě rodiny adres a co se stane, když tunel spadne. Ikona VPN na hostiteli neříká nic o pokrytí hosta, a to je nejčastější falešné potvrzení v celé této oblasti.

Obnova patří také vlastníkovi. Tunel patřící hostovi se obnovuje vlastním klientem hosta a trasami, které zapsal. Návrh patřící hostiteli se obnovuje posloupností bootování hostitele a pravidla přeposílání nepřežijí restart, pokud je znovu neuplatní unit nebo úloha při spuštění. Obnovený snapshot je nasazení, ne krok zpět, protože vrací staré přihlašovací údaje a staré trasy spolu s diskem. Než práci prohlásíte za hotovou, potvrďte, že vlastník stále odpovídá řádku, který jste zapsali, že DNS a obě rodiny adres se v hostovi překládají, že mrtvý tunel nechává použitelnou síť místo černé díry a že restart nebo obnova snapshotu reprodukuje stejný stav.