ESP to protokół IP 50, a nie port TCP 50: co należy dopuścić

Formularze zapory sieciowej pytają o port TCP, a oczywisty wpis to 50. Ten wpis niczego nie dopuszcza, ponieważ ESP to protokół IP numer 50, a numery protokołów nie są portami. Obie przestrzenie nazw dzielą tylko małe liczby całkowite i nic więcej, a błąd pozostaje niewidoczny, dopóki IKE się nie zakończy, a chroniony ruch nigdy nie dotrze.

Dwie przestrzenie nazw, które dzielą małe liczby

Nagłówek IP niesie pole protokołu, które nazywa to, co następuje: 6 dla TCP, 17 dla UDP, 1 dla ICMP, 50 dla ESP, 51 dla AH. Nagłówek TCP lub UDP niesie numery portów, które wybierają proces na hoście docelowym. Protokół 50 i port TCP 50 to niepowiązane wartości, ale okno dialogowe może sprawić, że będą wyglądać na wymienne.

Dlatego reguła przekierowania portów nie może wyrazić natywnego ESP. Nie ma portu docelowego ESP do przekierowania, a urządzenie, które rozumie tylko reguły portów, w ogóle nie ma słownictwa dla tego pakietu. Poprawna reguła nazywa natomiast protokół IP. Każde okno dialogowe portów jest niewłaściwym narzędziem dla tego pakietu.

Zamieszanie ma drugą połowę. Gdy pakiet jest zaszyfrowany, wszystko w jego wnętrzu jest nieprzejrzyste, łącznie z nagłówkiem TCP pierwotnego połączenia. Zapora, która sprawdza porty w tym pakiecie, patrzy na nagłówek zewnętrzny, który w przypadku natywnym nie ma portów do sprawdzenia.

Natywne ESP, potem alternatywa enkapsulowana

Natywne ESP jest przenoszone bezpośrednio jako protokół IP, co jest równie wydajne, co niewygodne. Wydajne, bo nie ma dodatkowego nagłówka, i niewygodne, bo żadne urządzenie tłumaczące adresy i porty nie może go śledzić. NAT traversal istnieje właśnie po to: opakowuje pakiet ESP w UDP, aby tłumacz miał porty do przepisania.

Obie formy to alternatywne wdrożenia tego samego kanału danych, a nie warstwy jednego z nich. Dopuszczenie natywnego ESP nie dopuszcza formy enkapsulowanej, a dopuszczenie UDP 4500 nie dopuszcza ruchu natywnego, więc zestaw reguł musi pasować do wdrożenia, a nie przypadkiem obejmować oba.

Wykrywanie też tu ma znaczenie. Punkty końcowe wybierają między formami podczas negocjacji, a przełączenie zwykle następuje, gdy między nimi zostanie wykryty NAT. Dlatego ścieżka, która zmieni się po ustanowieniu tunelu, może przenieść ruch do przestrzeni nazw, której twoje reguły nigdy nie obejmowały.

Przeczytaj, której formy połączenie rzeczywiście używa

Zapytaj punkt końcowy zamiast zgadywać z zapory. W Linuksie wpis stanu informuje, czy asocjacja używa enkapsulacji UDP i które porty są zaangażowane. Przechwycenie pakietów odpowiada na to samo pytanie z kabla i oba sposoby są szybsze niż czytanie zestawu reguł i nadzieja.

ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'

Pierwsze polecenie pokazuje typ enkapsulacji, gdy używany jest NAT traversal, i nic, gdy nie jest. Drugie pokazuje, która z dwóch form rzeczywiście przechodzi przez interfejs, i to kończy spory o konfigurację, która na papierze wygląda poprawnie.

Kontrdowód należy do tego samego kroku. Reguła, która zgłasza zero trafień, mówi ci, że pakiet nigdy do niej nie dotarł, a to jest kwestia routingu lub selektora, nie zapory.

Następnie potwierdź kanał sterujący osobno. IKE ma własne porty i własne dzienniki, a zakończona negocjacja bez danych to dokładnie ten podział, o którym jest ten artykuł.

Zapisz regułę we właściwej przestrzeni nazw

Reguła protokołu i reguła portu to różne instrukcje, więc narzędzie musi wyrazić tę, którą masz na myśli. W nftables dopasowanie protokołu jest jawne, a enkapsulowana alternatywa dostaje własną regułę UDP. Trzymaj obie reguły obok siebie, aby para była widoczna podczas przeglądu.

nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept

Nie rozszerzaj żadnej z reguł, aby zrekompensować błędną diagnozę. Zezwolenie na wszystko dla protokołu ESP na każdym interfejsie albo zezwolenie UDP z dowolnego miejsca do dowolnego miejsca naprawia objaw i usuwa kontrolę, którą próbowałeś ustawić. Wąski obsługiwany przepływ prawie zawsze wystarcza, gdy forma jest znana.

Na koniec, trzymaj warstwy prosto, gdy tunel działa, a aplikacja nie. Pakiety docierające do bramy nadal wymagają przekazywania, trasy powrotnej i polityki, która je dopuszcza, a żadnego z tego nie wyraża reguła ESP. Brakujący port wyjaśnia konkretną awarię, a nie każdą awarię IPsec. Trzymaj poprawkę reguły i sprawdzenie routingu jako dwa osobne wnioski.

Zapisz zaobserwowaną formę, dodaną regułę protokołu i licznik, który zobaczyłeś później. Trzy linie, a następna osoba odróżni błąd przestrzeni nazw od błędu routingu w minutę, a nie w popołudnie.