L2TP utan IPsec på Linux: xl2tpd, pppd och NAT

Ren L2TP är PPP i ett kuvert, och inget annat. Det bär dina ramar; det krypterar dem inte och det bevisar inte vem som sitter i andra änden, vilket är skälet till att nästan varje utrullning lägger IPsec under det. Ärliga skäl att köra den nakna versionen finns fortfarande: en labbänk, ett migreringssteg eller en länk som redan ligger inne i en annan skyddad väg.

Om du ändå går vidare, skriv den varningen i designanteckningen och låt den stå där. Det som följer är den driftväg jag använder på värdar i Debian- och RHEL-familjen: vilken fil äger vad, den MTU som förhindrar den klassiska stningen och vidarebefordringsreglerna som gör tunneln värd besväret.

Tre filer delar arbetet

xl2tpd avslutar styranslutningen och lämnar varje session till en PPP-demon, så konfigurationen är uppdelad på två program som aldrig läser varandras filer. Lyssnaren bor i /etc/xl2tpd/xl2tpd.conf, inne i en [lns default]-sektion som namnger adresspoolen med ip range, serversidan med local ip och överlämningen till PPP med pppoptfile. Slå på require authentication = yes, låt length bit och flow bit vara aktiverade och välj en pool som inget annat på värden redan använder.

PPP-policyn hör till den fil som alternativet namnger, vanligtvis /etc/ppp/options.xl2tpd: auth, avvisningar för pap, chap och mschap, require-mschap-v2, en MTU och MRU på 1460 samt en DNS-adress som klienten kan nå efter att länken kommit upp. Inloggningsuppgifterna är återigen en tredje fil, /etc/ppp/chap-secrets, där det andra fältet måste matcha namnet på LNS-sektionen och det fjärde kan fästa en viss adress från poolen.

Varför tunneln ansluter och sedan stannar

En Ethernet-ram på 1500 byte får inte plats i en väg som redan gör av med byte på sina egna huvuden. Det yttre IPv4-huvudet kostar 20, UDP kostar 8 och L2TP-huvudet omkring 12, vilket lämnar 1460 till PPP och dess nyttolast. Just att annonsera den mindre siffran i PPP är det som hindrar stora paket från att fragmenteras eller tyst tappas någonstans mitt på vägen.

Symtomet är en tunnel som ser frisk ut tills riktig trafik kommer: ping och kontrollmeddelanden går igenom, en filkopiering hänger sig, inget i loggen förklarar det. Sänk MTU och MRU tillsammans i båda ändar. Justerar du bara klienten blir en hård stning oftast periodisk, vilket är svårare att diagnostisera.

En port bär två samtal

UDP 1701 ligger under båda halvorna av protokollet, och detta enda faktum bryter fler brandväggsregler än någon annan del av uppsättningen. Först kommer en begäran om att starta styranslutningen och svaret på den; sessionsbegäran och bekräftelsen som följer etablerar inget mer än identifierarparet. Därefter tar PPP över: länkkontroll, sedan autentisering, sedan IP-kontrollprotokoll för att komma överens om adresser. Varje steg har sitt eget ordförråd i loggen, och ingen av dem utropar sig som ett L2TP-fel.

Att läsa en inspelning exakt i den ordningen säger vilket steg som misslyckades, och ett PPP-autentiseringsfel repareras inte genom att redigera xl2tpd. Den delade porten förklarar ett annat vanligt fel: en regel som bara tillåter de första paketen i ett flöde låter sessionen upprättas och blockerar sedan överföringen. Tillåt 1701 för hela samtalet, i båda riktningarna.

Göra tunneln användbar: vidarebefordran och NAT

En session i sig når bara servern. Klienternas internetuppkoppling kräver vidarebefordran, en NAT-regel för poolen på upplänken och DNS som klienten faktiskt kan fråga när länken kommit upp. Poolen måste också hållas utanför LAN-området, annars levereras svar adresserade till klienterna lokalt i stället för att skjutas tillbaka in i tunneln.

På servern slår du på vidarebefordran med sysctl -w net.ipv4.ip_forward=1, översätter poolen med iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE och tar sedan emot utgående tunneltrafik med en FORWARD-regel för -i ppp0 -o eth0 samt returtrafik med spegelregeln plus -m state --state RELATED,ESTABLISHED. Gör reglerna beständiga över omstarter, för en server som kommer tillbaka utan dem ser exakt ut som en trasig L2TP-konfiguration.

Att nå serverns eget LAN är en annan uppgift: lägg till en returväg för poolen på LAN-routern, eller proxy ARP på servern. Att gömma klienter bakom NAT när något i LAN-et måste adressera dem direkt bokar bara in en andra felsökningssession för senare.

Vad den nakna stacken inte gör och hur du verifierar

Ingen del av den här stacken krypterar PPP-ramarna, och inget i den autentiserar den bortre änden som den server du faktiskt valde. MS-CHAPv2 skyddar visserligen utbytet av inloggningsuppgifter från en lyssnare som bara observerar, men en angripare placerad på vägen kan fortfarande störa sessionen. Den inbyggda Windows-klienten erbjuder L2TP bara tillsammans med IPsec, så räkna med Linux, routernas firmware och tredjepartsklienter som motparter. Behandla den nakna konfigurationen som ett diagnostiskt steg, aldrig som platsen där man stannar.

Kontrollera i fast ordning: kör xl2tpd -D i förgrunden, följ journalen för PPP-steget, läs den tilldelade adressen från ip addr i båda ändar och fånga sedan UDP 1701 för att bekräfta att data flödar efter att sessionen kommit upp. Om alla fyra stämmer och trafiken ändå misslyckas ligger felet i routing, NAT eller MTU och inte i L2TP självt.