SSTP istek vremena ili greška certifikata: kako ih razlikovati
Izostali odgovor i odbijeni TLS identitet traže različite popravke. Odvojite SSTP fazu od provjere certifikata prije nego što bilo šta promijenite.
SSTP veza pada na dva načina koji sa korisnikove stolice izgledaju isto, a popravka za svaki leži na drugom sloju. Istek vremena znači da potrebna razmjena nikada nije završena; greška certifikata znači da je identitetski materijal stigao i odbijen. Ako drugo tretirate kao prvo, idete prema firewallima i lozinkama koji nikada nisu bili problem. Razlikovni dokaz je u klijentovom vlastitom logu, ako ga pročitate prije nego što bilo šta promijenite.
Dva neuspjeha, dvije različite razmjene
SSTP nosi tunel unutar sesije oblika HTTPS, zato preživljava mreže koje ne dopuštaju ništa osim 443. Klijent završi TLS rukovanje, pošalje HTTP zahtjev s metodom specifičnom za protokol, a zatim tunel teče unutar tog toka. Neuspjeh na bilo kojem od tih koraka zaustavlja vezu, a samo kasniji uključuju vjerodajnice.
Taj redoslijed je dijagnostika. Ako se TLS rukovanje nikad ne završi, nikakve vjerodajnice nisu poslane, pa reset lozinke ne može pomoći. Ako se rukovanje završi i zatim zapne, identitet je prihvaćen i nešto na putu zahtjeva ga je odbilo. Ako rukovanje padne s porukom provjere, server je odgovorio i klijentu se nije svidjelo ono što je čuo. Tri ishoda, tri sloja.
Log linija obično kaže u kojem ste od tri slučaja, zato je vrijedi zabilježiti prije prve promjene.
Istek vremena znači da faza nikada nije završena
Počnite s razrješavanjem imena i TCP dostupnošću, jer istek vremena tamo izgleda identično kao kasniji istek. Provjera porta koja javi da je 443 otvoren dokazuje da je slušalac prihvatio vezu i ništa više.
Sljedeći sumnjivac je put, a ne host. Proxyji i firewalli svjesni aplikacija ponekad odbiju metodu zahtjeva koju SSTP koristi ili ispuste tok koji ostaje otvoren satima, a oba ponašanja izgledaju kao istek vremena s klijentove strane. Obična HTTPS stranica koju poslužuje isti host učitava se besprijekorno dok je metoda tunela odbijena, zato pretraživanje krajnje točke dokazuje tako malo. Testirajte s mreže bez proxyja da razdvojite ta dva slučaja.
Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20
Istek vremena prije bilo kakvog odgovora druge strane ne govori ništa o računu, a promjena lozinke u tom trenutku samo dodaje varijablu.
Greška certifikata znači da je identitet odbijen
Ovdje je server zaista odgovorio, pa mreža radi i pitanje se seli na identitet. Uporedite ime s kojim se klijent javlja s imenima koja certifikat stvarno tvrdi, zatim provjerite datume valjanosti i lanac izdavaoca.
Privatni CA kojem klijent ne vjeruje proizvodi istu klasu greške kao istekao certifikat, a tako i sat koji kasni satima. Biranje sirove adrese stvara novu nepodudarnost, jer certifikat tvrdi imena, a ne adrese. U upravljanom postavljanju zatražite predviđenu konfiguraciju povjerenja od njenog administratora umjesto da prihvatite zamjenski korijen koji nudi stranica greške. Validacija ostaje uključena dok popravljate uzrok.
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
Držite uspješnu TLS fazu netaknutom kad prođe, jer njeno kasnije poništavanje skriva koja je promjena stvarno popravila tunel.
Gdje se te dvije pobrkaju
Oba neuspjeha izgledaju kao veza koja se ne diže, a oba dolaze nakon što je korisnik promijenio nešto nepovezano. Ta slučajnost čini pogrešnu popravku uvjerljivom neko vrijeme.
Dvije navike ih drže odvojenima. Zabilježite klijentov log prije nego što dotaknete konfiguraciju, da prvo stanje ostane sačuvano. Mijenjajte jedan sloj po pokušaju, da sljedeći rezultat pripada poznatoj varijabli. Provjera porta i preglednik su djelomična opažanja, a ne cijeli slijed, i nijedno ne zamjenjuje klijentov vlastiti izvještaj. Nijedna navika ništa ne košta, a obje skraćuju istragu.
Pitanje certifikata i pitanje dostupnosti dokumentirani su odvojeno s razlogom.
Ponovo testirajte pravim klijentom, zatim idite prema unutra
Kad je konkretna ispravka na mjestu, pokušajte ponovo sa stvarnim SSTP klijentom i pravim profilom, a ne s karticom preglednika.
rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod
Ako se sesija poveže, a resursi i dalje ne rade, tunel više nije sumnjivac: prijeđite na usmjeravanje, DNS i pristup uslugama. To je druga istraga s drugim dokazima. Očuvanje radnih TLS i autentifikacijskih faza sprječava da to postane ponavljanje prve. Zapišite u tiket fazu koja je pala, jer će sljedeća osoba inače opet početi od vrha.