strongSwan ESP-in-UDP: gdy nie ma czego wykrywać przez NAT

Wykrywanie NAT znajduje tłumaczenie adresów, a nie politykę firewalla. Połączenie lokacji bez NAT nadal może wymagać jawnego wyboru ESP-in-UDP.

Wykrywanie NAT odpowiada na jedno pytanie: czy adresy lub porty zmieniły się po drodze? Nie odpowiada, czy firewall zezwala na protokół IP 50. Bramy lokacji bez jakiegokolwiek tłumaczenia nadal mogą stać za polityką, która odrzuca native ESP, i ten wymóg trzeba skonfigurować, a nie wykryć. Mechanizmem jest ESP-in-UDP i to decyzja, a nie rezerwowy wariant, który pojawia się sam.

Wykrywanie to arytmetyka na adresach, nie sondowanie firewalla

IKEv2 przenosi ładunki wykrywania NAT zawierające skróty adresów i portów źródła oraz celu. Każda strona porównuje to, co otrzymała, z tym, co widzi lokalnie, a niezgodność mówi jej, że coś przetłumaczyło pakiet. Nic w tej wymianie nie sprawdza, czy router pośrodku przekazuje protokół 50.

Warto powiedzieć wprost praktyczny skutek. Tunel, który działał z native ESP, sam nie wykryje nowego restrykcyjnego firewalla, a jego następna próba zawiedzie na etapie danych, podczas gdy IKE nadal będzie się udawać. Zobaczysz ustanowione asocjacje bezpieczeństwa IKE i brak chronionego ruchu, co wygląda jak błąd routingu, dopóki nie przechwycisz na drucie.

Enkapsulacja jest więc cechą połączenia, które konfigurujesz, a nie wynikiem wynegocjowanym przez strony z zachowania sieci.

Jak encap zmienia wymianę

We współczesnym wdrożeniu strongSwan zarządzanym przez swanctl.conf, ustawienie encap = yes na połączeniu wpływa na wymianę wykrywania NAT tak, że obie strony używają enkapsulacji UDP dla ESP. Chronione pakiety podróżują wtedy wewnątrz UDP, zwykle na porcie 4500, a oba końce muszą się zgodzić na ten układ.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Ten fragment należy do prawdziwej definicji połączenia i nie jest pełnym profilem lokacji. Zachowaj adresy peera, uwierzytelnianie i selektory ruchu child, które już uruchamiasz; jedyny dodany klucz zmienia sposób pakowania chronionych danych, a nie to, co chronią.

Przewodnik strongSwan po NAT-traversal opisuje to zachowanie, w tym interakcję z pływającym portem, gdy używany jest MOBIKE.

Użyj ustawienia, które należy do twojego backendu

strongSwan ma dwa backendy konfiguracji, a klucz różni się między nimi. swanctl.conf połączenie przyjmuje encap, podczas gdy starsze ipsec.conf połączenie przyjmuje forceencaps. Wrzucenie słowa kluczowego jednego backendu do drugiego daje konfigurację, która ładuje się bez skargi i niczego nie zmienia, co jest gorsze niż błąd.

Sprawdź, który demon naprawdę działa, zanim cokolwiek edytujesz. W wielu dystrybucjach istnieją oba pliki, bo jeden jest pozostałością po wcześniejszej migracji, a aktywny to ten, który uruchamia jednostka usługi. Czytaj tę jednostkę, zamiast zgadywać ze znaczników czasu plików. Pięć sekund sprawdzenia tutaj oszczędza godziny testowania ustawienia, którego nic nie załadowało.

Zastosuj zmianę przez właściciela połączenia i odtwórz asocjację w kontrolowanym oknie. Już zainstalowany child zachowuje bieżącą enkapsulację, dopóki nie zostanie zastąpiony, więc sama edycja pliku nie dowodzi, że nowy układ jest w użyciu.

Sprawdź opakowane dane, nie tylko port

Przechwyć na bramie, gdy płynie chroniony ruch, a następnie porównaj to z własnym widokiem strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP pojawia się jako protokół IP 50 i wcale nie przypomina UDP. Opakowany ESP pojawia się jako datagramy UDP na 4500, których ładunek nie jest IKE. Ruch IKE na tym samym porcie nie jest dowodem enkapsulacji, bo MOBIKE może przenieść tam IKE, podczas gdy ścieżka danych pozostaje native, więc czytaj ładunek, a nie numer portu.

Miej też na uwadze MTU ścieżki. Otoczka dodaje narzut, a ścieżka, która niosła native ESP, może wymagać korekt, gdy pakiety rosną. Wymagana obsługa ICMP powinna już być częścią projektu; enkapsulacja nie usuwa tej zależności.

Zaakceptuj zmianę, gdy świeży ruch aplikacji w tunelu jest widoczny w przechwyceniu jako opakowany ESP po obu stronach i gdy usługa wewnętrzna oraz jej trasa powrotna nadal działają. Cokolwiek mniej to konfiguracja, która wygląda poprawnie w pliku.

Powiązane artykuły