Dlaczego Twój VPN gościa zawodzi za NAT-em VirtualBox?

Przeglądarka w maszynie wirtualnej działa, a klient VPN na tym samym gościu nie potrafi przenosić danych. Gość wyraźnie ma łączność, więc usterka leży w tym, czego wymaga zewnętrzny protokół VPN i co przepuści wirtualny NAT. Wynik rozstrzygają trzy warunki: który proces posiada VPN, jak wygląda zewnętrzna wymiana na drucie i czy tryb adaptera jest tym, o którym myślisz. Nazwanie warunku, który możesz zmienić, to cała decyzja.

Znajdź proces VPN, zanim obwinisz sieć

Najpierw zdecyduj, czy VPN działa wewnątrz gościa, czy na hoście, bo oba układy zawodzą inaczej. Klient wewnątrz gościa buduje własne połączenie zewnętrzne przez adapter gościa i dowolne tłumaczenie za nim. VPN hosta przechwytuje ruch gościa zgodnie z polityką hosta i hipervisora, co jest osobnym punktem przechwytywania z własnymi regułami. Oba mogą działać jednocześnie i zaciemniać dowody, więc wskaż ten, który powinien przenosić ten ruch, zanim dotkniesz któregokolwiek.

Zapisz teraz tryb adaptera gościa, zanim cokolwiek zmienisz. Ta jedna wartość wyjaśnia większość tego, co następuje, i to jest pierwsza rzecz, o którą ktoś cię później zapyta.

Zewnętrzna wymiana rozstrzyga zgodność

Przewodnik sieciowy VirtualBox wymienia ograniczenia NAT, które tu mają znaczenie: nie przepuści protokołów innych niż TCP i UDP, GRE jest wymieniony jako nieobsługiwany, a PPTP podano jako dotknięty przykład. PPTP używa wymiany kontrolnej TCP i GRE dla danych, więc połączenie kontrolne może się udać, podczas gdy ścieżka danych nie może przekroczyć tej samej granicy. To dwa różne dowody, a tylko jeden z nich dotyczy przenoszenia ruchu. Zezwolenie na port TCP 47 w regule zapory nie jest tym samym co zezwolenie na protokół IP 47, i te dwa są stale mylone.

Trzymaj ograniczenie przypisane do tego układu NAT, a nie do każdego urządzenia używającego słowa NAT. Fizyczny router może bez skargi przepuścić GRE, podczas gdy wirtualny NAT go odrzuca, a inny hipervisor sam decyduje, co przekazuje. Tam, gdzie organizacja oferuje zatwierdzony transport w TCP lub UDP, użyj jej obsługiwanego klienta i profilu dla tej ścieżki. Zgodność to jeden z kilku wymogów i nie ustanawia ani zaufania do serwera, ani uprawnienia konta, ani działających tras prywatnych.

Co naprawdę zmienia most

Most przekazuje adres MAC gościa segmentowi fizycznemu zamiast ukrywać go za tłumaczeniem. Gość pobiera wtedy adres od dowolnego serwera DHCP obsługującego ten segment, odpowiada ARP na ten adres i pojawia się wobec przełącznika nadrzędnego jako kolejny port. To usuwa ścieżkę tłumaczenia wirtualnego, co jest dokładnie powodem, dla którego stary przepis to zaleca, i zmienia jednocześnie trzy inne rzeczy. Adresacja pochodzi teraz z segmentu lokalnego, a nie od hipervisora, ekspozycja oznacza, że gość jest widoczny dla tego segmentu, a dopuszczenie zależy od portu przełącznika i jego polityki. Każda z nich może być powodem odrzucenia zmiany, i żadna nie dotyczy protokołu VPN.

Mostkowanie nie instaluje brakującej wtyczki, nie dostarcza niedostępnego tajnego agenta i nie naprawia odrzucenia uwierzytelnienia. Nie czyni też przestarzałego protokołu dobrym wyborem, a tam, gdzie operator ma utrzymywany zamiennik, decyzją jest on, a nie zmiana hipervisora. Przekierowanie portu to zupełnie trzecia rola: publikuje usługę przychodzącą i nie robi nic dla zewnętrznego protokołu klienta wychodzącego.

Dwa tunele, dwa tropy dowodów

VPN gościa potrzebuje użytecznej ścieżki od interfejsu gościa do jego partnera, zanim jakikolwiek adres wewnętrzny lub trasa prywatna zacznie mieć znaczenie. Tam, gdzie jest VPN hosta, może przekazywać lub blokować tę zewnętrzną wymianę zgodnie z własną polityką, a wewnętrzny tunel gościa zaczyna się dopiero po powodzeniu zewnętrznego. Zasięgu żadnej warstwy nie da się odczytać z jednej połączonej ikony ani z publicznego adresu przeglądarki hosta.

Zachowaj pierwszy komunikat błędu, a nie ostatni, bo najwcześniejsza usterka nazywa warstwę. Zmieniaj jeden obsługiwany układ sieci naraz, z tym samym profilem gościa i tymi samymi poświadczeniami, żeby porównanie coś znaczyło. Na podstawie usterki rozstrzygnij, który etap pękł: integracja lokalna, transport, uwierzytelnienie czy dostęp do zasobów po podniesieniu tunelu. Każdy z nich ma innego właściciela, i tylko jeden jest pytaniem o hipervisor.

Który warunek naprawdę cię blokuje

Teraz decyzja zawęża się do trzech pytań o różnych odpowiedziach. Jeśli protokół zewnętrzny leży poza TCP i UDP, ograniczeniem jest tryb NAT, a drogą naprzód jest most lub zatwierdzony transport TCP/UDP. Jeśli zewnętrzna wymiana się kończy, a ścieżka danych nie, ograniczenie jest to samo co w drugim dowodzie. Jeśli tunel wstaje, a zasoby nie odpowiadają, problem już minął hipervisor i trafił do routingu lub polityki.

Zapisz odpowiedź z trybem adaptera obok, inaczej następna osoba powtórzy to samo popołudnie. Po każdej poprawce przetestuj rzeczywistą aplikację i rozwiązywanie nazw wewnątrz gościa, potem połącz się ponownie i wypróbuj politykę awarii. Działająca strona internetowa przez tunel dowodzi tylko, że ścieżka sieciowa działa, co jest mniejszym twierdzeniem, niż się wtedy wydaje.