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.