VPN między lokalizacjami: który kierunek naprawdę wymaga reguły?

Oba końce zgłaszają zestawiony tunel, zdalna filia odpowiada z bramy, a aplikacja nadal przekracza limit czasu u użytkowników po jednej stronie. Zwykła rada mówi, aby dodać regułę zapory w obu kierunkach. Czasem to słuszne, czasem duplikuje regułę, która już istnieje, a czasem to druga reguła psuje stan. Który przypadek zachodzi, zależy od tego, gdzie zapora widzi pakiet.

Stanowy ruch powrotny zmienia liczbę

Zapora stanowa rejestruje żądanie i przepuszcza odpowiedź bez drugiej reguły, więc projekt wymagający tylko jednej reguły jest normalny. Lista dostępu bezstanowa nie ma takiej pamięci, a odpowiedź musi być dozwolona jawnie. Oba rozwiązania są poprawne na swojej platformie, dlatego porady się wykluczają.

Przeczytaj dokumentację przekazywania dla platformy przed sobą i sprawdź, czy edytowana polityka jest stanowa tam, gdzie widzi pakiet. Jawne odrzucenie dla ruchu zestawionego albo kolejność reguł, która ocenia odpowiedź przed tablicą stanów, zamienia działający projekt w zagadkę. Liczba reguł to szczegół implementacji, a wymaganiem jest, aby oba kierunki dozwolonej rozmowy mogły się zakończyć.

Gdzie zapora widzi odszyfrowane pakiety

W tunelu opartym na politykach zapora może oceniać pakiet zaszyfrowany przed odszyfrowaniem i pakiet odszyfrowany po nim, na różnych interfejsach. Reguła napisana dla niewłaściwego interfejsu istnieje, jest poprawna i nigdy nie pasuje. Tak zestaw reguł skopiowany z działającego wdrożenia może zawieść na identycznym sprzęcie.

IPsec oparty na trasach i większość nowoczesnych implementacji udostępnia interfejs tunelu, więc odszyfrowany pakiet trafia tam i obowiązują zwykłe reguły interfejsu. Potwierdź, którego modelu używa wdrożenie, zanim skopiujesz zestaw reguł z przewodnika napisanego dla drugiego. Interfejs tunelu to także miejsce, w które się patrzy, gdy trzeba wiedzieć, czy pakiet w ogóle został odszyfrowany.

Asymetryczny routing łamie założenie

Zapora stanowa zakłada, że widzi obie połowy rozmowy. Jeśli odpowiedź wraca przez inną bramę, to urządzenie nie ma stanu dla żądania i odrzuca je zgodnie z własną polityką. Objawem jest jednokierunkowa awaria, której żadna reguła po stronie wysyłającej nie naprawi. Prześledź ścieżkę odpowiedzi zanim cokolwiek zmienisz.

Sprawdź trasę odpowiedzi, zanim dodasz szeroką regułę zezwolenia po obu stronach. Tolerowanie wszystkiego na każdym interfejsie ukrywa błąd routingu i jednocześnie poszerza dostęp, co jest najgorszym dostępnym połączeniem.

Sprawdź oba kierunki z rzeczywistymi adresami źródłowymi

Testuj z adresem, który strona zdalna naprawdę widzi, ponieważ translacja może sprawić, że reguła źródłowa nie będzie pasować do niczego. Uruchom przechwytywanie na obu bramach jednocześnie.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Żądanie, które pojawia się na zdalnej bramie z nieoczekiwanym adresem źródłowym, wyjaśnia regułę, która nigdy nie pasuje, a odpowiedź docierająca na niewłaściwy interfejs wyjaśnia niezgodność stanu. Następnie przetestuj jeden cel w zatwierdzonym zakresie i jeden poza nim, aby granica została pokazana, a nie założona.

Zapisz adres źródłowy po translacji, interfejs użyty przez odszyfrowany pakiet i regułę, która pasowała. Te trzy fakty odpowiadają na następne zgłoszenie bez powtarzania całego dochodzenia.