VPN typu site-to-site działa tylko w jedną stronę: dwa różne błędy

Lokacja A dociera do B, B nie dociera do A, a tunel wygląda dobrze w obu kierunkach. Zanim dotkniesz tunelu, ustal, który błąd naprawdę masz. Nowe połączenie rozpoczęte w B i odrzucone oraz odpowiedź na połączenie rozpoczęte w A, która nigdy nie dociera, dają podobne skargi i zupełnie różne diagnozy. Jedno to problem polityki lub trasy na ścieżce; drugie to problem trasy powrotnej lub stanu dla ruchu, który już był dozwolony.

To rozróżnienie decyduje, które polecenia warto uruchomić.

Dwa błędy, które wyglądają identycznie

W pierwszym przypadku host B wysyła SYN do A i nic nie wraca. W drugim host A pomyślnie otwiera sesję, a odpowiedź znika w drodze powrotnej. Obaj użytkownicy mówią, że łącze jest jednokierunkowe, i obaj opisują pakiet, który zniknął, więc sam opis nie może ich rozdzielić.

Zapytaj, która strona rozpoczęła nieudaną próbę. Ten jeden fakt usuwa połowę możliwych przyczyn.

Następnie sprawdź, czy test przez cały czas używał tych samych hostów i tej samej usługi. Ping z jednej strony i połączenie do folderu udostępnionego z drugiej testują dwie różne rzeczy, a diagnostyka z bramy może wybrać adres tunelu, którego nie używa żaden ruch użytkownika.

Przypadek pierwszy: brak trasy powrotnej

Zdalny serwer, który odpowiada przez inną bramę domyślną, może odebrać żądanie i skierować odpowiedź gdzie indziej. Zapory ogniowe śledzące stan odrzucają wtedy asymetryczną odpowiedź, ponieważ nie pasuje ona do ustanowionego przepływu, co wygląda dokładnie jak kierunek, który nigdy nie działał. Translacja dodaje inny wariant: cel widzi przetłumaczone źródło i odpowiada na nie, więc reguła napisana dla oryginalnego adresu nigdy nie pasuje.

Sprawdź adres, który cel naprawdę widzi po translacji, oraz trasę powrotną dla tego adresu, a nie dla oryginalnej podsieci.

Przypadek drugi: polityka nigdy na to nie pozwalała

Przypadek odwrotny jest prostszy i częstszy, niż wygląda: jedno biuro ma korzystać z usługi centralnej i nigdy nie inicjować połączeń do centrum. Ta asymetria jest świadomą decyzją o dostępie, a tunel działa zgodnie z projektem. Przeczytaj politykę dostępu, zanim zmienisz jakiekolwiek ustawienie tunelu. Dokument, a nie przechwytywanie pakietów, mówi, który kierunek był zamierzony. Przechwycenie może pokazać tylko, co się stało, a nie co było dozwolone.

Jeśli dwukierunkowa inicjacja jest naprawdę konieczna, dodaj uprawnienie dla konkretnej usługi przez obsługiwany zestaw reguł platformy. Uczynienie każdej podsieci wzajemnie zaufaną, aby naprawić jedną aplikację, zamienia wąskie wymaganie w szerokie uprawnienie, a ta wymiana jest rzadko później przeglądana.

Porównaj stan przed i po na tych samych hostach

Obserwuj oba końce tej samej próby, a nie dwie osobne próby. Przechwytuj na bramie hosta, który inicjuje, i na celu, a następnie porównaj, co weszło, co wyszło i jaki adres widziała druga strona.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Jeśli przechwycenie na celu pokazuje żądanie z nieoczekiwanym adresem źródłowym, odpowiedź leży w translacji lub trasowaniu, a nie w polityce bezpieczeństwa tunelu. Jeśli cel nie pokazuje żadnego żądania, pakiet nigdy nie przeszedł chronionej ścieżki.

Po poprawce powtórz ten sam test z tego samego hosta i potwierdź, że niepowiązany dostęp nadal jest odmawiany. Stan tunelu “established” sam nie potwierdza żadnego z dwóch wniosków.