VPN na hoście czy wewnątrz VM? Przewodnik decyzyjny

Zbudowanie tunelu wewnątrz gościa i zbudowanie go na hoście oba zmieniają adres, który raportuje przeglądarka, i tam kończy się podobieństwo. Tunel należący do gościa trzyma swoje klucze, swoją trasę domyślną i swój resolver w jądrze gościa, podczas gdy host przekazuje zaszyfrowane pakiety na jeden adres zdalny. Tunel należący do hosta jest obrazem lustrzanym: klient hosta trzyma sesję i stosuje trasy oraz politykę, a gość pożycza to, co wychodzi. Wybierzesz niewłaściwego właściciela, a każdy późniejszy objaw wyśle cię do niewłaściwej maszyny. Dwie komendy rozstrzygają kwestię w około minutę, a reszta tego przewodnika to, co zrobić z odpowiedzią.

Ustal właściciela, zanim dotkniesz klienta

Reguła dotyczy tego, gdzie powstaje szyfrogram, a nie tego, która maszyna pokazuje ikonę VPN. Jeśli wytwarza go gość, gość potrzebuje działającej trasy do serwera VPN i niczego więcej od hosta. Jeśli wytwarza go host, gość potrzebuje, aby ścieżka przez hosta przetrwała dowolną politykę, którą klient hosta narzuca ruchowi lokalnemu.

Trzy pytania zwykle wybierają umiejscowienie za ciebie. Czy ruch gościa musi przetrwać klienta korporacyjnego na hoście? Wtedy tunel należy do gościa. Czy kilka gości potrzebuje jednego poświadczenia i jednego adresu wyjścia? Wtedy należy do hosta, z przekazywaniem skonfigurowanym celowo. Czy ruch gościa ma pozostać całkowicie poza VPN hosta? Wtedy tunel w gościu jest jedynym układem, który daje to z samej konstrukcji.

Zapisz odpowiedź w jednej linijce obok nazwy VM: guest-owned albo host-owned. W laboratorium sześciu maszyn ta notatka oszczędza więcej czasu niż każdy krok poniżej, bo powstrzymuje cię przed diagnozowaniem tunelu, którego nigdy nie było w maszynie, na którą się zalogowałeś.

WSL1 i WSL2 to przypadki przeciwne

WSL1 nie jest maszyną wirtualną, więc kwestia umiejscowienia w większości ulatnia się. Jego pliki binarne Linuksa działają przeciwko stosowi sieciowemu Windows przez warstwę tłumaczenia, a klient VPN dla Linuksa nie ma niezależnych interfejsów do skonfigurowania. Działa układ z tunelem po stronie Windows, a dystrybucja używa wyniku, niczego nie posiadając.

WSL2 jest odwrotnie. Uruchamia prawdziwe jądro w lekkiej VM pomocniczej za wirtualnym przełącznikiem Hyper-V, a jego przestrzeń adresowa jest tłumaczona przez NAT przez adapter po stronie hosta. Dlatego klient Linuksa wewnątrz dystrybucji zachowuje się jak na fizycznym pudełku z Linuksem: tworzy tun0 albo wg0, instaluje własne trasy i działa. Awaria mieszka po stronie hosta. Gdy klient VPN dla Windows łączy się z polityką blokującą ruch w sieciach lokalnych, traktuje podsieć WSL2 jako niezaufaną sieć lokalną i przecina ścieżkę NAT. Dystrybucja traci wtedy DNS i dostęp wychodzący, podczas gdy jej własny tunel jest nadal zdrowy: wg show raportuje uścisk dłoni, ip route wygląda poprawnie, a curl wisi.

Którą poprawkę możesz zastosować, zależy od kompilacji Windows. Starsza to wyjątek w kliencie hosta dla podsieci WSL, dodawany w ustawieniach sieci lokalnej albo tunelu dzielonego klienta. Nowsza, w kompilacjach Windows 11, które ją obsługują, to sieć lustrzana: umieść networkingMode=mirrored w sekcji [wsl2] pliku %UserProfile%\.wslconfig, uruchom wsl --shutdown, a dystrybucja będzie współdzielić interfejsy hosta zamiast prywatnej podsieci NAT. Tryb lustrzany zmienia też zachowanie localhost i portów przychodzących, więc traktuj go jako migrację, a nie przełącznik.

NAT, most i co host może zobaczyć

Pod NAT pakiety tunelu gościa są adresowane na publiczny adres serwera VPN i wychodzą przez adapter hosta jako zaszyfrowany UDP albo TCP. Host widzi jeden strumień i liczbę jego bajtów, nic o celach w środku. Pod adapterem mostkowym gość ma własną tożsamość warstwy 2 w fizycznej sieci LAN, bierze własny leasing DHCP i dla każdej polityki opartej na MAC wygląda jak drugie urządzenie. Żaden tryb nie pozwala hostowi czytać ładunku tunelu; gość mostkowany jest po prostu znacznie bardziej widoczny dla sieci wokół niego.

Izolacja też ma dolną granicę. Gość nie może ukryć się przed maszyną, do której należy jego pamięć, a kto kontroluje hosta, może czytać klucze z pamięci RAM gościa. Tunel w gościu daje granicę routingu i granicę malware, a nie ochronę przed osobą trzymającą laptop. Udokumentowane tryby adaptera warto mieć otwarte podczas wyboru, bo tryb zmienia zarówno to, co widzi host, jak i to, co widzi sieć LAN.

Przewodnik: umieść, skonfiguruj, udowodnij

Wykonaj te cztery kontrole po kolei w świeżej powłoce gościa i zatrzymaj się na pierwszej, która nie zgadza się z zapisanym właścicielem.

1. ip route get 1.1.1.1 zwracające tun0 albo wg0 oznacza własność gościa, a eth0 z prywatnym następnym skokiem oznacza własność hosta.
2. resolvectl query example.com, albo przeczytaj /etc/resolv.conf tam, gdzie gość nie uruchamia żadnej usługi resolvera. Tunel, który niesie ruch, ale nie DNS, to najczęstszy na wpół skonfigurowany stan.
3. Porównaj wyjścia: curl -4 -s https://ifconfig.me w gościu wobec curl.exe -4 -s https://ifconfig.me na hoście. Różne adresy oznaczają, że gość posiada tunel, a host w VPN z gościem pokazującym dostawcę domowego to przypadek, w którym nic nie zostało odziedziczone.
4. Powtórz oba z -6. Tunel tylko v4 wycieka v6, chyba że klient go blokuje lub trasuje, a wiele klientów domyślnie zostawia v6 na interfejsie fizycznym.

W projekcie z bramą na hoście, gdzie kilka gości dzieli jeden tunel, host musi przekazywać i tłumaczyć. Na hoście Linuksa to trzy części, a gość po cichu wraca do swojej zwykłej trasy, gdy którejś brakuje:

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

Po stronie WireGuard AllowedIPs partnera hosta musi obejmować podsieć gości, na przykład 192.168.122.0/24, inaczej pakiety powrotne nigdy nie dotrą, a konfiguracja wygląda jak problem z zaporą sieciową. Host Windows osiąga ten sam wynik przez Udostępnianie połączenia internetowego albo regułę NAT na przełączniku Hyper-V i potrzebuje tej samej kontroli ścieżki powrotnej.

Gdy układ jest jeszcze otwarty, ta tabela obejmuje najczęstsze rozwiązania:

Dwa tunele, dwa goście i konflikty między nimi

Gdy potrzebujesz dwóch wyjść naraz, wzorem, który się trzyma, jest jeden tunel na gościa. Każda VM zachowuje własną trasę domyślną i resolver, host zostaje w zwykłej sieci, a dwa tunele nigdy nie kłócą się o tę samą tablicę routingu. Mostkowanie dwóch gości też nie łączy ich tras: sieć wirtualna daje ścieżkę, a każdemu klientowi nadal trzeba powiedzieć, że ten ruch lokalny może ominąć tunel.

Uruchamianie tunelu hosta i tunelu gościa razem jest legalne, a celowe zagnieżdżanie bywa dokładnie tym, czego chcesz, gdy gość wychodzi przez własny tunel, a ten tunel wychodzi przez tunel hosta. W awarię zamienia to to, że nikt nie zapisał, który punkt końcowy przez którą warstwę ma być osiągnięty. Prowadź dwukolumnową listę z celem i właścicielem, a konflikt tras staje się wyszukiwaniem zamiast popołudnia odkrywania.

Zweryfikuj, a potem zostaw odtwarzanie właścicielowi

Przetestuj od środka gościa świeżym procesem aplikacji: ruch, rozwiązywanie nazw, obie rodziny adresów i to, co się dzieje, gdy tunel pada. Ikona VPN hosta nic nie mówi o pokryciu gościa, i to jest najczęstsze fałszywe potwierdzenie w całej tej dziedzinie.

Odtwarzanie również należy do właściciela. Tunel należący do gościa odtwarza własny klient gościa i trasy, które zapisał. Projekt należący do hosta odtwarza sekwencja rozruchu hosta, a reguły przekazywania nie przetrwają restartu, chyba że unit albo zadanie startowe zastosuje je ponownie. Przywrócona migawka to wdrożenie, a nie cofnięcie, bo przywraca stare poświadczenia i stare trasy razem z dyskiem. Zanim uznasz pracę za skończoną, potwierdź, że właściciel nadal odpowiada zapisanej linijce, że DNS i obie rodziny adresów rozwiązują się wewnątrz gościa, że martwy tunel zostawia użyteczną sieć zamiast czarnej dziury, i że restart albo przywrócenie migawki odtwarza ten sam stan.