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

Ren L2TP er PPP i en konvolut og ikke andet. Det bærer dine rammer; det krypterer dem ikke og beviser ikke, hvem der sidder i den anden ende, og derfor lægger næsten enhver udrulning IPsec ind under det. Ærlige grunde til at køre den nøgne version findes stadig: en laboratoriebænk, et migreringstrin eller et link, der allerede ligger inde i en anden beskyttet vej.

Hvis du går videre, så skriv det forbehold i designnoten og lad det blive der. Det følgende er den driftsvej, jeg bruger på værter i Debian- og RHEL-familien: hvilken fil ejer hvad, den MTU der forhindrer den klassiske blokering, og de videresendelsesregler, der gør tunnelen værd at have.

Tre filer deler arbejdet

xl2tpd afslutter kontrolforbindelsen og overdrager hver session til en PPP-dæmon, så konfigurationen er fordelt på to programmer, der aldrig læser hinandens filer. Lytteren bor i /etc/xl2tpd/xl2tpd.conf, inde i et [lns default]-afsnit, der navngiver adressepuljen med ip range, serversiden med local ip og overdragelsen til PPP med pppoptfile. Slå require authentication = yes til, lad length bit og flow bit være aktiveret, og vælg en pulje, som intet andet på værten allerede bruger.

PPP-politik hører til den fil, som den indstilling navngiver, normalt /etc/ppp/options.xl2tpd: auth, afvisninger for pap, chap og mschap, require-mschap-v2, en MTU og MRU på 1460 og en DNS-adresse, som klienten kan nå, efter forbindelsen er oppe. Legitimationsoplysningerne er igen en tredje fil, /etc/ppp/chap-secrets, hvor det andet felt skal matche LNS-afsnittets navn, og det fjerde felt kan fastgøre en bestemt adresse fra puljen.

Hvorfor tunnelen forbinder og derefter går i stå

En Ethernet-ramme på 1500 byte passer ikke ind i en vej, der allerede bruger byte på sine egne headere. Den ydre IPv4-header koster 20, UDP koster 8, og L2TP-headeren cirka 12, hvilket efterlader 1460 til PPP og dets nyttelast. Det er netop at annoncere det mindre tal i PPP, der forhindrer store pakker i at blive fragmenteret eller lydløst droppet et sted i midten.

Symptomet er en tunnel, der ser sund ud, indtil der kommer rigtig trafik: ping og kontrolmeddelelser går igennem, en filkopiering hænger, intet i loggen forklarer det. Sænk MTU og MRU sammen i begge ender. Justerer man kun klienten, bliver en hård blokering ofte til en periodisk, som er værre at diagnosticere.

Én port bærer to samtaler

UDP 1701 ligger under begge halvdele af protokollen, og den ene kendsgerning bryder flere firewallregler end nogen anden del af opsætningen. Først kommer en start-kontrol-forbindelsesanmodning og dens svar; anmodningen om session og bekræftelsen, der følger, etablerer ikke andet end identifikatorparet. Derefter overtager PPP: linkkontrol, så godkendelse, så IP-kontrolprotokol for at afklare adresser. Hvert trin har sit eget ordforråd i loggen, og ingen af dem melder sig som en L2TP-fejl.

At læse en optagelse i netop den rækkefølge fortæller dig, hvilket trin der fejlede, og en PPP-godkendelsesfejl bliver ikke repareret ved at redigere xl2tpd. Den delte port forklarer en anden almindelig fejl: en regel, der kun tillader de første pakker i en strøm, lader sessionen etablere og blokerer så overførslen. Tillad 1701 for hele samtalen, i begge retninger.

Sådan gør du tunnelen nyttig: videresendelse og NAT

En session i sig selv når kun serveren. Klienternes internetadgang kræver videresendelse, en NAT-regel for puljen på uplink og DNS, som klienten faktisk kan forespørge, når forbindelsen er oppe. Puljen skal også holdes væk fra LAN-området, ellers bliver svar rettet til klienterne leveret lokalt i stedet for at blive skubbet tilbage i tunnelen.

På serveren skal du aktivere videresendelse med sysctl -w net.ipv4.ip_forward=1, oversætte puljen med iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE og derefter acceptere udgående tunneltrafik med en FORWARD-regel for -i ppp0 -o eth0 og returtrafik med spejlreglen plus -m state --state RELATED,ESTABLISHED. Gør disse regler vedvarende over genstart, for en server, der kommer tilbage uden dem, ser præcis ud som en ødelagt L2TP-konfiguration.

At nå serverens eget LAN er en anden opgave: tilføj en returrute for puljen på LAN-routeren eller proxy ARP på serveren. At skjule klienter bag NAT, når noget inde i LAN'et skal adressere dem direkte, planlægger blot en anden fejlfindingssession til senere.

Hvad den nøgne stak ikke gør, og hvordan du verificerer

Ingen del af denne stak krypterer PPP-rammerne, og intet i den godkender den fjerne ende som den server, du faktisk valgte. MS-CHAPv2 beskytter godt nok udvekslingen af legitimationsoplysninger mod en lytter, der kun overværer, men en angriber placeret i vejen kan stadig forstyrre sessionen. Den indbyggede Windows-klient tilbyder kun L2TP sammen med IPsec, så regn med Linux, routerfirmware og tredjepartsklienter som dine modparter. Behandl den nøgne konfiguration som et diagnostisk trin, aldrig som stedet at stoppe.

Bekræft i en fast rækkefølge: kør xl2tpd -D i forgrunden, hold øje med journalen for PPP-trinnet, læs den tildelte adresse fra ip addr i begge ender, og optag derefter UDP 1701 for at bekræfte, at data flyder, efter sessionen er oppe. Hvis alle fire stemmer, og trafikken stadig fejler, ligger fejlen i routing, NAT eller MTU og ikke i L2TP selv.