SSTP-időtúllépés vagy tanúsítványhiba: hogyan különböztessük meg őket

Egy SSTP-kapcsolat kétféleképpen hibázik, amelyek a felhasználó székéből egyformának látszanak, és a javításuk más-más rétegen van. Az időtúllépés azt jelenti, hogy egy szükséges csere soha nem fejeződött be; a tanúsítványhiba azt jelenti, hogy identitás-anyag érkezett és elutasították. Ha a másodikat az elsőként kezeli, olyan tűzfalakhoz és jelszavakhoz jut, amelyek soha nem voltak a probléma. A megkülönböztető bizonyíték az ügyfél saját naplójában van, ha elolvassa, mielőtt bármit módosít.

Két hiba, két különböző csere

Az SSTP egy HTTPS alakú munkameneten belül hordoz alagutat, ezért éli túl azokat a hálózatokat, amelyek csak a 443-at engedik. Az ügyfél befejez egy TLS-kézfogást, HTTP-kérést küld protokolspecifikus metódussal, majd az alagút ezen a folyamon belül fut. Bármelyik lépés hibája megállítja a kapcsolatot, és csak a későbbiek érintenek hitelesítő adatokat.

Ez a sorrend a diagnózis. Ha a TLS-kézfogás soha nem fejeződik be, nem küldtek hitelesítő adatot, így a jelszó-visszaállítás nem segíthet. Ha a kézfogás befejeződik, majd megakad, az identitást elfogadták, és valami a kérés útvonalán elutasította. Ha a kézfogás érvényesítési üzenettel hibázik, a kiszolgáló válaszolt, és az ügyfélnek nem tetszett, amit hallott. Három eredmény, három réteg.

A naplósor általában megmondja, melyikben van a három közül, ezért érdemes rögzíteni az első változtatás előtt.

Az időtúllépés azt jelenti, hogy egy szakasz soha nem fejeződött be

Kezdje a névfeloldással és a TCP elérhetőséggel, mert az ottani időtúllépés pontosan úgy néz ki, mint egy későbbi. A 443 nyitottságát jelentő portellenőrző csak azt bizonyítja, hogy egy figyelő elfogadott egy kapcsolatot, és semmi többet.

A következő gyanúsított az útvonal, nem a gazdagép. A proxyk és az alkalmazásokat ismerő tűzfalak néha elutasítják azt a kérési metódust, amelyet az SSTP használ, vagy eldobnak egy órákig nyitva maradó folyamot, és mindkét viselkedés időtúllépésnek látszik az ügyfél oldaláról. Egy ugyanazon gazdagép által kiszolgált közönséges HTTPS-oldal hibátlanul betöltődik, miközben az alagútmetódust elutasítják, ezért bizonyít olyan keveset a végpontra böngészés. Teszteljen proxy nélküli hálózatról, hogy szétválassza ezt a két esetet.

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

A partner bármilyen válasza előtti időtúllépés semmit nem mond a fiókról, és a jelszó módosítása abban a pillanatban csak egy változót ad hozzá.

A tanúsítványhiba azt jelenti, hogy az identitást elutasították

Itt a kiszolgáló valóban válaszolt, tehát a hálózat működik, és a kérdés átkerül az identitásra. Hasonlítsa össze a nevet, amelyre az ügyfél tárcsáz, azokkal a nevekkel, amelyeket a tanúsítvány valóban állít, majd ellenőrizze az érvényességi dátumokat és a kiállítási láncot.

Egy privát CA, amelyben az ügyfél nem bízik, ugyanazt a hibaosztályt állítja elő, mint egy lejárt tanúsítvány, és így tesz egy órákkal tévedő óra is. A nyers címre tárcsázás új eltérést teremt, mert a tanúsítvány neveket állít, nem címeket. Felügyelt telepítésnél a szándékolt bizalmi konfigurációt a rendszergazdájától kérje, ahelyett hogy elfogadna egy hibaoldal által kínált csere-gyökeret. Az érvényesítés bekapcsolva marad, amíg az okot javítja.

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

Tartsa érintetlenül a sikeres TLS-szakaszt, miután átmegy, mert a későbbi visszavonása elrejti, melyik változtatás javította valójában az alagutat.

Ahol a kettő összekeveredik

Mindkét hiba olyan kapcsolatként jelenik meg, amely nem jön fel, és mindkettő azután jön, hogy a felhasználó valami oda nem tartozót módosított. Ez a véletlen egybeesés teszi egy ideig hihetővé a rossz javítást.

Két szokás tartja őket külön. Rögzítse az ügyfél naplóját, mielőtt a konfigurációhoz nyúl, hogy az első állapot megmaradjon. Kísérletenként egy réteget változtasson, hogy a következő eredmény egy ismert változóhoz tartozzon. A portellenőrző és a böngésző részleges megfigyelések, nem a teljes sorrend, és egyik sem helyettesíti az ügyfél saját jelentését. Egyik szokás sem kerül semmibe, és mindkettő lerövidíti a vizsgálatot.

A tanúsítvány kérdése és az elérhetőség kérdése okkal külön dokumentált.

Teszteljen újra a valódi ügyféllel, aztán haladjon befelé

Amikor a konkrét javítás a helyén van, próbálja újra a tényleges SSTP-ügyféllel és a valódi profillal, ne egy böngészőlappal.

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

Ha a munkamenet csatlakozik, és az erőforrások továbbra is hibáznak, az alagút már nem gyanús: lépjen tovább az útválasztásra, a DNS-re és a szolgáltatáselérésre. Az más vizsgálat más bizonyítékokkal. A működő TLS- és hitelesítési szakaszok megtartása megakadályozza, hogy az első megismétlésévé váljon. Írja a hibajegybe, melyik szakasz hibázott, különben a következő ember megint felülről kezdi.