Таймаут при 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 и удостоверителни етапи пречи да се превърне в повторение на първото. Запишете етапа, който се е провалил, в тикета, иначе следващият човек отново ще започне отгоре.