Тайм-аут SSTP или ошибка сертификата: как их различить

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

Два сбоя, два разных обмена

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

Этот порядок и есть диагностика. Если рукопожатие TLS никогда не завершается, учётные данные не отправлялись, поэтому сброс пароля не поможет. Если рукопожатие завершается и затем зависает, идентичность была принята, а что-то на пути запроса её отклонило. Если рукопожатие срывается с сообщением проверки, сервер ответил, и клиенту не понравилось услышанное. Три исхода, три уровня.

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

Тайм-аут означает, что этап так и не завершился

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Тайм-аут до любого ответа партнёра ничего не говорит об учётной записи, и смена пароля в этот момент лишь добавляет переменную.

Ошибка сертификата означает, что идентичность была отклонена

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

Частный CA, которому клиент не доверяет, даёт тот же класс ошибки, что и истёкший сертификат, и часы, ушедшие на часы, тоже. Набор по «сырому» адресу создаёт новое несоответствие, потому что сертификат утверждает имена, а не адреса. В управляемом развёртывании получите предусмотренную конфигурацию доверия у администратора, вместо того чтобы принимать заменяющий корень, предлагаемый страницей ошибки. Проверка остаётся включённой, пока вы устраняете причину.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Сохраняйте успешный этап TLS неизменным, когда он пройден, потому что его поздняя отмена скрывает, какое изменение действительно исправило туннель.

Где эти два путаются

Оба сбоя выглядят как соединение, которое не поднимается, и оба приходят после того, как пользователь изменил что-то не связанное. Именно это совпадение делает неверное исправление на время правдоподобным.

Две привычки держат их порознь. Зафиксируйте журнал клиента, прежде чем трогать конфигурацию, чтобы первое состояние сохранилось. Меняйте по одному уровню за попытку, чтобы следующий результат принадлежал известной переменной. Проверка порта и браузер — это частичные наблюдения, а не полная последовательность, и ни одна из них не заменяет собственный отчёт клиента. Ни одна привычка ничего не стоит, и обе сокращают расследование.

Вопрос сертификата и вопрос доступности документированы отдельно не случайно.

Повторите проверку настоящим клиентом, затем идите внутрь

Когда конкретное исправление на месте, повторите попытку настоящим клиентом SSTP и реальным профилем, а не вкладкой браузера.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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