VirtualBox NAT czy most: gdzie kończy się VPN maszyny wirtualnej

Dwa różne pytania pojawiają się razem za każdym razem, gdy maszyna wirtualna uruchamia klienta VPN, i mają różne odpowiedzi. Pierwsze dotyczy tego, czy tunel wewnątrz gościa chroni gospodarza, a drugie tego, czy tunel na gospodarzu obejmuje gościa. Tryb adaptera rozstrzyga oba, bardziej niż samo oprogramowanie VPN. Adapter NAT czyni gospodarza widocznym punktem końcowym, a adapter mostu umieszcza gościa w sieci z jego własnym adresem.

Kto faktycznie kończy zaszyfrowaną sesję

Zaszyfrowana sesja należy do maszyny, która ją kończy, a jest nią gość, gdy klient działa wewnątrz VM. Przez ten tunel przechodzi tylko ruch wchodzący do wirtualnego adaptera gościa, a hiperwizor nigdy sam nie kieruje innej maszyny przez gościa. Dlatego gość może utrzymywać działający tunel, gdy gospodarz przegląda otwartą sieć. Odwrotność nie jest symetryczna i właśnie ta asymetria jest częścią, którą większość poradników myli.

Czyj adres widzi sieć zewnętrzna, to pytanie, na które odpowiada tryb adaptera. Gdy to zostanie ustalone, zasięg przestaje być kwestią polityki i staje się mechaniczny. Wszystko poniżej wynika z tych dwóch faktów.

NAT przepisuje gościa, aż zacznie wyglądać jak gospodarz

Przy NAT hiperwizor przepisuje każdy pakiet gościa na adres gospodarza, zanim dotrze on do pierwszego przełącznika. Ten ruch trafia następnie do własnego stosu sieciowego gospodarza, gdzie podlega jego tablicy routingu, w tym trasie domyślnej należącej do tunelu na gospodarzu. Gość NAT jest więc objęty tunelem na gospodarzu bez żadnej konfiguracji, co jest przeciwieństwem tego, co sugeruje przypadek od gościa do gospodarza.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Gość, który uruchamia własnego klienta, kończy ten tunel wewnątrz gościa, a zaszyfrowany ruch wychodzi potem przez to samo przepisanie, więc aplikacje gospodarza zachowują własną ścieżkę i własny adres wyjściowy. VirtualBox w tym trybie odpowiada też za rozwiązywanie nazw i przekazuje zapytania gościa przez własny mechanizm, o ile --natdnshostresolver1 nie jest włączony. Włączenie go oddaje wyszukiwania gościa resolverowi gospodarza, co poprawia rozwiązywanie, gdy obraz gospodarza jest prawidłowy, i równie dobrze przekazuje resolver, który może istnieć tylko wewnątrz tunelu. VM trzeba wyłączyć przed zmianą ustawienia, a ustawienie należy do adaptera, a nie do oprogramowania gościa.

Most daje gościowi własną dzierżawę i własną ekspozycję

Most przekazuje ramki gościa do segmentu fizycznego, więc DHCP daje mu dzierżawę, a sieć traktuje go jako osobnego gospodarza. Każdy gość w moście może utrzymywać niezależny tunel z własną trasą domyślną, a tablica gospodarza nigdy się nie zmienia. Ceną jest ekspozycja: gość odpowiada na rozgłoszenia, pojawia się w tablicach sąsiadów i podlega bezpieczeństwu portów przełącznika oraz izolacji klientów bezprzewodowych. Tunel na gospodarzu też tego układu nie obejmuje, ponieważ ramki gościa nigdy nie przechodzą przez stos gospodarza.

Ta różnica wobec przypadku NAT zasługuje na powiedzenie wprost, a nie na pozostawienie jako implikacji. Gość w moście potrzebuje własnego klienta i własnych poświadczeń, ilekroć jego ruch musi korzystać z tunelu. Tam, gdzie gość ma pozostać niewidoczny dla sieci lokalnej, NAT albo sieć wyłącznie wewnętrzna z kontrolowanym routingiem jest lepszym projektem.

Dlaczego gość nie może być bramą gospodarza

Użyczenie tunelu gościa gospodarzowi nie ma obsługiwanego przełącznika w żadnym z dwóch dużych hiperwizorów. Gospodarz nie ma trasy do tunelu gościa ani reguły tłumaczenia, która by na niego wskazywała, więc ruch gościa i gospodarza pozostaje osobnymi strumieniami z osobnymi właścicielami. Ten kierunek zawodzi niezależnie od trybu adaptera.

Działające zamienniki to przekierowania i proxy. Lokalne przekierowanie SSH pozwala gospodarzowi połączyć się z własną pętlą zwrotną, podczas gdy gość niesie strumień do tunelu, co obejmuje usługi TCP bez instalowania drugiego klienta. Skłonienie własnego ruchu IP gospodarza do korzystania z tunelu gościa zamiast tego wymaga routera wewnątrz gościa oraz jawnej trasy na gospodarzu i tłumaczenia na gospodarzu. To mały projekt sieci, a nie pole wyboru, i wymaga planu drogi powrotnej. Gdy gość istnieje tylko po to, by uruchamiać klienta, umieść klienta na gospodarzu i usuń zbędny przeskok.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Resolver i trasy nie przekraczają granicy

DNS podąża za adapterem, który otrzymał opcję, więc gość nie dziedziczy resolvera tunelu gospodarza, a gospodarz nigdy nie poznaje serwera wepchniętego gościowi. Wepchnięte wartości dhcp-option DNS obowiązują dla interfejsu, który je przyjął, i dlatego gość w moście bez klienta nie potrafi rozwiązać nazw wewnętrznych. Gość NAT zwykle korzysta z obsługi DNS hiperwizora, a różnica jest widoczna w jednym poleceniu na środowisko.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Przeczytaj resolver i trasę wewnątrz gościa, zanim założysz, że któryś z nich podąża za gospodarzem. Dodaj resolver tunelu do własnego adaptera gościa, gdy nazwy wewnętrzne mają się tam rozwiązywać, a następnie sprawdź nazwą, która istnieje tylko za tunelem. Zapisz tryb adaptera, właściciela tunelu i źródło resolvera dla każdej VM, bo te trzy fakty odpowiadają na prawie każde późniejsze pytanie. Inne hiperwizory zmieniają nazwy trybów i zostawiają zasadę nietkniętą.