L2TP bez IPsec w systemie Linux: xl2tpd, pppd i NAT

Czysty L2TP to PPP w kopercie i nic więcej. Przenosi twoje ramki; nie szyfruje ich i nie dowodzi, kto siedzi po drugiej stronie, dlatego niemal każde wdrożenie podkłada pod niego IPsec. Uczciwe powody, by uruchamiać wersję nagą, wciąż istnieją: stanowisko laboratoryjne, krok migracji albo łącze, które już znajduje się wewnątrz innej chronionej ścieżki.

Jeśli mimo to brniesz dalej, zapisz to zastrzeżenie w notatce projektowej i zostaw je tam. To, co następuje, to ścieżka operacyjna, której używam na hostach z rodziny Debian i RHEL: który plik za co odpowiada, MTU, które zapobiega klasycznemu zablokowaniu, oraz reguły przekazywania, dzięki którym tunel ma sens.

Trzy pliki dzielą pracę

xl2tpd kończy połączenie sterujące i przekazuje każdą sesję demonowi PPP, więc konfiguracja rozkłada się na dwa programy, które nigdy nie czytają swoich plików. Nasłuchiwacz mieszka w /etc/xl2tpd/xl2tpd.conf, w sekcji [lns default], która nazywa pulę adresów przez ip range, stronę serwera przez local ip, a przekazanie do PPP przez pppoptfile. Włącz require authentication = yes, pozostaw length bit i flow bit aktywne i wybierz pulę, której nic innego na hoście jeszcze nie używa.

Polityka PPP należy do pliku, który nazywa ta opcja, zwykle /etc/ppp/options.xl2tpd: auth, odmowy dla pap, chap i mschap, require-mschap-v2, MTU i MRU równe 1460 oraz adres DNS, do którego klient dotrze po podniesieniu łącza. Poświadczenia to znowu trzeci plik, /etc/ppp/chap-secrets, gdzie drugie pole musi pasować do nazwy sekcji LNS, a czwarte może przypiąć konkretny adres z puli.

Dlaczego tunel się łączy, a potem zastyga

Ramka Ethernet o rozmiarze 1500 bajtów nie mieści się w ścieżce, która już wydaje bajty na własne nagłówki. Zewnętrzny nagłówek IPv4 kosztuje 20, UDP kosztuje 8, a nagłówek L2TP około 12, co zostawia 1460 dla PPP i jego ładunku. Właśnie ogłaszanie tej mniejszej liczby w PPP powstrzymuje duże pakiety przed fragmentacją albo cichym porzuceniem gdzieś w środku.

Objawem jest tunel, który wygląda zdrowo, dopóki nie pojawi się prawdziwy ruch: pingi i komunikaty sterujące przechodzą, kopiowanie pliku zawiesza się, nic w logu tego nie wyjaśnia. Obniż MTU i MRU razem po obu stronach. Regulacja samego klienta zwykle zamienia twarde zawieszenie w okresowe, które trudniej zdiagnozować.

Jeden port niesie dwie rozmowy

UDP 1701 leży pod obiema połowami protokołu, i ten jeden fakt łamie więcej reguł zapory niż jakakolwiek inna część konfiguracji. Najpierw przychodzą żądanie rozpoczęcia połączenia sterującego i odpowiedź na nie; żądanie sesji i potwierdzenie, które następują, ustanawiają nie więcej niż parę identyfikatorów. Potem przejmuje PPP: sterowanie łączem, następnie uwierzytelnianie, następnie protokół sterowania IP, by uzgodnić adresy. Każdy etap ma własne słownictwo w logu i żaden nie ogłasza się awarią L2TP.

Czytanie zrzutu dokładnie w tej kolejności mówi, który etap zawiódł, a awarii uwierzytelniania PPP nie naprawi edycja xl2tpd. Wspólny port wyjaśnia inną częstą awarię: reguła, która pozwala tylko na pierwsze pakiety przepływu, pozwala sesji powstać, a potem blokuje transfer. Zezwól na 1701 dla całej rozmowy, w obu kierunkach.

Uczynić tunel użytecznym: przekazywanie i NAT

Sesja sama w sobie dociera tylko do serwera. Dostęp klientów do internetu wymaga przekazywania, reguły NAT dla puli na łączu wyjściowym i DNS, o który klient naprawdę może zapytać po podniesieniu łącza. Pula musi też pozostawać poza zakresem LAN, inaczej odpowiedzi adresowane do klientów są dostarczane lokalnie zamiast wypychane z powrotem do tunelu.

Na serwerze włącz przekazywanie przez sysctl -w net.ipv4.ip_forward=1, przetłumacz pulę przez iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, a następnie przyjmuj wychodzący ruch tunelu regułą FORWARD dla -i ppp0 -o eth0 i ruch powrotny regułą lustrzaną plus -m state --state RELATED,ESTABLISHED. Uczyń te reguły trwałymi między restartami, bo serwer, który wraca bez nich, wygląda dokładnie jak zepsuta konfiguracja L2TP.

Dostanie się do własnej sieci LAN serwera to inne zadanie: dodaj trasę powrotną dla puli na routerze LAN albo proxy ARP na serwerze. Ukrywanie klientów za NAT, gdy coś wewnątrz LAN musi adresować ich bezpośrednio, tylko planuje drugą sesję debugowania na później.

Czego nagi stos nie robi i jak to sprawdzić

Żadna część tego stosu nie szyfruje ramek PPP i nic w nim nie uwierzytelnia drugiej strony jako serwera, który naprawdę wybrałeś. MS-CHAPv2 chroni wymianę poświadczeń przed podsłuchującym, który tylko obserwuje, ale atakujący umieszczony na ścieżce nadal może zakłócić sesję. Natywny klient Windows oferuje L2TP tylko w połączeniu z IPsec, więc licz na Linuksa, firmware routerów i klientów firm trzecich jako partnerów. Traktuj nagą konfigurację jako diagnostyczny stopień, nigdy jako miejsce, w którym się zatrzymujesz.

Sprawdzaj w ustalonej kolejności: uruchom xl2tpd -D na pierwszym planie, obserwuj dziennik pod kątem etapu PPP, odczytaj przydzielony adres z ip addr po obu stronach, a potem przechwyć UDP 1701, by potwierdzić, że dane płyną po podniesieniu sesji. Jeśli wszystkie cztery się zgadzają, a ruch nadal zawodzi, wina leży w routingu, NAT albo MTU, a nie w samym L2TP.