L2TP/IPsec przez NAT: co naprawdę się psuje i dlaczego

Twierdzenie, że NAT psuje L2TP/IPsec, jest w połowie prawdziwe i dlatego bezużyteczne. Tłumaczenie adresów jest normalne, NAT traversal istnieje właśnie po to, by je przetrwać, a miliony klientów łączą się codziennie zza routera. Psuje się konkretny etap konkretnej wymiany: IKE nigdy nie dostaje odpowiedzi, tunel w kapsułce jest odrzucany przez politykę dopuszczającą tylko jeden protokół albo mapowanie tłumaczenia wygasa, gdy tunel jest bezczynny. Gdy wiesz, na którym etapie jesteś, naprawa to zwykle jedna reguła lub keepalive, a nie nowy projekt VPN.

Mit to niewłaściwe pytanie

Użyteczne pytanie nie brzmi „czy NAT to psuje”, ale „która część wymiany jest tłumaczona i co robi z nią urządzenie tłumaczące”. L2TP/IPsec to protokół warstwowy: IKE negocjuje, ESP chroni, a L2TP przenosi PPP wewnątrz tej ochrony. Tłumaczenie adresów działa inaczej na każdej warstwie, a sygnatury awarii można rozróżnić, patrząc na etap negocjacji, a nie na okno błędu.

Router, który bez problemu przegląda internet, dowodzi tylko, że TCP z tłumaczeniem portu źródłowego działa. Nic nie mówi o UDP 500, UDP 4500 ani protokole 50, a to właśnie od tych trzech rzeczy zależy to wdrożenie.

Etap 1: IKE musi w ogóle dostać odpowiedź

Pierwsza wymiana idzie do respondera na UDP 500. Jeśli nie wróci żadna odpowiedź, nic innego nie ma znaczenia: klucz współdzielony, propozycja i dane uwierzytelniające pozostają nieodczytane. Obserwuj żądanie i odpowiedź, zamiast wnioskować z limitu czasu klienta:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Żądanie bez odpowiedzi zwykle oznacza, że zapora albo operator wyżej wyrzuca pakiet, a nie że serwer go odrzucił. Odpowiedź z ładunkiem powiadomienia, który wskazuje propozycję lub problem z certyfikatem, oznacza, że pakiety dotarły, a negocjacja nie powiodła się z powodu treści, co jest zupełnie inną naprawą.

Gdy obie strony są za tłumaczeniem, inicjator musi tylko dotrzeć do respondera, więc większość wdrożeń po stronie klienta działa od etapu 1. Hosting po stronie serwera to miejsce, w którym zaczyna się problem z ruchem przychodzącym, i dlatego tych dwóch sytuacji nie należy nigdy omawiać jako jednej.

Etap 2: kapsułkowanie zmienia to, co widzi zapora

ESP to protokół IP, a nie port TCP lub UDP, a zwykłe tłumaczenie adresów portów nie ma pola portu do przepisania. Dlatego NAT traversal przenosi chroniony ładunek do UDP 4500: kapsułkowanie daje urządzeniu tłumaczącemu coś, co potrafi przetłumaczyć. Gdy to nastąpi, reguła zapory napisana tylko dla UDP 500 pozwoli na negocjację i odrzuci tunel, co daje mylący wynik, w którym dziennik pokazuje udaną fazę 1 i żaden ruch.

Sama wymiana IKE może też przejść na UDP 4500 po wykryciu NAT, co zaskakuje osoby, które zezwoliły tylko na 500. Zezwól na oba porty w obu kierunkach na ścieżce i pamiętaj, że zapora stanowa utrzymuje przepływ tylko dopóki widzi ruch.

Protokół 50 nadal ma znaczenie na ścieżkach bez tłumaczenia i na ścieżkach, gdzie urządzenie pośredniczące jest skonfigurowane, by go dopuścić. Jeśli diagnozujesz przez wykluczanie, wyłącz hipotezę zamiast dodawać reguły hurtowo: zezwól na 500, 4500 i ESP, potwierdź, że tunel wstaje, a potem usuń to, co okazało się zbędne. Reguła, której nikt nie potrafi wyjaśnić, jest regułą, której nikt nie usunie, gdy stanie się przyczyną następnej awarii. Zapisz zawężenie w dzienniku zmian wraz z etapem, który naprawiło, aby następny inżynier zaczął od twoich dowodów, a nie od tej samej reguły praktycznej.

Etap 3: mapowanie wygasa i tunel umiera

Urządzenie tłumaczące utrzymuje stan dla przekazywanych przepływów, a ten stan ma czas życia. Tunel L2TP/IPsec przenosi niewiele ruchu, gdy nikt go nie używa, więc bezczynny tunel może przeżyć swoje mapowanie i przestać odbierać ruch powrotny. Klient nadal jest przekonany, że jest połączony, serwer nic nie widzi, a pierwszym objawem jest zwykle limit czasu aplikacji, a nie błąd VPN.

Wykrywanie martwego peera i keepalive NAT istnieją właśnie po to, a obie strony muszą być gotowe je wysyłać. Jeśli twój serwer jest za tłumaczeniem, wymogiem po stronie Windows jest udokumentowane ustawienie rejestru, które każe serwerowi zakładać kapsułkowanie UDP dla własnych pakietów wychodzących; bez niego responder wysyła ESP, którego urządzenie tłumaczące nie potrafi zmapować z powrotem. To kwestia konfiguracji serwera, nie klienta.

Zmiana adresu WAN daje ten sam efekt z innej strony: mapowanie jest odbudowywane wokół nowego adresu, a stare asocjacje bezpieczeństwa wskazują teraz na krotkę, która już nie istnieje. Zachowanie przy ponownym łączeniu należy do implementacji klienta, dlatego „połącz ponownie po restarcie routera” działa na jednym kliencie, a na innym wymaga ręcznego przełącznika.

Hosting za NAT operatora to inny problem

Jeśli chcesz hostować serwer L2TP/IPsec w domu i docierać do niego z zewnątrz, wymogiem jest nieproszona dostępność przychodząca, a tego NAT traversal nie zapewnia. NAT operatora przed twoim routerem oznacza, że nie ma portu, który możesz przekierować i stać się osiągalny, bo publiczny adres jest współdzielony, a mapowanie jest tylko wychodzące.

Żadne pole wyboru IPsec pass-through tego nie zmienia i żadna konfiguracja klienta tego nie rekompensuje. Obsługiwane odpowiedzi to adres, który jest naprawdę osiągalny, hostowany punkt końcowy albo architektura, w której każdy uczestnik nawiązuje połączenie wychodzące. Specyfikacja kapsułkowania UDP rozwiązuje problem tłumaczenia dla przepływów, które istnieją; nie tworzy ścieżki przychodzącej tam, gdzie operator jej nie oferuje.

Porównuj więc sieci, zamiast zgadywać. Zabierz to samo urządzenie i profil do innej dozwolonej sieci i zobacz, który etap tam zawodzi. Jeśli działa gdzie indziej, różnica jest w ścieżce, a to zawęża poszukiwania do trzech etapów powyżej zamiast do całej konfiguracji.