L2TP ilman IPseciä Linuxissa: xl2tpd, pppd ja NAT

Pelkkä L2TP on PPP kuoressa, eikä mitään muuta. Se kuljettaa kehyksesi; se ei salaa niitä eikä todista, kuka istuu toisessa päässä, minkä vuoksi lähes jokainen käyttöönotto työntää IPsecin sen alle. Rehellisiä syitä ajaa paljasta versiota on yhä: laboratoriopenkki, migraatiovaihe tai linkki, joka on jo toisen suojatun polun sisällä.

Jos silti jatkat, kirjoita tuo varoitus suunnittelumuistioon ja jätä se sinne. Seuraavassa on toimintapolku, jota käytän Debian- ja RHEL-perheen isännillä: mikä tiedosto omistaa mitä, klassisen jumittumisen estävä MTU ja edelleenlähetyssäännöt, jotka tekevät tunnelista kannattavan.

Kolme tiedostoa jakavat työn

xl2tpd päättää ohjausyhteyden ja luovuttaa jokaisen istunnon PPP-demoniille, joten kokoonpano jakautuu kahdelle ohjelmalle, jotka eivät koskaan lue toistensa tiedostoja. Kuuntelija asuu tiedostossa /etc/xl2tpd/xl2tpd.conf, osiossa [lns default], joka nimeää osoitealtaan komennolla ip range, palvelinpään komennolla local ip ja luovutuksen PPP:lle komennolla pppoptfile. Kytke require authentication = yes päälle, jätä length bit ja flow bit käyttöön ja valitse allas, jota mikään muu isännässä ei vielä käytä.

PPP-käytäntö kuuluu siihen tiedostoon, jonka tuo asetus nimeää, tavallisesti /etc/ppp/options.xl2tpd: auth, hylkäykset papille, chapille ja mschapille, require-mschap-v2, MTU ja MRU 1460 sekä DNS-osoite, johon asiakas pääsee linkin noustua. Tunnistetiedot ovat taas kolmas tiedosto, /etc/ppp/chap-secrets, jossa toisen kentän on vastattava LNS-osion nimeä ja neljäs kenttä voi kiinnittää altaasta tietyn osoitteen.

Miksi tunneli yhdistyy ja sitten jumittuu

1500 tavun Ethernet-kehys ei mahdu polkuun, joka kuluttaa jo tavuja omiin otsikoihinsa. Ulompi IPv4-otsikko maksaa 20, UDP 8 ja L2TP-otsikko noin 12, mikä jättää PPP:lle ja sen hyötykuormalle 1460. Juuri tämän pienemmän luvun ilmoittaminen PPP:ssä estää suuria paketteja pirstoutumasta tai pudotetuiksi hiljaisesti jonnekin matkan varrelle.

Oire on tunneli, joka näyttää terveeltä, kunnes todellinen liikenne saapuu: pingit ja ohjausviestit menevät läpi, tiedoston kopiointi jumittuu, mikään lokissa ei selitä sitä. Laske MTU ja MRU yhdessä molemmissa päissä. Vain asiakkaan säätäminen muuttaa yleensä kovan jumittumisen ajoittaiseksi, mikä on diagnosoinnin kannalta pahempaa.

Yksi portti kuljettaa kaksi keskustelua

UDP 1701 on protokollan molempien puoliskojen alla, ja tämä yksi tosiasia rikkoo enemmän palomuurisääntöjä kuin mikään muu osa asetusta. Ensin tulevat ohjausyhteyden aloituspyyntö ja sen vastaus; seuraavat istuntopyyntö ja vahvistus eivät vakiinnuta muuta kuin tunnisteparin. Sen jälkeen PPP ottaa vallan: linkin ohjaus, sitten todennus, sitten IP:n ohjausprotokolla osoitteiden sopimiseksi. Jokaisella vaiheella on oma sanastonsa lokissa, eikä mikään niistä ilmoita itseään L2TP-viaksi.

Tallenteen lukeminen juuri tuossa järjestyksessä kertoo, mikä vaihe epäonnistui, eikä PPP-todennuksen epäonnistumista korjata muokkaamalla xl2tpd:tä. Jaettu portti selittää toisen yleisen vian: sääntö, joka sallii vain vuon ensimmäiset paketit, antaa istunnon muodostua ja estää sitten siirron. Salli 1701 koko keskustelulle, molempiin suuntiin.

Tunnelista hyödyllinen: edelleenlähetys ja NAT

Istunto itsessään tavoittaa vain palvelimen. Asiakkaiden internetyhteys tarvitsee edelleenlähetyksen, NAT-säännön altaalle uplinkissä ja DNS:n, jota asiakas voi linkin noustua todella kysellä. Altaan on myös pysyttävä LAN-alueen ulkopuolella, muuten asiakkaille osoitetut vastaukset toimitetaan paikallisesti sen sijaan, että ne työnnettäisiin takaisin tunneliin.

Palvelimella ota edelleenlähetys käyttöön komennolla sysctl -w net.ipv4.ip_forward=1, käännä allas komennolla iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ja hyväksy sitten lähtevä tunneliliikenne FORWARD-säännöllä kohteelle -i ppp0 -o eth0 sekä paluuliikenne peilisäännöllä ja -m state --state RELATED,ESTABLISHED. Tee säännöistä pysyvät uudelleenkäynnistysten yli, sillä palvelin, joka palaa ilman niitä, näyttää täsmälleen rikkinäiseltä L2TP-kokoonpanolta.

Palvelimen omaan LAN:iin pääseminen on eri tehtävä: lisää paluureitti altaalle LAN-reitittimessä tai proxy ARP palvelimella. Asiakkaiden piilottaminen NAT:n taakse, kun jonkin LAN:n sisällä on osoitettava niitä suoraan, vain aikatauluttaa toisen vianetsintäistunnon myöhemmäksi.

Mitä paljas pino ei tee ja miten se varmistetaan

Mikään osa tästä pinosta ei salaa PPP-kehyksiä, eikä mikään siinä todista vastapäätä siksi palvelimeksi, jonka todella valitsit. MS-CHAPv2 suojaa kyllä tunnistetietojen vaihtoa vain seuraavalta kuuntelijalta, mutta polulle sijoitettu hyökkääjä voi silti häiritä istuntoa. Windowsin natiivi asiakas tarjoaa L2TP:tä vain yhdessä IPsecin kanssa, joten varaudu siihen, että vertaisinasi ovat Linux, reitittimien laiteohjelmisto ja kolmannen osapuolen asiakkaat. Kohtele paljasta kokoonpanoa diagnoosivaiheena, älä koskaan paikkana, johon pysähtyä.

Vahvista kiinteässä järjestyksessä: aja xl2tpd -D etualalla, seuraa lokia PPP-vaiheen osalta, lue annettu osoite ip addr-tulosteesta molemmissa päissä ja kaappaa sitten UDP 1701 vahvistaaksesi, että data virtaa istunnon noustua. Jos kaikki neljä täsmäävät ja liikenne silti epäonnistuu, vika on reitityksessä, NAT:issa tai MTU:ssa eikä itse L2TP:ssä.