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, а четверте може закріпити конкретну адресу з пулу.

Чому тунель підключається і потім зупиняється

Кадр Ethernet розміром 1500 байтів не вміщується в шлях, який уже витрачає байти на власні заголовки. Зовнішній заголовок 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.