Проброс PPTP отсутствует: исправляем ошибку 807 в Windows VPN

Переадресация TCP 1723 часто открывает первую часть PPTP, а остальное оставляет сломанным, поэтому Windows при попытке всё равно возвращает ошибку 807. Следующий рефлекс — добавить правило для порта 47, и именно этот шаг тратит полдня: GRE — это номер протокола в заголовке IP, а не порт, который может сопоставить таблица переадресации. Пока маршрутизатор не пропустит протокол 47 и не привяжет его к тому же вызову, туннель не может начаться. Разделы ниже разделяют два канала, а затем проверяют их по одному.

В таблице портов нет строки для номера протокола

PPTP использует два разговора, которые сбоят по-разному. Тот, что на TCP 1723, начинает вызов, передаёт информацию о канале и разрывает его, когда пользователь отключается. Сторона данных работает внутри GRE, который заголовок IP помечает номером протокола 47, и внутри этого туннеля PPP согласует канал, пока MS-CHAPv2 проверяет учётные данные.

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

Что сообщает Windows, когда путь данных умирает

Ошибка 807 говорит, что подключение не удалось завершить, а на практике это означает, что вызов дошёл до сервера и канал данных не поднялся. Это вердикт о транспорте, а не об учётной записи. Ошибка 691 — та, что указывает на учётные данные или на несоответствие протокола аутентификации, поэтому она отправляет совсем в другое место.

Работайте с транспортом, прежде чем трогать пароль. Смена учётных данных в погоне за 807 оставляет настоящую неисправность на месте и делает следующую попытку труднее для чтения.

Почему второй клиент ломает работающий туннель

Поскольку портов, которые бы их различали, нет, устройство NAT не может разделить двух клиентов PPTP так, как разделяет два сеанса HTTPS. Поэтому многие потребительские устройства разрешают один вызов PPTP и отслеживают его по адресу источника. Ноутбук, который работал один, перестаёт завершать подключение, как только звонит вторая машина, а со стороны клиента сбой выглядит случайным. Этот шаблон относится к прошивке, и никакое изменение профиля его не изменит.

Наблюдайте за таблицей соединений, пока звонят оба клиента. Если сопоставление всегда держит только первый хост, маршрутизатор достиг предела своих возможностей, и никакая настройка на стороне клиента этого не сдвинет.

Докажите, какая половина сбоит

Убедитесь, что TCP 1723 доходит, прежде чем менять что-либо на маршрутизаторе, потому что этот ответ определяет, какую половину вы проверяете. Запустите это с клиента Windows против собственного имени сервера. Первая команда печатает, ответил ли порт, а вторая звонит без диалога, что делает повторные попытки сопоставимыми.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Истинный результат в проверке порта означает, что канал управления открыт и GRE — оставшийся подозреваемый. Ложный результат означает, что сломаны маршрутизация, фильтр или переадресация, и никакое изменение GRE это не спасёт. За стороной данных нужно наблюдать там, где она видна: на сервере или на маршрутизаторе.

tcpdump -ni any proto 47

Эквивалент в Wireshark — это фильтр отображения ip proto 47, который легче передать тому, кому неуютно в командной строке. GRE, который приходит без ничего в ответ, означает, что обратный путь нужно исправить.

Что на самом деле исправляет ошибку

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Замена PPTP — другой вариант и часто более дешёвый. Маршрутизатор, который сам завершает VPN, избегает двойного NAT для входящих клиентов, а протоколу, который NAT на основе портов уже обрабатывает, проброс вообще не нужен: OpenVPN через UDP, SSTP через TCP 443 или L2TP/IPsec с NAT-T, который заворачивает ESP в UDP 4500. PPTP также зависит от MS-CHAPv2, чьи задокументированные слабости делают его плохим выбором для нового развёртывания даже после исчезновения ошибки.

Запишите, какое правило сделало разницу, потому что тот же объект столкнётся с тем же ограничением, когда второй пользователь попросит доступ. Исправление на уровне протокола относится к сетевым заметкам, куда посмотрит следующий инженер.