L2TP без IPsec под Linux: xl2tpd, pppd и NAT

Обикновеният L2TP е PPP в плик и нищо друго. Той пренася вашите кадри; не ги криптира и не доказва кой седи от другата страна, затова почти всяко внедряване подлага IPsec под него. Честни причини да пуснете голата версия все още съществуват: лабораторен стенд, стъпка от миграция или връзка, която вече е вътре в друг защитен път.

Ако все пак продължите, запишете това предупреждение в бележката за дизайна и го оставете там. Следва оперативният път, който използвам на хостове от Debian и семейството на RHEL: кой файл какво отговаря, MTU, което предотвратява класическото забиване, и правилата за препращане, които правят тунела смислен.

Три файла разделят работата

xl2tpd прекратява контролната връзка и предава всяка сесия на PPP демон, така че конфигурацията е разпределена между две програми, които никога не четат файловете една на друга. Слушателят живее в /etc/xl2tpd/xl2tpd.conf, в секция [lns default], която именува адресния пул с ip range, страната на сървъра с local ip и предаването към PPP с pppoptfile. Включете require authentication = yes, оставете length bit и flow bit активирани и изберете пул, който нищо друго на хоста още не използва.

Политиката на PPP принадлежи на файла, който тази опция посочи, обикновено /etc/ppp/options.xl2tpd: auth, откази за pap, chap и mschap, require-mschap-v2, MTU и MRU 1460 и DNS адрес, до който клиентът може да достигне след вдигане на връзката. Данните за достъп са отново трети файл, /etc/ppp/chap-secrets, където второто поле трябва да съвпада с името на LNS секцията, а четвъртото може да закрепи конкретен адрес от пула.

Защо тунелът се свързва и после забива

1500-байтов Ethernet кадър не се побира в път, който вече харчи байтове за собствените си заглавки. Външната IPv4 заглавка струва 20, UDP — 8, а L2TP заглавката — около 12, което оставя 1460 за PPP и полезния му товар. Именно обявяването на тази по-малка стойност в PPP пречи на големите пакети да бъдат фрагментирани или тихо изпуснати някъде по средата.

Симптомът е тунел, който изглежда здрав, докато не пристигне реален трафик: пинговете и контролните съобщения минават, копирането на файл забива, нищо в журнала не го обяснява. Намалете MTU и MRU заедно от двете страни. Настройката само на клиента обикновено превръща твърдото забиване в периодично, което е по-лошо за диагностика.

Един порт носи два разговора

UDP 1701 стои под двете половини на протокола и този единствен факт чупи повече правила на защитната стена от всяка друга част на настройката. Първо идват заявката за начало на контролна връзка и отговорът ѝ; заявката за сесия и потвърждението след тях не установяват нищо повече от двойката идентификатори. След това поема PPP: контрол на връзката, после автентикация, после протокол за контрол на IP, за да уреди адресите. Всеки етап има свой речник в журнала и никой от тях не се обявява като повреда на L2TP.

Четенето на запис точно в този ред ви казва кой етап се е провалил, а провал на PPP автентикацията няма да се поправи с редактиране на xl2tpd. Споделеният порт обяснява друга честа повреда: правило, което позволява само първите пакети на поток, оставя сесията да се установи и после блокира преноса. Разрешете 1701 за целия разговор, в двете посоки.

Как да направим тунела полезен: препращане и NAT

Сесията сама по себе си достига само до сървъра. За интернет достъп на клиента са нужни препращане, NAT правило за пула на изходящия канал и DNS, който клиентът наистина може да заяви, след като връзката е вдигната. Пулът също трябва да стои далеч от диапазона на LAN, иначе отговорите, адресирани до клиентите, се доставят локално, вместо да бъдат изтласкани обратно в тунела.

На сървъра включете препращането с sysctl -w net.ipv4.ip_forward=1, преведете пула с iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, после приемайте изходящия тунелен трафик с FORWARD правило за -i ppp0 -o eth0 и връщащия се трафик с огледалното правило плюс -m state --state RELATED,ESTABLISHED. Запазете тези правила през рестартиранията, защото сървър, който се връща без тях, изглежда точно като счупена L2TP конфигурация.

Достигането до собствената LAN на сървъра е друга задача: добавете обратен маршрут за пула на LAN рутера или proxy ARP на сървъра. Скриването на клиентите зад NAT, когато нещо в LAN трябва да се обръща към тях директно, просто насрочва втора сесия за отстраняване на проблеми по-късно.

Какво голият стек не прави и как да го проверите

Никоя част от този стек не криптира PPP кадрите и нищо в него не удостоверява отсрещната страна като сървъра, който наистина сте избрали. MS-CHAPv2 наистина предпазва обмена на данни за достъп от слушател, който само наблюдава, но нападател, разположен на пътя, все още може да се намеси в сесията. Родният клиент на Windows предлага L2TP само в комбинация с IPsec, така че предвидете Linux, фърмуер на рутери и клиенти от трети страни като ваши партньори. Отнасяйте се към голата конфигурация като диагностична стъпало, никога като мястото за спиране.

Проверете в фиксиран ред: пуснете xl2tpd -D на преден план, наблюдавайте журнала за етапа на PPP, прочетете зададения адрес от ip addr от двете страни, после хванете UDP 1701, за да потвърдите, че данните текат след установяване на сесията. Ако и четирите съвпадат, а трафикът все още се проваля, вината е в маршрутизация, NAT или MTU, а не в самия L2TP.