Com comprovar si un client VPN admet realment SSTP

Anomenar un producte client VPN no diu res sobre si parla SSTP, i el port 443 a l'adreça encara ho demostra menys. L'SSTP funciona amb TLS sobre TCP 443, després un intercanvi de control SSTP, després PPP per a l'enllaç mateix, amb la validació del certificat i un mètode d'autenticació PPP a sobre. Un client admet el protocol només quan la implementació esmentada, en la versió instal·lada, completa cadascuna d'aquestes capes segons els requisits del vostre servidor. Feu les comprovacions següents en ordre i atureu-vos a la primera que falli, perquè és la que val la pena resoldre.

Feu coincidir la implementació, la versió i la plataforma

Comenceu per la plataforma, l'aplicació i la compilació instal·lada, perquè un sol nom de fabricant pot correspondre a dues implementacions completament diferents. Els tipus de VPN integrats i els clients de tercers no són el mateix, i un connector pot mostrar una etiqueta d'adaptador que no descriu el protocol que hi ha a sota. La documentació de la versió actual no descriu la compilació que s'executa a la màquina que teniu davant. Llegiu la pàgina específica de la versió i compareu-la amb el que el client diu de si mateix.

A Windows el tipus de túnel prové de la plataforma i no de la interfície gràfica, així que pregunteu a la plataforma. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress mostra Sstp quan el client natiu intentarà el protocol, i la referència de tipus de connexió el llista entre els tipus de túnel integrats. A Linux no hi ha cap client SSTP natiu, de manera que la pregunta és si una implementació separada com ara sstpc del paquet sstp-client està instal·lada i al dia.

Llegiu el format del perfil abans de l'etiqueta

Els perfils no són intercanviables, i el fitxer que us han lliurat normalment resol la qüestió més de pressa que qualsevol llista de funcions. Les directives d'OpenVPN, les claus de WireGuard i els paràmetres de connexió SSTP descriuen tres protocols sense relació, i cap diàleg d'importació converteix l'un en l'altre. Compartir el port TCP 443 no tradueix res, perquè SSTP, OpenVPN sobre TLS i un servei HTTPS corrent poden ocupar el mateix port i no tenen res en comú per sobre.

Si el fitxer és un .ovpn o una configuració de WireGuard, la resposta ja és clara: no es demana a aquest client que parli SSTP. Importar-lo en un client que només fa SSTP falla a l'etapa del perfil, molt abans que comenci qualsevol negociació del protocol.

Què no demostra TLS sobre el desplegament

Un handshake TLS complet demostra que el servidor té un certificat, i no demostra res sobre si el vostre client confia en la cadena emissora o fa coincidir el nom que hi ha dins. La validació ha de reeixir contra el servidor previst, incloent-hi qualsevol CA privada que gestioni l'organització, i un client que ofereix saltar-se els errors de certificat ha eliminat la comprovació en lloc d'haver guanyat suport del protocol. La validació de la cadena i la coincidència del nom són dues proves separades, i una pila que en passa una pot fallar en l'altra. Totes dues pertanyen als criteris d'acceptació, no a l'annex de resolució de problemes.

Després confirmeu el mètode d'autenticació PPP, perquè un desplegament amb EAP-TLS necessita un client que pugui presentar un certificat dins de PPP, mentre que un mètode basat en contrasenya necessita suport per a aquest intercanvi. Una adreça de servidor i una contrasenya no descriuen el requisit real de l'organització, sobretot quan hi ha un segon factor o una comprovació del dispositiu al davant. Pregunteu quin mètode imposa el servidor abans de suposar que el client el pot satisfer.

Seguiu la sessió per quatre etapes

Observeu com la connexió travessa quatre fronteres: TCP i TLS cap al servidor, l'intercanvi de control SSTP, la negociació PPP i després el recurs que realment necessiteu. Un registre que s'atura després de TLS descriu una avaria diferent d'un que s'atura dins de PPP, i els dos porten a responsables diferents. Que un navegador carregui la pàgina web de l'amfitrió només demostra que alguna cosa ha respost al 443, que és el fals positiu més habitual en aquest àmbit. Si aquesta pàgina es carrega mentre el client encara falla, el problema és per sobre de TLS i el servidor web no és el sospitós.

Acabeu amb un recurs privat real i una consulta de nom, perquè una sessió que s'estableix i no transporta res sembla igual que una de funcional a la majoria de finestres d'estat. Una petició reeixida al recurs que necessiteu resol una qüestió que la icona no pot.

Quan falta suport, canvieu el pla

Si el client no pot parlar SSTP, obteniu una alternativa aprovada o demaneu al propietari del servidor un protocol que tots dos extrems admetin. Esborrar les opcions no reconegudes fins que la importació funcioni produeix un perfil que no connecta enlloc, que és una ruta més lenta cap al mateix cul-de-sac. Un instal·lador d'origen desconegut que anuncia compatibilitat universal afegeix una via de confiança no aprovada a la màquina i sovint substitueix el client de la plataforma per una cosa que l'organització no pot actualitzar. Cap de les dues jugades és una solució, i totes dues són més difícils de desfer que el problema original.

Tracteu la qüestió de la compatibilitat per separat del rendiment i de l'elecció del punt final, perquè un servidor proper no serveix de res quan el client no pot parlar el seu protocol. L'ajust de la latència no repara una etapa que mai no es completa.