VPN w gościu i VPN na hoście: która trasa naprawdę wygrywa

Dwaj klienci działają jednocześnie, każdy przekonany, że posiada trasę domyślną, a objaw pojawia się jako coś dziwnego: jedna aplikacja gościa działa, inna rozwiązuje się w złym miejscu. VPN wewnątrz gościa i VPN na hoście mogą współistnieć, ale tylko wtedy, gdy zewnętrzna ścieżka i wewnętrzna polityka zgadzają się co do tego, kto co niesie. Uruchomienie obu nie tworzy łańcucha samo w sobie. Najpierw zapisz podłączenie, potem zmieniaj jedną rzecz naraz.

Najpierw zapisz podłączenie gościa

Gość dociera do swojego serwera VPN ścieżką, którą dał mu hipervisor: NAT za hostem, most do segmentu fizycznego albo sieć tylko dla hosta z routingiem dodanym na wierzchu. Każde podłączenie zmienia to, co gość widzi i co host może zrobić z jego ruchem. Pod NAT pakiety gościa wyglądają, jakby przychodziły z hosta, więc własny tunel hosta może je nieść, a gość nic o tym nie wie. Pod mostem gość ma własną obecność w segmencie i własną bramę domyślną.

Zapisz podłączenie, zanim dotkniesz jakiejkolwiek konfiguracji, wraz z tym, który klient ma nieść którą aplikację. To zdanie rozwiązuje większość takich przypadków, bo obaj klienci są zwykle zbudowani na różnych założeniach. Gość, od którego oczekuje się użycia tunelu hosta, nie może mieć też własnej konkurencyjnej trasy domyślnej.

Prześledź punkt końcowy gościa na zewnątrz

VPN gościa potrzebuje użytecznej ścieżki do własnego serwera, zanim cokolwiek innego zacznie działać. Gdy tunel hosta jest włączony, a gość siedzi za NAT, uścisk dłoni gościa wychodzi przez tunel hosta, co jest albo zamierzone, albo jest wypadkiem, którego nikt nie udokumentował. Gdy tunel hosta padnie, a gość od niego zależał, gość traci łączność bez ani jednej zmiany po swojej stronie. Prześledzenie punktu końcowego na zewnątrz mówi, który z tych dwóch przypadków naprawdę masz.

Szeroka trasa w obu kontekstach przechwytuje ruch, którego oczekiwał drugi klient. Trasa 0.0.0.0/0 wewnątrz gościa i klient hosta z pełnym tunelem oba roszczą sobie wszystko, a wygrywa ta, która obowiązuje ostatnia. Nakładanie się sieci wirtualnych gościa, lokalnego LAN-u i sieci zdalnych daje ten sam efekt dla prefiksów prywatnych, z awariami przypominającymi problemy z uwierzytelnianiem; zachowanie tłumaczenia adresów jest takie samo, jak opisane dla sieci kontenerów.

Porównaj zapis przed i po

Zrób punkt odniesienia z wyłączonym tunelem hosta albo w dowolnym kontrolowanym stanie, na który pozwala twoja polityka, i zapisz trasę i resolver gościa. Następnie zastosuj konfigurację łączoną i porównaj oba zapisy, zachowując wymagania prywatności. Jeśli bezpośredni punkt odniesienia nie jest odpowiedni, zapisz to ograniczenie w zapisie zamiast pomijać porównanie.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Zapytanie o trasę wskazuje interfejs i adres źródłowy, które niosłyby konkretny cel, i jest to najbardziej użyteczna linia w tym dochodzeniu. Lista reguł pokazuje, czy routing oparty na polityce wysyła niektóre cele przez drugą tabelę. Wynik resolvera pokazuje, czy DNS podążał za tunelem gościa, czy pozostał na ścieżce hosta. Uruchom te same trzy polecenia przed zmianą i po niej, a różnica wskaże winnego.

Utrzymuj własność jasną między restartami

Ograniczenie dostępu lokalnego klienta hosta może blokować ruch do wirtualnego NAT lub mostu, a to ograniczenie bywa mylone z problemem danych logowania gościa. Czytaj udokumentowane zachowanie klienta, zamiast wyłączać ograniczenie, żeby test przeszedł. Po obsługiwanej poprawce przetestuj ponownie aplikację gościa i wymaganą politykę awarii. Host, który skutecznie łączy się ponownie, niczego nie dowodzi o trasie ani resolverze gościa.

Zdecyduj, która strona posiada trasę domyślną, i zapisz to w instrukcji operacyjnej. Restart gościa albo zmiana sieci na hoście, która po cichu odwraca własność, tworzy zgłoszenie błędu o VPN, który nigdy nie był winny. Układ powinien przetrwać restart, choć nikt nie pamięta, dlaczego działał.