Dlaczego L2TP/IPsec potrzebuje UDP 1701 obok IPsec

Zapory ogniowe, które zezwalają na IKE i ESP, ale nie na UDP 1701, przerywają połączenia L2TP w sposób, który wygląda jak problem z poświadczeniami. Powód jest taki, że L2TP jest drugim protokołem podróżującym wewnątrz pierwszego. IPsec przenosi i uwierzytelnia wymianę, a L2TP prowadzi własny tunel przez UDP 1701, który lokalny stos nadal musi dostarczyć. Wiedza o tym, gdzie pojawia się każdy nagłówek, wyjaśnia, które urządzenie potrzebuje której reguły.

Dwa protokoły, dwa zestawy portów

Połączenie L2TP/IPsec używa IKE na UDP 500, przejścia NAT na UDP 4500 tam, gdzie jest tłumaczenie, oraz ESP jako protokołu IP 50 tam, gdzie go nie ma. Sam L2TP jest protokołem tunelowym na UDP 1701 i działa po uwierzytelnieniu partnera przez IPsec. Obie połowy zawodzą inaczej, a wiersze dziennika, które o nich informują, pochodzą z różnych komponentów. Zestaw reguł obejmujący tylko pierwszą połowę daje połączenie, które negocjuje, a potem ginie w fazie tunelu.

Numery portów opisują punkty końcowe transportu, a ESP wcale nie jest portem. Dlatego interfejs zapory oferujący tylko reguły TCP i UDP nie może wyrazić pełnej polityki IPsec. Protokół 50 musi być dozwolony jako protokół, a reguła wspominająca tylko UDP nigdy go nie dopasuje.

Otoczka wyjaśnia port

W sieci połączenie L2TP/IPsec zwykle pokazuje IKE na 500 i opakowany ESP na 4500. Nagłówek UDP 1701 znajduje się wewnątrz chronionego ładunku, dlatego przechwycenie na interfejsie zewnętrznym go nie pokazuje. Lokalny host nadal musi dostarczyć ten datagram do demona L2TP, a dostarczenie następuje po dekapsulacji. Dlatego reguła 1701 należy do zapory samego punktu końcowego, nawet gdy żadne urządzenie pośrednie nigdy nie widzi portu.

Kolejność przetwarzania wyjaśnia większość zamieszania. Jeśli stos zastosuje politykę IPsec przed filtrem hosta, zdekapsulowany pakiet L2TP jest dopasowywany jako UDP 1701; jeśli kolejność jest odwrotna, zestaw reguł widzi porty zewnętrzne. Oba zachowania występują w praktyce, dlatego ten sam zestaw reguł wydaje się działać na jednej platformie, a zawodzić na innej.

Sprawdź ścieżkę po kolei

Najpierw przechwyć interfejs zewnętrzny i potwierdź, że IKE i opakowany ESP przemieszczają się w obu kierunkach. Następnie sprawdź liczniki lokalnej zapory dla ruchu po dekapsulacji. Kolejność ma znaczenie, ponieważ przechwycenie, które nie pokazuje niczego, oznacza, że problem leży powyżej hosta.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

Przechwycenie potwierdza pierwszą połowę wymiany i pokazuje, czy partner odpowiada. Lista reguł pokazuje, czy istnieje reguła 1701 i gdzie znajduje się względem dowolnej polityki odrzucania. Lista gniazd potwierdza, że demon L2TP jest powiązany i nasłuchuje, co wyklucza usługę, która nigdy nie wystartowała. Przeczytaj wszystkie trzy przed zmianą reguły, ponieważ brakujący nasłuch i filtrowany port dają identyczne skargi użytkownika.

Czego nie pokaże skanowanie portów

Zewnętrzne skanowanie UDP 1701 wobec poprawnie skonfigurowanego serwera zwykle nic nie zgłasza i to jest oczekiwany wynik. Port nie jest wystawiony do internetu; dociera się do niego dopiero po uwierzytelnieniu partnera przez IPsec. Traktowanie zamkniętego wyniku jako usterki prowadzi do otwarcia portu, który powinien pozostać zamknięty. Skanowanie nie widzi wnętrza tunelu bardziej niż widzi ruch aplikacji.

Zamiast tego przetestuj prawdziwym klientem i przeczytaj, do którego etapu dociera. Jeśli połączenie negocjuje i potem się zatrzymuje, podejrzany jest demon L2TP lub filtr lokalny; jeśli nigdy nie negocjuje, winne są porty zewnętrzne. Ten jeden podział usuwa większość zgadywania, którą regułę dodać, a warstwowość protokołów czyni to przewidywalnym zamiast tajemniczym.