Czy Twoja VM korzysta z VPN hosta? Sprawdź to wewnątrz gościa

Sprawdzasz publiczny adres IP hosta, widać na nim VPN, i wnioskujesz, że VM jest objęta ochroną. Ten wniosek nie jest poparty tym testem. Gość ma własną tablicę routingu, własny resolver i własne interfejsy, a adres wyjściowy hosta nic o nich nie mówi.

Test musi być wykonany wewnątrz gościa i musi nazywać to, co zmierzył.

Zacznij wewnątrz gościa, a nie w przeglądarce hosta

Najpierw zapisz tryb sieci hiperwizora: NAT, bridged, host-only lub macvtap. W trybie NAT host routuje ruch gościa, więc tunel hosta może mieć zastosowanie albo nie, w zależności od tego, jak klient instaluje trasy. W trybie bridged gość jest równorzędnym uczestnikiem fizycznej sieci LAN, a tunel hosta nie ma znaczenia. Te dwa tryby dają przeciwne odpowiedzi przy tej samej konfiguracji hosta.

Zapisz tryb, zanim cokolwiek zmienisz, bo to on decyduje, co może oznaczać wynik.

Wyślij jedno żądanie, którego cel znasz

Użyj nieszkodliwego żądania do usługi, która raportuje adres źródłowy, jaki zobaczyła. Następnie sprawdź własną decyzję routingu gościa dla tego celu: ip route get 203.0.113.5 wypisuje interfejs i bramę, których użyje gość.

Jeśli interfejsem jest zwykła karta NIC gościa, ruch nie przechodzi przez tunel wewnątrz gościa.

Drugi adapter, ustawienie proxy lub klient VPN po stronie gościa może zmienić odpowiedź dla jednej aplikacji, a nie dla innej. Testuj aplikację, na której naprawdę ci zależy, a nie ogólne żądanie z powłoki.

Sprawdź resolver osobno

Zmieniony adres wyjściowy nie mówi, który resolver obsłużył tę nazwę hosta. Zapytaj o nazwę wprost narzędziem odpowiednim dla platformy i zanotuj, który serwer odpowiedział. Split DNS oznacza, że pytanie o resolver i pytanie o routing mają różne odpowiedzi.

Te dwa mogą się rozchodzić w obu kierunkach, a ta rozbieżność jest często prawdziwym błędem.

Na hoście z systemd resolvectl query nazywa interfejs i serwer DNS stojący za odpowiedzią. Starsze konfiguracje pokazują serwer w danych wyjściowych dig. W każdym razie chodzi o to, aby zobaczyć, który serwer odpowiedział, a nie tylko czy odpowiedź przyszła.

Testuj politykę awaryjną, nie tylko sukces

Jeśli wymaganiem jest, aby żaden ruch nie wychodził poza tunel, udane żądanie niczego nie dowodzi. Użyj obsługiwanego przez klienta kontrolowanego testu awarii: zatrzymaj tunel w obsługiwany sposób i sprawdź, czy nowe żądanie gościa jest blokowane. Nie zakładaj, że kill switch klienta hosta obejmuje każdy wirtualny układ przekazywania. Jego udokumentowany zakres to jedyna rzecz, na której możesz polegać.

Gość, który po utracie tunelu wraca do fizycznej karty NIC, robi dokładnie to, na co pozwala tryb NAT.

Zapisz tryb i zakres

Zapisz tryb hiperwizora, interfejs i trasę gościa, resolver oraz testowaną aplikację. Dodaj datę, bo przywrócenie snapshotu lub aktualizacja hiperwizora mogą zmienić wszystkie cztery.

Jeśli IPv4 szedł przez tunel, powiedz to. Nie rozszerzaj twierdzenia na IPv6, inną przestrzeń nazw ani inną VM w innej sieci.