SSTP за прокси, проверяющим TLS: где обрывается сеанс

Браузер открывает корпоративный интранет, сертификат прокси считается доверенным, и всё же клиент SSTP обрывается ближе к концу соединения. Эта картина указывает на разницу между веб-запросом и сеансом в туннеле, а не на неверный пароль. Пройдите соединение от TCP вверх и отметьте первый этап, который не проходит. Именно этап, а не код ошибки, говорит, виноват ли прокси.

Начните там, где останавливается клиент

Клиент проходит фиксированную последовательность: TCP-соединение с портом 443, рукопожатие TLS, проверка сертификата, HTTP-обмен SSTP, согласование и аутентификация PPP, затем настройка IP. Сбой на каждом этапе оставляет свой след, и их смешение уводит на неверную страницу настройки.

Сбой TCP — это тайм-аут или сброс до появления хотя бы одного байта TLS. Сбой TLS — это предупреждение или тайм-аут рукопожатия. Сбой сертификата даёт предупреждение о цепочке или имени. Сбой HTTP наступает после успешного рукопожатия, часто как код состояния или немедленное закрытие. Сбой PPP наступает после того, как туннель технически установлен, поэтому он выглядит как проблема аутентификации.

Читайте журнал клиента в поисках последнего успешного этапа, а не первой строки ошибки. Строка ошибки обычно сообщает следствие, тогда как граница этапа называет компонент, который отказал.

Что SSTP требует от сети нести

SSTP работает поверх TLS на TCP 443 и затем отправляет HTTP-запрос SSTP_DUPLEX_POST, определённый в спецификации SSTP, на путь вида /sra_{GUID}/. Запрос объявляет практически неограниченную длину содержимого и держит поток открытым в обе стороны на всё время сеанса. Кадры PPP путешествуют внутри этого потока.

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

Фильтрация методов и аутентификация добавляют собственные режимы отказа. Если прокси запрашивает учётные данные, клиент VPN может не ответить, хотя браузер ответил бы. Если он удаляет или переписывает метод, шлюз отклоняет запрос до начала PPP.

Почему проверка меняет личность

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

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

Поэтому добавление неизвестного корня или отключение проверки — неправильное лечение. Это меняет то, какой сертификат принимает клиент; на обработку потока, которая на самом деле сломала сеанс, это не влияет.

Определите издателя до изменения настроек

Спросите у конечной точки, какой сертификат она предъявляет и кто его подписал. Команды ниже показывают цепочку и издателя, не запуская сеанс VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

Тест браузера к тому же хосту доказывает лишь то, что прокси принимает GET. Он ничего не говорит о методе SSTP, URI запроса или времени жизни тела, поэтому не считайте работающую страницу интранета доказательством поддержки пути туннеля.

Выберите поддерживаемый путь

Задайте владельцу сети один конкретный вопрос: разрешает ли прокси небуферизованный дуплексный POST к этому шлюзу на порту 443? Ответ «да» ведёт к исключению в прокси или документированному обходу для хоста VPN. Ответ «нет» означает, что проверяемый путь не может нести SSTP, и поддерживаемое решение — другой путь или протокол, а не доделка клиента.

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

Задокументируйте результат: издатель, сбойный этап, правило прокси и выбранный путь. Следующий человек, увидев ту же остановку на 98 процентах, сможет проверить один факт вместо повторения всего прохода.