Tunel działa, internetu brak: gdzie zatrzymuje się przekazywanie

Klient się łączy, tunel przenosi pingi do bramy, a nic za nią nie odpowiada. Ten stan jest normalny dla bramy, która zawsze miała zapewniać tylko dostęp do chronionych sieci, a jest usterką dla bramy reklamowanej jako wyjście pełnego tunelu. Przed zmianą reguł potwierdź, jaka usługa została obiecana. Następnie prześledź jedno publiczne żądanie przez cztery miejsca, w których może się zatrzymać. Jedno żądanie i jedno przechwycenie pakietów rozstrzygają więcej niż strona domysłów.

Potwierdź, czy wyjście do internetu kiedykolwiek było projektem

Profil tunelu dzielonego kieruje do VPN tylko chronione podsieci, więc publiczne przeglądanie odbywa się przez łącze lokalne i nigdy nie dotyka bramy. Profil pełnego tunelu instaluje w tunelu trasę domyślną, co czyni bramę odpowiedzialną za całą ścieżkę. Oba są uzasadnionymi projektami, a ich mylenie tworzy zgłoszenie usterki tam, gdzie jej nie ma. Przeczytaj trasy ogłaszane przez klienta, zanim przetestujesz cokolwiek innego, bo tabela tras odpowiada na pytanie, które zgłoszenie zwykle stawia błędnie.

To, co instaluje klient, nie zawsze jest tym, co zakłada profil. Wypchnięta trasa może zostać nadpisana przez trasę lokalną o niższej metryce, a klient, który zachowuje trasę LAN, dodając trasę domyślną, zachowuje się jak tunel dzielony dla tej podsieci.

Prześledź jedno publiczne żądanie

Wybierz jedno miejsce docelowe i prześledź je od klienta na zewnątrz. Na kliencie sprawdź, czy pakiet rzeczywiście wybiera tunel i jakiego adresu lokalnego używa jako źródła. Następnie sprawdź bramę: czy pakiet dociera i czy opuszcza interfejs publiczny. Każda z tych odpowiedzi usuwa całą kategorię przyczyn.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Jeśli brama nigdy nie widzi pakietu, trasa klienta lub wybór tunelu są błędne. Jeśli pakiet dociera i nie wychodzi, problem leży na bramie i obowiązują trzy pozostałe kontrole.

Sprawdź przekazywanie, trasę i tłumaczenie

Wskazówki dotyczące przekazywania dostarczane z strongSwanem dotyczą bramy dowolnego typu tunelu: jądro musi mieć pozwolenie na przenoszenie pakietów między interfejsami, a użyteczna trasa musi wskazywać ku internetowi. Polityka zapory musi następnie zezwalać na ruch, a adres źródłowy musi być taki, na który strona publiczna może odpowiedzieć. Prywatny adres klienta przekazany bez zmian do internetu nigdy nie otrzymuje odpowiedzi.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Tłumaczenie źródła to zwykle brakujący element. Dzięki niemu brama przepisuje źródło klienta na swój adres publiczny i śledzi przepływ; bez niego odpowiedź nie ma gdzie trafić. Platformy chmurowe dodają drugą granicę, na której tabela tras lub grupa zabezpieczeń instancji mogą odrzucić ruch dozwolony przez zaporę gościa. Tę granicę łatwo przeoczyć, bo system gościa wygląda od środka na poprawnie skonfigurowany.

Filtrowanie odwrotnej ścieżki w konfiguracji asymetrycznej również może odrzucać prawidłowe pakiety. Odczytaj licznik tej reguły, zamiast zakładać, że jest w porządku, bo rygorystyczne ustawienie na interfejsie publicznym odrzuca ruch przychodzący inną drogą niż przewiduje tabela tras.

Droga powrotna i resolver to dwie różne odpowiedzi

Obserwuj także odpowiedź, nie tylko żądanie. Jeśli żądanie wychodzi przetłumaczone, a odpowiedź wraca do przetłumaczonego przepływu, przekazywanie działa nawet wtedy, gdy aplikacja nadal zawodzi, a następne dochodzenie należy do aplikacji lub DNS.

Strona zwracająca błąd HTTP jest dowodem, że przekazywanie do internetu działa. Nazwa, której nie można rozwiązać, gdy dostęp po adresie działa, to problem resolvera, nie NAT.

Po precyzyjnej poprawce przetestuj ponownie klienta oraz każdy celowo ograniczony zasób prywatny. Udzielenie dostępu do internetu nie może po cichu rozszerzać dostępu na każdą sieć podłączoną do bramy.