Сервер PPTP за домашним роутером: сначала почините 1723 и GRE

PPTP за домашним роутером отказывает двумя несвязанными способами, и путаница между ними стоит целого вечера. Один сбой — пробел в перенаправлении: роутер пропускает TCP 1723 и отбрасывает протокол IP 47, поэтому клиент висит на ошибке 619. Другой — проблема размера: туннель поднимается, проходит аутентификацию, а затем зависает, когда должен пройти пакет полного размера. Выяснить, какой из них у вас, — первый настоящий шаг; остальное сравнивает, что способен выразить ваш роутер, а не какая марка лучше.

Два транспорта, и только у одного есть порт

PPTP делится на два транспорта: управляющее соединение на TCP 1723 и кадры PPP, упакованные в расширенный GRE, то есть протокол IP 47. У GRE нет номера порта, поэтому правило, записанное как проброс порта 1723, не может его покрыть, как бы веб-интерфейс ни называл поле. Домашний роутер обычно предлагает галочку с названием проброс PPTP вместо правила протокола, и эта галочка делает две вещи: пропускает протокол 47 через межсетевой экран и учит NAT отслеживать поток GRE. На Linux-роутере эти работы — отдельные модули и отдельные правила, поэтому наполовину настроенный проброс всё равно даёт работающий канал управления. Выясните, какая половина присутствует, прежде чем что-либо менять.

Собственный межсетевой экран сервера тоже должен разрешать протокол 47 с адреса роутера. Межсетевой экран хоста, который принимает только 1723/tcp, воспроизводит ошибку 619 изнутри LAN, и поэтому сломанный проброс и сломанное правило хоста выглядят одинаково.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Если модули отсутствуют, загрузите их через sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre и сделайте загрузку постоянной, потому что перезагрузка, забывшая помощник, снова превращает работающий туннель в ошибку 619. Правило проброса должно принимать протокол 47 только к адресу сервера, а не ко всей LAN. Определение в RFC 2637 разделяет путь управления и путь данных, поэтому ни один экран проброса портов не описывает PPTP полностью.

Галочка проброса или явное правило протокола

Галочка проброса, которая только открывает межсетевой экран, ближе к правильному, чем ALG, переписывающий идентификаторы вызова. Половина с межсетевым экраном предсказуема, потому что протокол 47 либо принимается, либо отбрасывается, и счётчики говорят, что именно. Половина с переписыванием — это место, где производители различаются, потому что идентификаторы вызова PPTP задаются для каждого туннеля, и NAT, который их редактирует, обязан отслеживать каждый затронутый вызов. Когда один клиент подключается, а два нет, ALG — первый подозреваемый.

Правило NAT назначения для 1723 тоже несёт проблему владельца. Если старое правило всё ещё отправляет 1723 на хост, который перестал запускать сервер, пакеты попадают на закрытый порт, и собственная служба PPTP роутера перестаёт отвечать, что читается как отказ межсетевого экрана, но в действительности является устаревшей целью. Прочитайте правило и его назначение, прежде чем добавлять второе. На роутерах, которые сами завершают PPTP, правило WAN конкурирует со встроенной службой, поэтому выберите одного владельца для 1723 и протокола 47.

Два клиента за одним NAT — это случай, который отделяет простой проброс от умного. Проброс протокола 47 без переписывания идентификаторов вызова обычно ведёт себя лучше, чем помощник, который пытается их исправить.

Измерьте туннель, прежде чем винить роутер

PPTP уменьшает полезную нагрузку, и это уменьшение — арифметика, а не загадка. Каждый пакет туннеля несёт внешний заголовок IP, расширенный заголовок GRE, заголовок PPP и, при шифровании, заголовок MPPE. Когда путь не может провести получившийся кадр, маленькие пакеты проходят, вход завершается, а сеанс останавливается в первый раз, когда передача файла или рукопожатие TLS отправляет пакет полного размера.

Посчитайте число вместо того, чтобы гадать. Расширенный GRE стоит 8 байт, PPP — 4, MPPE — 4, а внешний заголовок IP — 20, поэтому туннель съедает 36 байт до любой нагрузки. На WAN с PPPoE, который заканчивается на 1492, наибольший помещающийся PPP MTU — это 1492 минус 36, то есть 1456. Задайте mtu и mru это значение в параметрах PPP и проверьте снова пингом без фрагментации.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Пинг измеряет путь, а не туннель: 1464 байта нагрузки плюс 28 байт заголовков IP и ICMP точно заполняют кадр в 1492 байта. Если этот пинг не проходит, снижайте число, пока он не пройдёт, и вычтите 36 из результата. MTU туннеля, заданный выше предела пути, вызывает зависание без единой строки журнала, где упоминался бы размер.

PPTP, L2TP/IPsec или OpenVPN на одном роутере

Один и тот же роутер может нести любой из трёх обычных туннелей, и разница в том, что он должен выразить. PPTP требует двух правил в двух разных уровнях. L2TP поверх IPsec требует UDP 500 и 4500 для обмена ключами и, если NAT-T его не несёт, протокол 50 для нагрузки. OpenVPN требует один порт UDP и вообще не требует помощника.

Столбец L2TP не является автоматически дружелюбнее GRE. ESP — это протокол IP 50, и у него тоже нет порта, поэтому роутер, испытывающий трудности с протоколом 47, может испытывать их и с протоколом 50 по той же причине. NAT-T существует, чтобы завернуть ESP внутрь UDP 4500, и когда оба конца его поддерживают, правило протокола 50 становится ненужным. Это свойство концов, а не галочки PPTP на роутере. Подтвердите, какую инкапсуляцию клиент действительно согласовал, прежде чем писать правила для обеих.

OpenVPN — вариант с наименьшим числом движущихся частей на стороне роутера. Один порт UDP, один проброс, никакого помощника слежения за соединениями и никакого переписывания идентификаторов вызова. В обмен нужен клиент, который надо установить, вместо встроенного дозвонщика, и часто это единственная причина, по которой PPTP остаётся в разговоре.

Что чинить и что заменять

Починка проброса и MTU даёт работающий туннель, а не тот, который стоит сохранять. Аутентификация MSCHAPv2 в PPTP уязвима уже много лет, а работающий туннель передаёт учётные данные, которые можно восстановить офлайн. Если удалённое устройство умеет запускать L2TP/IPsec или OpenVPN, считайте ремонт временной мерой с датой.

Решение сводится к тому, что поддерживает дальний конец и как долго должна продержаться схема. Старое устройство, говорящее только PPTP, получает ремонт; всё, куда можно установить клиент, мигрирует.

Прежде чем закрыть заявку, подтвердите, что клиент переживает большую передачу, а не только вход, и что роутер после перезагрузки по-прежнему держит правило протокола 47. Туннель, который проходит одну копию файла и умирает после следующего обновления прошивки, никогда не был завершён.