L2TP uten IPsec på Linux: xl2tpd, pppd og NAT

Ren L2TP er PPP i en konvolutt, og ikke noe annet. Det bærer rammene dine; det krypterer dem ikke og beviser ikke hvem som sitter i den andre enden, og derfor legger nesten enhver utrulling IPsec under det. Ærlige grunner til å kjøre den nakne versjonen finnes fortsatt: en laboratoriebenk, et migreringstrinn eller en lenke som allerede ligger inne i en annen beskyttet vei.

Hvis du går videre, skriv det forbeholdet i designnotatet og la det stå der. Det som følger er driftsveien jeg bruker på verter i Debian- og RHEL-familien: hvilken fil eier hva, MTU-en som forhindrer den klassiske stansen, og videresendingsreglene som gjør tunnelen verdt å ha.

Tre filer deler arbeidet

xl2tpd avslutter kontrollforbindelsen og overlater hver sesjon til en PPP-daemon, så konfigurasjonen er fordelt på to programmer som aldri leser hverandres filer. Lytteren bor i /etc/xl2tpd/xl2tpd.conf, inne i en [lns default]-seksjon som navngir adressepoolen med ip range, serversiden med local ip og overleveringen til PPP med pppoptfile. Slå på require authentication = yes, la length bit og flow bit være aktivert, og velg en pool som ingenting annet på verten allerede bruker.

PPP-policyen hører til filen som det alternativet nevner, vanligvis /etc/ppp/options.xl2tpd: auth, avvisninger for pap, chap og mschap, require-mschap-v2, en MTU og MRU på 1460, og en DNS-adresse klienten kan nå etter at forbindelsen er oppe. Påloggingsdetaljene er igjen en tredje fil, /etc/ppp/chap-secrets, der det andre feltet må samsvare med navnet på LNS-seksjonen, og det fjerde feltet kan feste en bestemt adresse fra poolen.

Hvorfor tunnelen kobler til og så stanser

En Ethernet-ramme på 1500 byte passer ikke inn i en vei som allerede bruker byte på sine egne headere. Den ytre IPv4-headeren koster 20, UDP koster 8, og L2TP-headeren omtrent 12, noe som etterlater 1460 til PPP og nyttelasten. Nettopp å annonsere det mindre tallet i PPP er det som hindrer store pakker i å bli fragmentert eller stille droppet et sted midtveis.

Symptomet er en tunnel som ser sunn ut til ekte trafikk kommer: ping og kontrollmeldinger går gjennom, en filkopi henger, ingenting i loggen forklarer det. Senk MTU og MRU sammen i begge ender. Justerer du bare klienten, blir en hard stans ofte til en periodisk, som er verre å diagnostisere.

Én port bærer to samtaler

UDP 1701 ligger under begge halvdeler av protokollen, og dette ene faktum bryter flere brannmurregler enn noen annen del av oppsettet. Først kommer en forespørsel om å starte kontrollforbindelsen og svaret på den; sesjonsforespørselen og bekreftelsen som følger, etablerer ikke mer enn identifikatorparet. Deretter overtar PPP: lenkekontroll, så autentisering, så IP-kontrollprotokoll for å avtale adresser. Hvert trinn har sitt eget ordforråd i loggen, og ingen av dem melder seg som en L2TP-feil.

Å lese en opptak nøyaktig i den rekkefølgen forteller deg hvilket trinn som feilet, og en PPP-autentiseringsfeil blir ikke reparert ved å redigere xl2tpd. Den delte porten forklarer en annen vanlig feil: en regel som bare tillater de første pakkene i en strøm, lar sesjonen etablere seg og blokkerer deretter overføringen. Tillat 1701 for hele samtalen, i begge retninger.

Gjøre tunnelen nyttig: videresending og NAT

En sesjon i seg selv når bare serveren. Klientenes internettilgang krever videresending, en NAT-regel for poolen på opplenken, og DNS som klienten faktisk kan spørre etter at forbindelsen er oppe. Poolen må også holdes unna LAN-området, ellers leveres svar rettet til klientene lokalt i stedet for å skyves tilbake i tunnelen.

På serveren slår du på videresending med sysctl -w net.ipv4.ip_forward=1, oversetter poolen med iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, og godtar deretter utgående tunneltrafikk med en FORWARD-regel for -i ppp0 -o eth0 og returtrafikk med speilregelen pluss -m state --state RELATED,ESTABLISHED. Gjør disse reglene varige over omstarter, for en server som kommer tilbake uten dem, ser nøyaktig ut som en ødelagt L2TP-konfigurasjon.

Å nå serverens eget LAN er en annen oppgave: legg til en returrute for poolen på LAN-ruteren, eller proxy ARP på serveren. Å skjule klienter bak NAT når noe i LAN-et må adressere dem direkte, planlegger bare en andre feilsøkingsøkt senere.

Hva den nakne stabelen ikke gjør, og hvordan du verifiserer

Ingen del av denne stabelen krypterer PPP-rammene, og ingenting i den autentiserer den fjerne enden som serveren du faktisk valgte. MS-CHAPv2 beskytter riktignok utvekslingen av påloggingsdetaljer mot en lytter som bare observerer, men en angriper plassert i veien kan fortsatt forstyrre sesjonen. Den innebygde Windows-klienten tilbyr bare L2TP sammen med IPsec, så regn med Linux, rutermikrokode og tredjepartsklienter som dine motparter. Behandle den nakne konfigurasjonen som et diagnostisk trinn, aldri som stedet å stoppe.

Kontroller i fast rekkefølge: kjør xl2tpd -D i forgrunnen, følg med på journalen for PPP-trinnet, les den tildelte adressen fra ip addr i begge ender, og fang deretter UDP 1701 for å bekrefte at data flyter etter at sesjonen er oppe. Hvis alle fire stemmer og trafikken fortsatt feiler, ligger feilen i ruting, NAT eller MTU og ikke i L2TP selv.