SSTP-tempatigo aŭ atestila eraro: kiel distingi ilin

Konekto SSTP malsukcesas duamaniere, kiuj aspektas samaj de la seĝo de la uzanto, kaj la riparo por ĉiu kuŝas sur malsama tavolo. Tempatigo signifas, ke bezonata interŝanĝo neniam finiĝis; atestila eraro signifas, ke identaĵa materialo alvenis kaj estis rifuzita. Se vi traktas la duan kiel la unuan, vi iras al fajroŝirmiloj kaj pasvortoj, kiuj neniam estis la problemo. La distinga pruvo estas en la propra protokolo de la kliento, se vi legas ĝin antaŭ ol ŝanĝi ion.

Du malsukcesoj, du malsamaj interŝanĝoj

SSTP portas tunelon ene de seanco laŭ formo de HTTPS, tial ĝi postvivas en retoj, kiuj permesas nenion krom 443. La kliento kompletigas TLS-manpremon, sendas HTTP-peton kun protokol-specifa metodo, kaj poste la tunelo funkcias ene de tiu fluo. Malsukceso ĉe iu ajn el tiuj paŝoj haltigas la konekton, kaj nur la lastaj koncernas akreditaĵojn.

Tiu ordo estas la diagnozo. Se la TLS-manpremo neniam kompletiĝas, neniu akreditaĵo estis sendita, do pasvorta restarigo ne povas helpi. Se la manpremo kompletiĝas kaj poste haltas, la identeco estis akceptita kaj io en la peta vojo rifuzis ĝin. Se la manpremo malsukcesas kun validiga mesaĝo, la servilo respondis kaj la kliento ne ŝatis tion, kion ĝi aŭdis. Tri rezultoj, tri tavoloj.

La protokola linio kutime nomas, en kiu el la tri vi estas, tial indas kapti ĝin antaŭ la unua ŝanĝo.

Tempatigo signifas, ke etapo neniam finiĝis

Komencu per nomsolvado kaj TCP-atingebleco, ĉar tempatigo tie aspektas idente al tempatigo poste. Pordokontrolilo, kiu raportas 443 malfermita, pruvas, ke aŭskultanto akceptis konekton, kaj nenion pli.

La sekva suspektato estas la vojo, ne la gastiganto. Prokuriloj kaj aplikaĵ-konsciaj fajroŝirmiloj foje rifuzas la petmetodon, kiun SSTP uzas, aŭ faligas fluon, kiu restas malfermita dum horoj, kaj ambaŭ kondutoj aspektas kiel tempatigo de la klienta flanko. Ordinara HTTPS-paĝo servata de la sama gastiganto ŝarĝiĝas perfekte dum la tunela metodo estas rifuzata, tial retumi al la finpunkto pruvas tiel malmulte. Testu el reto sen la prokurilo por apartigi tiujn du kazojn.

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

Tempatigo antaŭ iu ajn respondo de la kunulo diras nenion pri la konto, kaj ŝanĝi la pasvorton tiutempe nur aldonas variablon.

Atestila eraro signifas, ke la identeco estis rifuzita

Ĉi tie la servilo ja respondis, do la reto funkcias kaj la demando moviĝas al identeco. Komparu la nomon, kiun la kliento vokas, kun la nomoj, kiujn la atestilo efektive asertas, poste kontrolu la validajn datojn kaj la eldonan ĉenon.

Privata CA, kiun la kliento ne fidas, produktas la saman klason de eraro kiel eksvalidiĝinta atestilo, kaj same horloĝo, kiu eraras je horoj. Voki la krudan adreson kreas novan malkongruon, ĉar atestilo asertas nomojn, ne adresojn. En administrata enkonduko, prenu la celitan fido-agordon de ĝia administranto anstataŭ akcepti anstataŭan radikon proponitan de erarpaĝo. Validado restas ŝaltita dum vi riparas la kaŭzon.

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

Konservu la sukcesan TLS-etapon senŝanĝa post kiam ĝi pasas, ĉar malfari ĝin poste kaŝas, kiu ŝanĝo efektive riparis la tunelon.

Kie la du konfuziĝas

Ambaŭ malsukcesoj prezentiĝas kiel konekto, kiu ne leviĝas, kaj ambaŭ alvenas post kiam la uzanto ŝanĝis ion nerilatan. Ĝuste tiu koincido igas la malĝustan riparon ŝajni kredinda dum tempo.

Du kutimoj tenas ilin apartaj. Kaptu la klientan protokolon antaŭ ol tuŝi la agordon, por ke la unua stato konserviĝu. Ŝanĝu unu tavolon po provo, por ke la sekva rezulto apartenu al konata variablo. Pordokontrolilo kaj retumilo estas partaj observoj anstataŭ la plena sinsekvo, kaj neniu el ili anstataŭas la propran raporton de la kliento. Neniu el la kutimoj kostas ion, kaj ambaŭ mallongigas la esploron.

La atestila demando kaj la atingebleca demando estas dokumentitaj aparte pro kialo.

Retestu per la vera kliento, poste moviĝu internen

Post kiam la konkreta korekto estas en loko, reprovu per la efektiva SSTP-kliento kaj la reala profilo, ne per retumila langeto.

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

Se la seanco konektiĝas kaj rimedoj ankoraŭ malsukcesas, la tunelo jam ne estas suspektato: transiru al enkursigado, DNS kaj serva aliro. Tio estas alia esploro kun aliaj pruvoj. Konservi la funkciantajn TLS- kaj aŭtentikigajn etapojn malhelpas, ke ĝi fariĝu ripeto de la unua. Skribu la etapon, kiu malsukcesis, en la bileton, ĉar alie la sekva persono denove komencos ĉe la supro.