L'SSTP falla on l'HTTPS del navegador té èxit: per què
L'SSTP funciona dins de TLS al port 443, però no és una petició web. Proveu TCP, la identitat TLS, l'intercanvi SSTP i l'autenticació PPP com a etapes separades.
El navegador obre el nom d'amfitrió de la VPN per HTTPS sense queixar-se, i el client SSTP continua negant-se a connectar-se. No hi ha res contradictori en aquesta parella. L'SSTP utilitza TLS com a transport exterior i després executa la seva pròpia petició i la càrrega PPP dins d'aquesta connexió, així que una pàgina carregada correctament només demostra una cosa molt concreta: l'amfitrió respon un GET al port 443. El client fa una pregunta diferent, i el servidor pot respondre-la malament.
La pàgina carrega i el túnel no
La gent recorre a la prova del navegador perquè és ràpida, i després pren el resultat com a prova que el servidor és abastable i està configurat. És una prova sobre un GET al camí que hagi obert la barra d'adreces, res més. La conversa VPN comença després del mateix handshake TLS, però envia un mètode i un camí que una pàgina web no fa servir mai. Per tant, una resposta 200 per al navegador no diu res sobre si existeix el punt final SSTP.
Separeu les dues observacions i la recerca s'escurça. El transport i la cadena de certificats funcionen, i alguna cosa en l'intercanvi de protocol per sobre no funciona. Aquesta és una investigació diferent de la d'un port trencat o un certificat caducat, i necessita proves diferents.
Què envia realment el client SSTP
El client envia una petició HTTP amb el mètode SSTP_DUPLEX_POST al camí /sra_{GUID}/, i després manté el cos de la connexió obert com un flux bidireccional que transporta trames PPP. Un servidor conforme respon HTTP/1.1 200 i deixa de comportar-se com un servidor web. Qualsevol altra cosa és una signatura: 405 o 404 vol dir que el punt final no hi és, 301 o 302 vol dir que alguna cosa redirigeix la petició, i un FIN immediat vol dir que un proxy o servidor ha tancat el flux.
Per això l'objectiu ha de ser un servidor SSTP i no un servidor web amb un certificat TLS afegit. El mètode, el camí i el cos de llarga durada són requisits del protocol, així que un proxy invers no els pot afegir només amb configuració. Un proxy que reexpedeix HTTPS normal perfectament encara pot refusar un mètode que no reconeix.
On un proxy o servidor web trenca el flux
Un intermediari inspecciona la línia de petició HTTP abans de reexpedir res, i un mètode personalitzat amb un camí inusual pot incomplir les seves regles. Alguns dispositius serveixen una pàgina normal mentre rebutgen o interrompen el túnel, així que el client informa d'una connexió que comença i després mor en lloc d'un refús net. Altres accepten la petició i després apliquen un temps d'espera de cos o d'inactivitat que els keepalives PPP no poden superar. Tots dos semblen iguals des del costat del client, per això l'etapa que ha fallat importa més que el text de l'error.
Compartir el port 443 entre un lloc web i SSTP és una decisió d'encaminament, no una promesa que cada salt tracti les dues converses de la mateixa manera. Si hi ha un balancejador de càrrega, un tallafoc o un terminador TLS al camí, afegiu-lo a la llista de sospitosos abans de tocar la configuració de la VPN.
Proveu les etapes per separat
Executeu les comprovacions en ordre i atureu-vos al primer fracàs, perquè cada etapa descarta una capa diferent. La sonda TLS de sota separa la identitat del certificat de tot el que fa SSTP. Substituïu el nom d'amfitrió pel vostre punt final i llegiu el subjecte i la cadena que imprimeix.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comDesprés mapem les proves restants a les etapes en lloc d'endevinar a partir de l'error del client. La taula de sota és la llista de comprovació per citar al tiquet, amb la signatura que separa un fracàs del següent.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Registreu al tiquet l'última etapa que ha tingut èxit en lloc d'escriure "no es pot connectar". L'especificació MS-SSTP documenta la petició i l'intercanvi PPP que segueixen el handshake TLS, i és la referència de per què una prova al navegador no pot substituir cap de les dues.
Primer la identitat, després PPP
La identitat TLS i l'autenticació PPP són seqüencials, no alternatives, i confondre-les porta la gent a la configuració de servidor equivocada. El client valida primer el certificat del servidor i la seva finalitat prevista, després PPP negocia el seu propi estat i autentica l'usuari amb un mètode de desafiament-resposta o EAP. Un problema de certificat produeix un error diferent del d'una contrasenya rebutjada, i cap dels dos errors descriu l'etapa que cobreix l'altre.
Canviar el nom d'amfitrió per una adreça, o clicar més enllà de l'avís de certificat, elimina la comprovació que hauria identificat l'etapa fallida en lloc de corregir-la. Manteniu l'avís i llegiu-lo. Tampoc no reinicieu una contrasenya PPP quan l'intercanvi HTTP no ha arribat mai al comportament SSTP, perquè la credencial no s'ha demanat mai.