L2TP IPsec nélkül Linuxon: xl2tpd, pppd és NAT

A csupasz L2TP PPP egy borítékban, és semmi más. Szállítja a kereteket; nem titkosítja őket, és nem bizonyítja, ki ül a másik végén, ezért szinte minden telepítés IPsecet csúsztat alá. Őszinte okok a csupasz változat futtatására még mindig vannak: egy laboratóriumi pad, egy migrációs lépés, vagy egy olyan kapcsolat, amely már egy másik védett útvonalon belül van.

Ha mégis nekivág, írja be ezt a figyelmeztetést a tervezési jegyzetbe, és hagyja ott. A következő a Debian és RHEL családba tartozó hosztokon használt üzemeltetési útvonal: melyik fájl miért felelős, az MTU, amely megakadályozza a klasszikus elakadást, és az átirányítási szabályok, amelyek használhatóvá teszik az alagutat.

Három fájl osztja meg a munkát

Az xl2tpd lezárja a vezérlőkapcsolatot, és minden munkamenetet átad egy PPP-démonnak, így a konfiguráció két olyan program között oszlik meg, amelyek soha nem olvassák egymás fájljait. A figyelő a /etc/xl2tpd/xl2tpd.conf fájlban él, egy [lns default] szakaszon belül, amely az ip range beállítással nevezi meg a címkészletet, a local ip beállítással a kiszolgáló oldalát, és a pppoptfile beállítással a PPP-nek való átadást. Kapcsolja be a require authentication = yes opciót, hagyja engedélyezve a length bit és flow bit beállítást, és válasszon olyan készletet, amelyet a hoszton semmi más nem használ.

A PPP-szabályzat abba a fájlba tartozik, amelyet ez az opció megnevez, általában a /etc/ppp/options.xl2tpd fájlba: auth, a pap, a chap és az mschap elutasítása, require-mschap-v2, 1460-as MTU és MRU, valamint egy DNS-cím, amelyet az ügyfél a kapcsolat felállása után elérhet. A hitelesítő adatok ismét egy harmadik fájlban, a /etc/ppp/chap-secrets fájlban vannak, ahol a második mezőnek meg kell egyeznie az LNS-szakasz nevével, a negyedik mező pedig készletből származó konkrét címet rögzíthet.

Miért kapcsolódik az alagút, és miért akad el utána

Egy 1500 bájtos Ethernet-keret nem fér bele egy olyan útvonalba, amely már bájtokat költ a saját fejléceire. A külső IPv4-fejléc 20-at, az UDP 8-at, az L2TP-fejléc pedig körülbelül 12-t vesz igénybe, ami 1460-at hagy a PPP-nek és a hasznos terhének. Éppen ennek a kisebb számnak a hirdetése a PPP-ben az, ami megakadályozza, hogy a nagy csomagok feldarabolódjanak vagy csendben elvesszenek valahol a közepén.

A tünet egy olyan alagút, amely egészségesnek látszik, amíg valódi forgalom nem érkezik: a pingek és a vezérlőüzenetek átmennek, egy fájlmásolás elakad, a naplóban semmi sem magyarázza meg. Csökkentse az MTU-t és az MRU-t együtt mindkét végén. Ha csak az ügyfelet állítja, a kemény elakadás rendszerint időszakossá válik, amit nehezebb diagnosztizálni.

Egy port két beszélgetést hordoz

Az UDP 1701 a protokoll mindkét fele alatt van, és ez az egyetlen tény több tűzfalszabályt tör el, mint a beállítás bármely más része. Először egy vezérlőkapcsolat-indítási kérés és annak válasza érkezik; az ezt követő munkamenet-kérés és megerősítés nem hoz létre többet az azonosító párnál. Ezután a PPP veszi át: kapcsolatvezérlés, majd hitelesítés, majd IP-vezérlő protokoll a címek egyeztetésére. Minden szakasznak saját szókincse van a naplóban, és egyik sem jelenti be magát L2TP-hibaként.

A rögzítés pontosan ebben a sorrendben való olvasása megmondja, melyik szakasz hiúsult meg, és a PPP-hitelesítés hibáját nem javítja az xl2tpd szerkesztése. A megosztott port egy másik gyakori hibát magyaráz: az a szabály, amely csak egy folyam első csomagjait engedi át, hagyja létrejönni a munkamenetet, majd blokkolja az átvitelt. Engedélyezze az 1701-et a teljes beszélgetésre, mindkét irányban.

Használhatóvá tenni az alagutat: átirányítás és NAT

Egy munkamenet önmagában csak a kiszolgálót éri el. Az ügyfelek interneteléréséhez átirányítás, a készlethez NAT-szabály a felső kapcsolaton, és olyan DNS kell, amelyet az ügyfél a kapcsolat felállása után valóban meg tud kérdezni. A készletnek a LAN tartományán kívül is kell maradnia, különben az ügyfeleknek címzett válaszok helyben kerülnek kézbesítésre, ahelyett hogy visszalökődnének az alagútba.

A kiszolgálón engedélyezze az átirányítást a sysctl -w net.ipv4.ip_forward=1 paranccsal, fordítsa le a készletet az iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE paranccsal, majd fogadja a kimenő alagútforgalmat egy FORWARD-szabállyal a -i ppp0 -o eth0 esetében, a visszatérő forgalmat pedig a tükörszabállyal és a -m state --state RELATED,ESTABLISHED beállítással. Tegye ezeket a szabályokat újraindításokon át tartóssá, mert egy kiszolgáló, amely ezek nélkül tér vissza, pontosan úgy néz ki, mint egy elromlott L2TP-konfiguráció.

A kiszolgáló saját LAN-jának elérése más feladat: adjon hozzá visszatérő útvonalat a készlethez a LAN-routeren, vagy proxy ARP-t a kiszolgálón. Az ügyfelek NAT mögé rejtése, amikor a LAN-on belül valaminek közvetlenül kell címieznie őket, csak egy második hibakeresési munkamenetet ütemez későbbre.

Mit nem tesz a csupasz verem, és hogyan ellenőrizze

Ennek a veremnek egyetlen része sem titkosítja a PPP-kereteket, és semmi benne nem hitelesíti a távoli felet azként a kiszolgálóként, amelyet valóban választott. Az MS-CHAPv2 valóban védi a hitelesítő adatok cseréjét egy csak figyelő hallgatótól, ám az útvonalba helyezett támadó még mindig beavatkozhat a munkamenetbe. A Windows natív kliense csak IPsec-kel együtt kínál L2TP-t, ezért számoljon Linuxszal, router-firmware-rel és harmadik féltől származó kliensekkel mint partnerekkel. Kezelje a csupasz konfigurációt diagnosztikai lépcsőfokként, soha ne megállóhelyként.

Ellenőrizze rögzített sorrendben: futtassa az xl2tpd -D parancsot előtérben, figyelje a naplót a PPP-szakasz szempontjából, olvassa ki a kiosztott címet az ip addr kimenetéből mindkét végén, majd rögzítse az UDP 1701-et annak megerősítésére, hogy az adatok a munkamenet felállása után folynak. Ha mind a négy egyezik, és a forgalom mégis meghiúsul, a hiba az útválasztásban, a NAT-ban vagy az MTU-ban van, nem magában az L2TP-ben.