SSTP-aikakatkaisu vai varmennevirhe: miten erottaa ne toisistaan

SSTP-yhteys epäonnistuu kahdella tavalla, jotka näyttävät käyttäjän tuolilta samalta, ja kummankin korjaus on eri kerroksessa. Aikakatkaisu tarkoittaa, että vaadittu vaihto ei koskaan valmistunut; varmennevirhe tarkoittaa, että identiteettimateriaalia saapui ja se hylättiin. Jos kohtelet jälkimmäistä kuin ensimmäistä, päädyt palomuureihin ja salasanoihin, jotka eivät koskaan olleet ongelma. Erottava todiste on asiakkaan omassa lokissa, jos luet sen ennen kuin muutat mitään.

Kaksi epäonnistumista, kaksi erilaista vaihtoa

SSTP kuljettaa tunnelia HTTPS-muotoisen istunnon sisällä, siksi se selviää verkoissa, jotka eivät salli muuta kuin 443:n. Asiakas suorittaa TLS-kättelyn loppuun, lähettää HTTP-pyynnön protokollakohtaisella menetelmällä, ja sitten tunneli kulkee sen virran sisällä. Epäonnistuminen missä tahansa näistä vaiheista pysäyttää yhteyden, ja vain myöhemmät koskevat tunnistetietoja.

Tuo järjestys on diagnoosi. Jos TLS-kättely ei koskaan valmistu, tunnistetietoja ei lähetetty, joten salasanan nollaus ei voi auttaa. Jos kättely valmistuu ja sitten juuttuu, identiteetti hyväksyttiin ja jokin pyynnön polulla hylkäsi sen. Jos kättely epäonnistuu validoinnin viestiin, palvelin vastasi eikä asiakas pitänyt kuulemastaan. Kolme lopputulosta, kolme kerrosta.

Lokirivi yleensä kertoo, kummassa kolmesta olet, siksi se kannattaa tallentaa ennen ensimmäistä muutosta.

Aikakatkaisu tarkoittaa, että vaihe ei koskaan valmistunut

Aloita nimien selvityksestä ja TCP-tavoitettavuudesta, koska aikakatkaisu siellä näyttää samalta kuin myöhempi aikakatkaisu. Porttitarkistin, joka ilmoittaa 443:n olevan auki, todistaa vain, että kuuntelija otti yhteyden vastaan, ei mitään sen enempää.

Seuraava epäilty on polku eikä isäntä. Välityspalvelimet ja sovellustietoiset palomuurit hylkäävät joskus pyyntömenetelmän, jota SSTP käyttää, tai pudottavat virran, joka pysyy auki tunteja, ja molemmat käytökset näyttävät asiakkaan puolelta aikakatkaisulta. Saman isännän tarjoama tavallinen HTTPS-sivu latautuu moitteettomasti, kun taas tunnelimenetelmä hylätään, siksi päätepisteeseen selaaminen todistaa niin vähän. Testaa verkosta ilman välityspalvelinta, jotta erotat nämä kaksi tapausta.

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

Aikakatkaisu ennen mitään vastapuolen vastausta ei kerro tilistä mitään, ja salasanan vaihtaminen siinä vaiheessa lisää vain yhden muuttujan.

Varmennevirhe tarkoittaa, että identiteetti hylättiin

Tässä palvelin todella vastasi, joten verkko toimii ja kysymys siirtyy identiteettiin. Vertaa nimeä, jolla asiakas soittaa, nimiin, joita varmenne todella väittää, ja tarkista sitten voimassaolopäivät ja myöntäjäketju.

Yksityinen CA, johon asiakas ei luota, tuottaa saman virheluokan kuin vanhentunut varmenne, ja niin tekee myös kello, joka on tunteja väärässä. Raakaan osoitteeseen soittaminen luo uuden ristiriidan, koska varmenne väittää nimiä eikä osoitteita. Hallitussa käyttöönotossa hanki aiottu luottamusasetus sen ylläpitäjältä sen sijaan, että hyväksyisit virhesivun tarjoaman korvaavan juuren. Validointi pysyy päällä, kun korjaat syytä.

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

Pidä onnistunut TLS-vaihe koskemattomana, kun se on mennyt läpi, koska sen myöhempi peruminen kätkee, mikä muutos tunnelin todella korjasi.

Missä nämä kaksi menevät sekaisin

Molemmat epäonnistumiset näkyvät yhteytenä, joka ei nouse, ja molemmat tulevat sen jälkeen, kun käyttäjä on muuttanut jotain asiaankuulumatonta. Juuri tuo sattuma saa väärän korjauksen näyttämään hetken uskottavalta.

Kaksi tapaa pitää ne erillään. Tallenna asiakkaan loki ennen asetusten koskemista, jotta ensimmäinen tila säilyy. Muuta yhtä kerrosta kerrallaan, jotta seuraava tulos kuuluu tunnettuun muuttujaan. Porttitarkistin ja selain ovat osittaisia havaintoja eivätkä koko järjestystä, eikä kumpikaan korvaa asiakkaan omaa raporttia. Kumpikaan tapa ei maksa mitään, ja molemmat lyhentävät tutkintaa.

Varmennekysymys ja tavoitettavuuskysymys on dokumentoitu erikseen syystä.

Testaa uudelleen oikealla asiakkaalla ja siirry sitten sisäänpäin

Kun konkreettinen korjaus on paikallaan, yritä uudelleen varsinaisella SSTP-asiakkaalla ja oikealla profiililla, älä selaimen välilehdellä.

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

Jos istunto yhdistää ja resurssit silti epäonnistuvat, tunneli ei ole enää epäilty: siirry reititykseen, DNS:ään ja palveluiden käyttöön. Se on toinen tutkinta toisilla todisteilla. Toimivien TLS- ja todennusvaiheiden säilyttäminen estää sitä toistamasta ensimmäistä. Kirjoita tikettiin vaihe, joka epäonnistui, muuten seuraava henkilö aloittaa taas alusta.