L2TP ilma IPsecita Linuxis: xl2tpd, pppd ja NAT

Paljas L2TP on PPP ümbrikus ja mitte midagi muud. See kannab teie kaadreid; see ei krüpteeri neid ega tõesta, kes istub teises otsas, mistõttu peaaegu iga juurutus paneb selle alla IPsec. Ausaid põhjuseid palja versiooni käitamiseks on endiselt: laboripink, migratsioonietapp või link, mis asub juba teise kaitstud tee sees.

Kui te siiski jätkate, kirjutage see hoiatus disainimärkme sisse ja jätke see sinna. Järgnev on töötee, mida ma kasutan Debiani ja RHEL-i perekonna hostidel: milline fail mille eest vastutab, MTU, mis hoiab ära klassikalise tõkke, ja edastusreeglid, mis teevad tunnelist asja.

Kolm faili jagavad töö

xl2tpd lõpetab juhtühenduse ja annab iga seansi üle PPP-deemonile, nii et konfiguratsioon jaguneb kahe programmi vahel, mis ei loe kunagi teineteise faile. Kuulaja elab failis /etc/xl2tpd/xl2tpd.conf, jaotise [lns default] sees, mis nimetab aadressibasseini ip range-iga, serveripoolse otsa local ip-ga ja üleandmise PPP-le pppoptfile-iga. Lülitage sisse require authentication = yes, jätke length bit ja flow bit lubatuks ning valige bassein, mida miski muu hostis juba ei kasuta.

PPP-poliitika kuulub sellesse faili, mille see valik nimetab, tavaliselt /etc/ppp/options.xl2tpd: auth, keeldumised pap, chap ja mschap jaoks, require-mschap-v2, MTU ja MRU 1460 ning DNS-aadress, millele klient pärast lingi ülestõstmist pääseb. Volitused on jälle kolmas fail, /etc/ppp/chap-secrets, kus teine väli peab vastama LNS-i jaotise nimele ja neljas väli võib basseinist kindla aadressi kinnitada.

Miks tunnel ühendub ja siis tõmbub kinni

1500-baidine Etherneti kaader ei mahu teele, mis kulutab juba baite omaenda päistele. Välimine IPv4 päis maksab 20, UDP 8 ja L2TP päis umbes 12, mis jätab PPP-le ja selle kandevõimele 1460. Just selle väiksema arvu teavitamine PPP-s hoiab ära suurte pakettide killustamise või vaikse kadumise kusagil keskel.

Sümptom on tunnel, mis näib terve, kuni saabub tegelik liiklus: pingid ja juhtsõnumid lähevad läbi, failikopeerimine tõmbub kinni, miski logis ei selgita seda. Langetage MTU ja MRU mõlemas otsas koos. Ainult kliendi kohandamine muudab tavaliselt kõva tõkke vahelduvaks, mida on raskem diagnoosida.

Üks port kannab kahte vestlust

UDP 1701 asub protokolli mõlema poole all ja see üks tõsiasi rikub rohkem tulemüürireegleid kui ükski teine seadistuse osa. Kõigepealt tulevad juhtühenduse alguse taotlus ja selle vastus; järgnev seansitaotlus ja kinnitus ei kehtesta midagi enamat kui identifikaatorite paar. Seejärel võtab PPP üle: lingi juhtimine, siis autentimine, siis IP juhtimise protokoll aadresside kokkuleppimiseks. Igal etapil on logis oma sõnavara ja ükski neist ei teatata endast kui L2TP tõrkest.

Salvestise lugemine täpselt selles järjekorras ütleb teile, milline etapp ebaõnnestus, ja PPP autentimise tõrge ei parane xl2tpd muutmisega. Jagatud port selgitab veel üht levinud tõrget: reegel, mis lubab ainult voo esimesi pakette, laseb seansil kinnistuda ja blokeerib seejärel ülekande. Lubage 1701 kogu vestluse jaoks, mõlemas suunas.

Tunneli kasulikuks muutmine: edastus ja NAT

Seanss iseenesest jõuab ainult serverini. Klientide internetiühenduse jaoks on vaja edastust, NAT-reeglit basseini jaoks ühendusliinil ja DNS-i, mille poole klient saab pärast lingi ülestõstmist tõesti pöörduda. Bassein peab jääma ka LAN-i vahemikust välja, muidu toimetatakse klientidele adresseeritud vastused kohapeal, selle asemel et need tunnelisse tagasi lükata.

Serveris lubage edastus käsuga sysctl -w net.ipv4.ip_forward=1, tõlkige bassein käsuga iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, seejärel võtke vastu väljuv tunnelliiklus FORWARD-reegliga -i ppp0 -o eth0 ja tagasitulev liiklus peegelreegliga pluss -m state --state RELATED,ESTABLISHED. Tehke need reeglid taaskäivituste vahel püsivaks, sest server, mis tuleb tagasi ilma nendeta, näeb välja täpselt nagu katkine L2TP konfiguratsioon.

Serveri enda LAN-i jõudmine on teine ülesanne: lisage basseinile tagasitee LAN-i ruuteril või proxy ARP serveris. Klientide NAT-i taha peitmine siis, kui miski LAN-i sees peab neile otse adresseerima, ainult planeerib hiljem teise silumisseansi.

Mida paljas virn ei tee ja kuidas seda kontrollida

Ükski osa sellest virnast ei krüpteeri PPP kaadreid ja miski selles ei autenti kaugemat otsa serverina, mille te tegelikult valisite. MS-CHAPv2 kaitseb küll volituste vahetust ainult pealtvaataja eest, kuid teele paigutatud ründaja saab siiski seanssi segada. Windowsi natiivne klient pakub L2TP-d ainult koos IPseciga, seega arvestage partneritena Linuxi, ruuterite püsivara ja kolmandate osapoolte klientidega. Käsitlege paljast konfiguratsiooni diagnostilise vaheastmena, mitte kunagi kohana, kus peatuda.

Kontrollige kindlas järjekorras: käivitage xl2tpd -D esiplaanil, jälgige logi PPP etapi jaoks, lugege määratud aadress ip addr väljundist mõlemas otsas, seejärel püüdke UDP 1701, et kinnitada, et andmed liiguvad pärast seansi ülestõstmist. Kui kõik neli klapivad ja liiklus ikka ei tööta, on süü marsruutimises, NAT-is või MTU-s, mitte L2TP-s endas.