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

Rein L2TP er PPP i ein konvolutt, og ikkje noko anna. Det ber rammene dine; det krypterer dei ikkje og provar ikkje kven som sit i den andre enden, og difor legg nesten kvar utrulling IPsec under det. Ærlege grunnar til å køyre den nakne versjonen finst framleis: ein laboratoriebenk, eit migreringstrinn eller ei lenkje som alt ligg inne i ein annan verna veg.

Viss du går vidare, skriv det atterhaldet i designnotatet og lat det stå der. Det som følgjer er driftsvegen eg brukar på vertar i Debian- og RHEL-familien: kva fil eig kva, MTU-en som hindrar den klassiske stansen, og videresendingsreglane som gjer tunnelen verdt å ha.

Tre filer deler arbeidet

xl2tpd avsluttar kontrollforbindinga og overlèt kvar sesjon til ein PPP-daemon, så konfigurasjonen er fordelt på to program som aldri les kvar sine filer. Lyttaren bur i /etc/xl2tpd/xl2tpd.conf, inne i ein [lns default]-seksjon som namngir adressebassenget med ip range, serversida med local ip og overleveringa til PPP med pppoptfile. Slå på require authentication = yes, lat length bit og flow bit vere aktiverte, og vel eit basseng som ingenting anna på verten alt brukar.

PPP-policyen høyrer til fila som det valet nemner, vanlegvis /etc/ppp/options.xl2tpd: auth, avvisingar for pap, chap og mschap, require-mschap-v2, ein MTU og MRU på 1460, og ei DNS-adresse klienten kan nå etter at sambandet er oppe. Påloggingsdetaljane er igjen ei tredje fil, /etc/ppp/chap-secrets, der det andre feltet må samsvare med namnet på LNS-seksjonen, og det fjerde feltet kan feste ei bestemd adresse frå bassenget.

Kvifor tunnelen koplar til og så stansar

Ei Ethernet-ramme på 1500 byte passar ikkje inn i ein veg som alt brukar byte på sine eigne headers. Den ytre IPv4-headeren kostar 20, UDP kostar 8, og L2TP-headeren omtrent 12, noko som lèt 1460 att til PPP og nyttelasta. Nettopp å annonsere det mindre talet i PPP er det som hindrar store pakkar i å bli fragmenterte eller stille droppa ein stad midtvegs.

Symptomet er ein tunnel som ser sunn ut til ekte trafikk kjem: ping og kontrollmeldingar går gjennom, ein filkopi heng, ingenting i loggen forklarar det. Senk MTU og MRU saman i begge endar. Justerer du berre klienten, blir ein hard stans ofte til ein periodisk, som er verre å diagnostisere.

Éin port ber to samtalar

UDP 1701 ligg under begge halvdelane av protokollen, og dette eine faktum bryt fleire brannmurreglar enn nokon annan del av oppsettet. Fyrst kjem ei førespurnad om å starte kontrollforbindinga og svaret på henne; sesjonsførespurnaden og stadfestinga som følgjer, etablerer ikkje meir enn identifikatorparet. Deretter tek PPP over: lenkjekontroll, så autentisering, så IP-kontrollprotokoll for å avtale adresser. Kvart trinn har sitt eige ordforråd i loggen, og ingen av dei melder seg som ein L2TP-feil.

Å lese eit opptak nøyaktig i den rekkjefølgja fortel deg kva trinn som feila, og ein PPP-autentiseringsfeil blir ikkje reparert ved å redigere xl2tpd. Den delte porten forklarar ein annan vanleg feil: ein regel som berre tillèt dei fyrste pakkane i ein straum, lèt sesjonen etablere seg og blokkerer deretter overføringa. Tillat 1701 for heile samtalen, i begge retningar.

Gjere tunnelen nyttig: videresending og NAT

Ein sesjon i seg sjølv når berre serveren. Internettilgangen til klientane krev videresending, ein NAT-regel for bassenget på opplenkja, og DNS som klienten faktisk kan spørje etter at sambandet er oppe. Bassenget må òg haldast unna LAN-området, elles blir svar retta til klientane leverte lokalt i staden for å bli skyvne tilbake i tunnelen.

På serveren slår du på videresending med sysctl -w net.ipv4.ip_forward=1, set om bassenget med iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, og godtek deretter utgåande tunneltrafikk med ein FORWARD-regel for -i ppp0 -o eth0 og returtrafikk med spegelregelen pluss -m state --state RELATED,ESTABLISHED. Gjer desse reglane varige over omstartar, for ein server som kjem tilbake utan dei, ser nøyaktig ut som ein øydelagd L2TP-konfigurasjon.

Å nå serveren sitt eige LAN er ei anna oppgåve: legg til ein returveg for bassenget på LAN-rutaren, eller proxy ARP på serveren. Å skjule klientar bak NAT når noko i LAN-et må adressere dei direkte, planlegg berre ein andre feilsøkingsøkt seinare.

Kva den nakne stabelen ikkje gjer, og korleis du stadfester

Ingen del av denne stabelen krypterer PPP-rammene, og ingenting i han autentiserer den fjerne enden som serveren du faktisk valde. MS-CHAPv2 vernar riktig nok utvekslinga av påloggingsdetaljar mot ein lyttar som berre observerer, men ein åtakarmann plassert i vegen kan framleis forstyrre sesjonen. Den innebygde Windows-klienten tilbyr berre L2TP saman med IPsec, så rekn med Linux, rutarmikrokode og tredjepartsklientar som motpartane dine. Behandle den nakne konfigurasjonen som eit diagnostisk trinn, aldri som staden å stoppe.

Kontroller i fast rekkjefølgje: køyr xl2tpd -D i forgrunnen, følg med på journalen for PPP-trinnet, les den tildelte adressa frå ip addr i begge endar, og fang deretter UDP 1701 for å stadfeste at data flyt etter at sesjonen er oppe. Viss alle fire stemmer og trafikken framleis feilar, ligg feilen i ruting, NAT eller MTU og ikkje i L2TP sjølv.