Ошибка PPTP 800 против 812 и обрывы через минуту

Ошибка 800, ошибка 812 и туннель PPTP, умирающий через минуту, — это три разные неисправности. Сопоставьте каждый симптом слою, который действительно отказал.

Три сообщения об ошибке от одного клиента PPTP обычно описывают три разные неисправности. Ошибка 800 означает, что туннель так и не сформировался, ошибка 812 означает, что сервер отклонил метод проверки подлинности, а обрыв через минуту — это таймер keepalive, который решает, что здоровый партнёр исчез. Каждый этап срывается по своей причине, поэтому каждому нужна своя проверка.

Ошибка 800 означает, что туннель так и не сформировался

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

Проверьте этот внешний путь извне собственной локальной сети, потому что соединение, работающее в офисе, ничего не доказывает о крае:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

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

Направьте перенаправление на текущий адрес сервера в локальной сети, включите пропуск PPTP там, где маршрутизатор его предлагает, и повторите попытку из той же внешней точки. Когда GRE фильтруется выше и вы не можете это изменить, у SSTP через TCP 443 или L2TP/IPsec через UDP 500 и 4500 больше шансов, чем у любого изменения на стороне Windows.

Ошибка 812 — это отказ сервера от вашего метода проверки подлинности

Ошибка 812 возвращается после того, как туннель поднят, поэтому кажется проблемой пароля. Сервер отклоняет согласованный для соединения метод проверки подлинности, а не обязательно сам пароль. На клиенте откройте запись VPN, перейдите на вкладку безопасности, задайте тип Point-to-Point Tunneling Protocol, выберите явный список протоколов и отметьте Microsoft CHAP версии 2.

Текущий параметр можно прочитать, не щёлкая по диалогу:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Сервер, требующий MS-CHAP v2, отклоняет клиента, оставленного на PAP или на автоматическом типе, который согласует что-то более слабое, и ошибка приходит до оценки любого пользовательского пароля. Формат учётной записи — вторая половина того же отказа. В одном случае Windows отправил удостоверение учётной записи Microsoft вида MicrosoftAccount\[email protected], тогда как серверу нужна была локальная или доменная учётная запись. Ввод SERVERNAME\username сообщил Windows, к какому хранилищу учётных записей обращаться, и убрал ошибку. Введите имя вручную, вместо того чтобы сохранённые учётные данные повторяли прежний формат.

Обрывы через минуту — это решение keepalive

Когда туннель подключается, пропускает немного трафика и затем отключается, посмотрите на поведение эха LCP сервера, прежде чем трогать клиента. Демон периодически просит партнёра подтвердить, что тот ещё на месте. Если в заданном бюджете приходит слишком мало ответов, сеанс сбрасывается, хотя у пользователя ещё есть рабочее соединение.

На сервере Linux pptpd эти значения живут в /etc/ppp/options.pptpd, и обычный ремонт — расширить бюджет, а не сокращать интервал:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Тридцать промахов при интервале в пять секунд прощают короткую заминку, вместо того чтобы объявлять партнёра исчезнувшим. Снижение числа до одного или двух превращает обычный джиттер на транслируемом пути в отключение примерно каждую минуту. Если ваш сервер — Windows RRAS, а не pptpd, смотрите вместо этого тайм-аут сеанса PPP и политику отключения при простое. Они живут в другом месте, и правка несуществующего файла pppd ничего не изменит.

Перекрывающиеся подсети ломают путь данных

Туннель PPTP может чисто пройти проверку подлинности и всё равно никуда не попасть, когда оба сайта используют один и тот же частный диапазон, например 192.168.1.0/24 в офисе и дома. Клиент не может сказать, к какому узлу относится данный адрес, а некоторые стеки вообще отказываются устанавливать маршрут, вместо того чтобы выбрать один.

Считайте это ошибкой проектирования и перенумеруйте одну сторону либо выдайте клиенту намеренно транслированный диапазон доступа. Отладка клиента PPTP не исправит адресное пространство, существующее дважды, и симптом будет по-прежнему выглядеть как случайный обрыв.

Начните с этапа, который отказал: GRE для 800, метод и строка учётной записи для 812, настройки эха для туннеля, умирающего по расписанию.

Похожие статьи