Brama VPN potrzebuje przekazywania IP: co sprawdzić

Twój klient może pingować adres bramy, podczas gdy wszystkie zasoby za nią pozostają nieosiągalne. Ta para obserwacji opisuje hosta, który z tobą rozmawia, i router, który nie routuje, czyli różne role na tej samej maszynie. Przekazywanie to przełącznik między nimi.

Obie role są niezależne, podobnie jak obie rodziny adresów.

Odpowiedź na własny adres niczego nie dowodzi

Gdy pakiet jest zaadresowany do samej bramy, lokalny stos go zużywa i nie zapada żadna decyzja o przekazaniu. Dlatego udany ping na adres tunelu lub interfejs zarządzania mówi ci, że demon żyje, a tunel jest podniesiony, ale nic nie mówi o ruchu przeznaczonym dla sieci za pudełkiem. Jądro sprawdza swoją ścieżkę przekazywania tylko dla pakietów, które nie są zaadresowane do niego.

Czytaj wymaganie jako rolę, a nie ustawienie: ten host musi przenosić pakiety między dwoma interfejsami. Laptop, który musi tylko dotrzeć do sieci zdalnej, nigdy nie przyjmuje tej roli, a punkt końcowy typu site-to-site zawsze ją przyjmuje. Takie czytanie wymagania wyjaśnia, dlaczego działająca konfiguracja klienta zawodzi po przeniesieniu na bramę.

To samo zdanie dotyczy zapory przed decyzją o przekazaniu, która ma własną politykę co do tego, co wolno przekazywać.

Sprawdź każdą rodzinę adresów osobno

Przekazywanie IPv4 to jeden przełącznik, a przekazywanie IPv6 to inny, z własnym zachowaniem na każdym interfejsie. Włączenie pierwszego nic nie mówi o drugim, a klient z dwoma stosami może dotrzeć do połowy sieci, podczas gdy reszta pozostaje ciemna. Dwa klienty różnych rodzin mogą więc nie zgadzać się co do tej samej bramy. Zapytaj, której rodziny użył zawodzący klient, zanim zmienisz którekolwiek ustawienie. Potwierdź oba, zanim uznasz, że projekt routingu jest błędny.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

W wielu dystrybucjach wartość czytana w czasie działania została tam umieszczona przez usługę lub plik konfiguracyjny, więc zmiana wykonana jednorazowym poleceniem może zniknąć przy ponownym uruchomieniu. Znajdź plik, który jest właścicielem ustawienia, zanim zmienisz wartość czasu działania.

Przekazywanie jest jednym z czterech wymagań

Działający przepływ przekazywany potrzebuje naraz czterech rzeczy: klient musi wiedzieć, że cel jest za tunelem, brama musi mieć trasę dalej, odpowiedzi muszą mieć drogę powrotną, a zapora musi zezwalać na ruch. Translacja źródła należy do tego projektu jako opcja, a nie reguła, bo prywatna sieć routowana o symetrycznych ścieżkach jej nie potrzebuje, a asymetryczna zwykle potrzebuje. Każde z czterech zawodzi niezależnie, dlatego naprawa jednego rzadko przesuwa objaw. Zapisz wszystkie cztery, zanim zmienisz którekolwiek.

Platformy chmurowe dodają piąte rozważanie. Niektóre wymuszają kontrole źródła i celu na instancjach, co odrzuca przekazywane pakiety niezależnie od tego, jak skonfigurowane jest jądro gościa. Autorytetem jest tam własna dokumentacja sieciowa platformy, a nie wynik sysctl wewnątrz VM.

Testuj z klienta, nie z bramy

Test uruchomiony w powłoce samej bramy nie przechodzi przez żadną część właśnie włączonej ścieżki przekazywania. Generuj ruch z klienta, który ma problem, i potwierdź, że dociera do czegoś za bramą, a nie do samej bramy. To jedyny test, który ćwiczy zmienioną rolę.

Trzymaj reguły nasłuchu i reguły przekazywania osobno w głowie i w rejestrze zmian. Otwarcie portu VPN wpuszcza klientów do usługi; nie daje im nic w sieci za nią, a oba wyglądają identycznie na liście zapory, która rosła latami.

Jeśli pakiety docierają, a usługa odrzuca użytkownika, wyszedłeś poza sieć. Kontynuuj autoryzacją aplikacji zamiast ponownie rozszerzać politykę przekazywania.