Dlaczego serwer za klientem VPN odpowiada przez tunel

Połączenia przychodzące do hosta, na którym działa też klient VPN, zawodzą w bardzo specyficzny sposób: uzgadnianie dociera, demon odpowiada, a klient nie otrzymuje nic z powrotem. Nic nie blokuje portu. Odpowiedź wyszła przez tunel, ponieważ tunel posiada trasę domyślną, a jądro trasuje odpowiedzi według celu, nie według pamięci o tym, skąd przyszło żądanie. To jedno pominięcie wyjaśnia każdy kolejny objaw.

Odpowiedź jest trasowana, nie pamiętana

Klient VPN, który instaluje trasę domyślną, dodaje wpis przewyższający bramę LAN, albo metryką, albo dzieląc przestrzeń na dwie dokładniejsze połowy. Pakiety wychodzące wybierają teraz interfejs tunelu. Jądro nigdy nie pyta, skąd pierwotnie dotarł pakiet, na który odpowiada. To jedno pominięcie wyjaśnia każdy kolejny objaw.

Kierunek w przód jest trasowany według celu, a kierunek powrotny też. Odpowiedź jest adresowana do publicznego klienta, którego tunel chętnie przeniesie. Drugi koniec otrzymuje pakiet, którego źródła nie posiada, odrzuca go, a pierwotny klient czeka, aż upłynie czas.

Ścisłe filtrowanie ścieżki powrotnej może odrzucić pakiet przychodzący, zanim demon go w ogóle przeczyta. Sprawdź najpierw ten licznik, bo odrzucenie przez filtr i błąd routingu wyglądają z zewnątrz identycznie.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Pierwsze polecenie pokazuje, która trasa domyślna teraz wygrywa. Drugie informuje, czy ścisłe filtrowanie obowiązuje globalnie czy na interfejs, a trzecie pokazuje dowolną regułę łańcucha przekazywania, która może być zaangażowana.

Trzy sposoby zachowania ścieżki powrotnej

Wyłączenie celu usługi z tunelu to najwęższa opcja. Trasa hosta wskazująca bramę LAN plus demon przypisany do adresu fizycznego, a nie do każdego adresu, trzyma ten jeden przepływ poza tunelem. Zmiana jest lokalna i łatwa do cofnięcia.

Routing polityczny to ogólna odpowiedź. Reguła oparta na adresie źródłowym lub na znaczniku zapory wybiera tablicę, której trasa domyślna wskazuje bramę WAN, podczas gdy własne połączenia hosta nadal korzystają z tunelu. Utrzymuj priorytet jawnie, aby reguła nie została później przesłonięta.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Dwa pierwsze polecenia budują alternatywną ścieżkę dla odpowiedzi pochodzących z adresu publicznego. Trzecie pyta jądro, którą ścieżką poszłyby dokładnie to źródło i cel, i tak potwierdzasz, że reguła ma jakikolwiek skutek.

Tłumaczenie źródła to trzecia opcja i jedyna, która przetrwa router wykonujący już NAT przed usługą. Odpowiedź musi wrócić do tego routera, a maskowanie na interfejs WAN to osiąga, ukrywając klienta w logach usługi. Ręczna zamiana trasy domyślnej po połączeniu to diagnostyka, bo klient przepisuje tablicę przy następnym połączeniu.

Gdy maszyna trasuje także dla LAN

Ten sam błąd pojawia się o jeden skok dalej, gdy host trasuje dla urządzeń za sobą. Połączenie przychodzące jest przekazywane do urządzenia wewnętrznego, którego jedyną ścieżką powrotną jest tunel, a odpowiedź dociera do zewnętrznego klienta z adresu dostawcy. Urządzenie wewnętrzne przez cały czas działa poprawnie.

Śledzenie połączeń widzi wtedy odpowiedź dla strumienia, którego nigdy nie zarejestrowało, i odrzuca ją. Tłumaczenie celu dostarcza połączenie przychodzące do urządzenia, a tłumaczenie źródła sprawia, że odpowiedź wygląda, jakby pochodziła z samego routera.

Trasa polityczna, która utrzymuje przekierowany port w WAN, podczas gdy własny ruch routera korzysta z tunelu, jest czystszym odpowiednikiem. Bez tłumaczenia źródła odpowiedź jest adresowana do zewnętrznego klienta, a urządzenie wewnętrzne nie ma żadnej trasy do tego adresu.

Trzy sondy, które rozdzielają przyczyny

Wykonaj trzy sondy: połączenie do maszyny z internetu, połączenie z niej do publicznego hosta i wyszukanie nazwy. Gdy pierwsze dwie się różnią, winna jest ścieżka powrotna. Gdy nazwy zawodzą w obu kierunkach, resolver jest inną usterką, która tylko dzieli tunel.

Najpierw napraw kwestię routingu, potem patrz na nazwy. Mieszanie obu to sposób, w jaki działający serwer jest obwiniany za zepsuty resolver.

Zapisz, który interfejs wymienia wyjątek, i trzymaj konfigurację pod kontrolą wersji. Reguła napisana wobec interfejsu, który po aktualizacji zostaje przemianowany, przechodzi dziś, a zawodzi po następnym restarcie.