PPTP через хот-спот: TCP 1723 — это лишь половина

Пройдите проверки по порядку: открывается ли управляющее соединение, выживает ли GRE на пути, принимает ли сервер вызов и завершается ли аутентификация. Клиенту PPTP нужны и сеанс TCP на 1723, и путь GRE, несущий данные, а хот-спот может пропустить одно и отбросить другое. Выполнение их по порядку подскажет, какую границу исследовать, вместо догадок. Номера ошибок Windows этого за вас не делают.

GRE — это IP-протокол 47. Это не порт 47 TCP или UDP, и это различие объясняет большую часть путаницы вокруг межсетевых экранов.

Два пути, одно соединение

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

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

Хот-спот добавляет ещё две границы

Клиентский трафик обычно проходит через собственный NAT телефона, а затем через трансляцию уровня оператора, прежде чем достичь сервера. Правило на офисном маршрутизаторе не может исправить промежуточное устройство, принадлежащее кому-то другому, поэтому перенаправление портов со стороны дома редко помогает. Исходящему клиенту также не нужен открытый входящий порт; ответы на транслированное соединение возвращаются через состояние, созданное шлюзом. У сервера, размещённого за NAT, совсем другой набор требований.

Пункт меню с названием PPTP passthrough, где он есть, определяет, как это устройство обрабатывает данный протокол. Это не та же функция, что размещение VPN на телефоне или безусловная передача каждого протокола, и его включение не является общим разрешением пропускать GRE.

Читайте 807 как перерыв, а не приговор

Windows сообщает 807 как прерванное соединение, что описывает результат, а не причину. Его таблица ошибок рассматривает 806 отдельно как категорию, связанную с GRE, и это различие стоит знать до построения теории. Ни одно из чисел не раскрывает, фильтровал ли оператор протокол 47, закончилась ли у сервера ёмкость или были ли верны учётные данные. Ошибка говорит, что сеанс завершился; путь говорит, где.

Успешный тест браузера на хот-споте доказывает лишь то, что работает обычный путь приложения. О GRE он не говорит ничего.

Изолируйте этап, который не удался

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

Всё это диагностирует развёртывание, которое уже существует. Это не аргумент за создание новой службы PPTP, и протокол нельзя обойти переговорами: установка другого клиента не заставит неизменённый сервер говорить что-то иное.

Для постоянного доступа согласуйте поддерживаемую миграцию с владельцем VPN. Контрольный список заканчивается решением, а не обходным путём.