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 и автентикациски фази спречува тоа да стане повторување на првата. Запишете во тикетот која фаза пропаднала, инаку следниот човек повторно ќе почне од врвот.