SSTP-tydsverloop of sertifikaatfout: hoe om die twee te onderskei

SSTP-verbinding misluk op twee maniere wat van die gebruiker se stoel af dieselfde lyk, en die herstel vir elkeen lê op ’n ander laag. ’n Tydsverloop beteken dat ’n vereiste uitruiling nooit klaargekom het nie; ’n sertifikaatfout beteken dat identiteitsmateriaal aangekom het en verwerp is. Om die tweede soos die eerste te behandel, stuur jou na firewalls en wagwoorde wat nooit die probleem was nie. Die onderskeidende bewys is in die kliënt se eie log, as jy dit lees voordat jy iets verander.

Twee mislukkings, twee verskillende uitruilings

SSTP dra ’n tonnel binne ’n HTTPS-vormige sessie, en daarom oorleef dit netwerke wat net 443 toelaat. Die kliënt voltooi ’n TLS-handdruk, stuur ’n HTTP-versoek met ’n protokolspesifieke metode, en dan loop die tonnel binne daardie stroom. ’n Mislukking by enige van daardie stappe stop die verbinding, en net die later stappe behels geloofsbriewe.

Daardie volgorde is die diagnose. As die TLS-handdruk nooit voltooi nie, is geen geloofsbrief gestuur nie, so ’n wagwoordherstel kan nie help nie. As die handdruk voltooi en dan vasdraai, is identiteit aanvaar en iets in die versoekpad het dit geweier. As die handdruk met ’n valideringsboodskap misluk, het die bediener geantwoord en die kliënt het nie gehou van wat hy gehoor het nie. Drie uitkomste, drie lae.

Die logreël noem gewoonlik in watter van die drie jy is, en daarom is dit die moeite werd om dit vas te vang voor die eerste verandering.

’n Tydsverloop beteken ’n stadium het nooit klaargekom nie

Begin met naamopossing en TCP-bereikbaarheid, want ’n tydsverloop daar lyk identies aan ’n tydsverloop later. ’n Poortkontrole wat 443 oop rapporteer, bewys dat ’n luisteraar ’n verbinding aanvaar het, en niks verder nie.

Die volgende verdagte is die pad eerder as die gasheer. Volmagte en firewalls wat toepassings verstaan, weier soms die versoekmetode wat SSTP gebruik, of laat ’n stroom val wat ure lank oop bly, en albei gedrag lyk soos ’n tydsverloop van die kliënt se kant. ’n Generiese HTTPS-bladsy wat deur dieselfde gasheer bedien word, laai perfek terwyl die tonnelmetode geweier word, en daarom bewys blaai na die eindpunt so min. Toets van ’n netwerk sonder die volmag om daardie twee gevalle te skei.

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

’n Tydsverloop voor enige antwoord van ’n eweknie sê niks oor die rekening nie, en om op daardie punt die wagwoord te verander voeg net ’n veranderlike by.

’n Sertifikaatfout beteken identiteit is verwerp

Hier het die bediener wel geantwoord, so die netwerk werk en die vraag skuif na identiteit. Vergelyk die naam wat die kliënt skakel met die name wat die sertifikaat werklik beweer, en kyk dan na geldigheidsdatums en die uitreikketting.

’n Privaat CA wat die kliënt nie vertrou nie, lewer dieselfde klas fout as ’n vervalle sertifikaat, en so ook ’n horlosie wat ure verkeerd is. Om die rou adres te skakel, skep ’n nuwe wanverhouding, want ’n sertifikaat beweer name eerder as adresse. Op ’n bestuurde ontplooiing, kry die beoogde vertrouenskonfigurasie by sy administrateur in plaas daarvan om ’n vervangingswortel te aanvaar wat deur ’n foutbladsy aangebied word. Validasie bly aan terwyl jy die oorsaak regmaak.

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

Hou die suksesvolle TLS-stadium ongeskonde sodra dit slaag, want om dit later terug te draai verberg watter verandering die tonnel werklik reggemaak het.

Waar die twee verwar word

Albei mislukkings kom voor as ’n verbinding wat nie opkom nie, en albei kom nadat die gebruiker iets onverwants verander het. Daardie sameloop is wat die verkeerde herstel ’n ruk lank geloofwaardig laat lyk.

Twee gewoontes hou hulle uitmekaar. Neem die kliënt se log vas voordat jy aan die konfigurasie raak, sodat die eerste toestand bewaar bly. Verander een laag per poging, sodat die volgende resultaat aan ’n bekende veranderlike behoort. ’n Poortkontrole en ’n blaaier is gedeeltelike waarnemings eerder as die volle volgorde, en nie een vervang die kliënt se eie verslag nie. Nie een gewoonte kos iets nie, en albei verkort die ondersoek.

Die sertifikaatvraag en die bereikbaarheidsvraag word om ’n rede afsonderlik gedokumenteer.

Toets weer met die regte kliënt, beweeg dan na binne

Sodra die spesifieke regstelling in plek is, probeer weer met die werklike SSTP-kliënt en die regte profiel, nie met ’n blaaier-oortjie nie.

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

As die sessie verbind en hulpbronne steeds misluk, is die tonnel nie meer die verdagte nie: beweeg na roetering, DNS en dienstoegang. Dit is ’n ander ondersoek met ander bewyse. Om die werkende TLS- en verifikasiestadiums te behou, keer dat dit ’n herhaling van die eerste een word. Skryf die stadium wat misluk het in die kaartjie, want die volgende persoon sal anders bo weer begin.