El port 443 respon, SSTP encara falla: quina etapa s’ha trencat?

Completar un handshake TCP al port 443 mentre el túnel no es construeix mai demostra una cosa, i és una cosa petita. Alguna cosa escolta i està disposada a acceptar una connexió en aquesta adreça. No identifica el servei, el certificat que presentarà ni què passa després dels primers bytes.

Entre aquest handshake i un túnel funcional hi ha quatre etapes, i cadascuna produeix un error diferent.

Un port obert descriu només una capa

Acceptar una connexió TCP vol dir que un procés posseeix el sòcol i que el camí permet el handshake. No diu res sobre si aquest procés és un servidor SSTP, si té un certificat vàlid per al nom del vostre perfil o si autoritzarà el vostre compte. Un servidor web a la mateixa adreça respon perfectament al handshake i després respon a la vostra petició SSTP amb un error HTTP. Tot el que hi ha per sobre d’aquest handshake queda sense provar.

Tracteu la prova del port com el filtre més barat possible i no com un veredicte. El seu valor és que elimina una categoria sencera de fallades, no que confirmi tot el que hi ha per sobre.

Confondre les dues coses és la raó per la qual la gent reinstal·la clients després d’una prova que mai no va examinar el problema real del client.

Separeu les quatre etapes amb proves

Les etapes són l’abast del transport, la validació TLS, l’intercanvi SSTP sobre HTTPS i l’autenticació PPP dins del túnel. Un camí que passa la primera i falla la quarta necessita una correcció de credencials; un que falla la segona necessita una correcció de certificat o de nom. Aquestes reparacions no tenen res en comú, i triar la incorrecta malbarata la interrupció.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

La tercera ordre val la pena llegir-la amb atenció. Un 200 d’una pàgina web corrent us diu que hi ha un servei web; no us diu que la petició SSTP s’entendrà. Un 404 de la mateixa adreça és igualment poc informatiu sobre la VPN. Només el registre del client us diu a quina de les quatre etapes ha arribat.

Fixeu-vos en quin nom ha fet servir cada ordre. El certificat es tria pel nom que envieu, així que una discrepància entre el perfil i la prova és una discrepància que heu introduït vosaltres. Escriure aquest nom al costat del resultat evita la confusió més endavant.

Llegiu l’èxit parcial en la direcció correcta

Un intermediari pot permetre la navegació corrent i refusar l’intercanvi posterior, i per això un proxy que funciona per a llocs web encara pot fallar per a un túnel. El mateix patró apareix quan un certificat és vàlid per a un nom de navegador però no per al nom configurat al perfil: el navegador queda satisfet i el client no, i tots dos tenen raó sobre què han comprovat.

Mantingueu la validació del servidor activada mentre diagnostiqueu això. Desactivar-la converteix una discrepància de certificat en un handshake correcte i amaga l’única prova que hauria explicat la fallada.

Si el mateix perfil funciona des d’una altra xarxa, la diferència depèn del camí. Això redueix la cerca als intermediaris sense dir-ne quin, i encara és un pas útil endavant. Registreu la xarxa que heu fet servir, perquè la comparació no val res sense ella.

Després proveu l’aplicació, no només la sessió

Un cop existeix una sessió, verifiqueu la ruta prevista, la resolució de noms i el permís de servei des del client que els necessita. Un túnel connectat encara pot tenir un reenviament absent a l’altre costat o una ruta de retorn que mai no va existir, i aquestes fallades semblen exactament un problema d’aplicació per a la persona que espera.

Mantingueu cada conclusió lligada a l’etapa que l’ha produïda. Anomenar port obert una VPN funcional és com una comprovació de certificat de cinc minuts es converteix en un dia de reinstal·lar programari.