Como comprobar se un cliente VPN admite SSTP de verdade

Chamar cliente VPN a un produto non di nada sobre se fala SSTP, e o porto 443 no enderezo demostra aínda menos. SSTP executa TLS sobre TCP 443, despois un intercambio de control SSTP, despois PPP para a propia ligazón, coa validación do certificado e un método de autenticación PPP por riba. Un cliente admite o protocolo só cando a implementación indicada, na versión instalada, completa cada unha desas capas segundo os requisitos do seu servidor. Faga as comprobacións seguintes en orde e detéñase na primeira que falla, porque é a que paga a pena resolver.

Faga coincidir a implementación, a versión e a plataforma

Comece pola plataforma, a aplicación e a compilación instalada, porque un nome de fabricante pode cubrir dúas implementacións completamente distintas. Os tipos de VPN integrados e os clientes de terceiros non son o mesmo, e un complemento pode amosar unha etiqueta de adaptador que non describe o protocolo que hai debaixo. A documentación da versión actual non describe a compilación que se executa na máquina que ten diante. Lea a páxina específica da versión e compárea co que o cliente declara sobre si mesmo.

En Windows o tipo de túnel vén da plataforma e non da interface gráfica, así que pregunte á plataforma. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress mostra Sstp cando o cliente nativo tentará o protocolo, e a referencia de tipos de conexión inclúeo entre os tipos de túnel integrados. En Linux non existe ningún cliente SSTP nativo, así que a pregunta pasa a ser se unha implementación aparte como sstpc do paquete sstp-client está instalada e ao día.

Lea o formato do perfil antes da etiqueta

Os perfís non son intercambiables, e o ficheiro que lle entregaron adoita resolver a cuestión máis rápido que calquera lista de funcións. As directivas de OpenVPN, as chaves de WireGuard e os axustes de conexión SSTP describen tres protocolos sen relación, e ningún diálogo de importación converte un noutro. Compartir o porto TCP 443 non traduce nada, porque SSTP, OpenVPN sobre TLS e un servizo HTTPS corrente poden ocupar o mesmo porto e non ter nada en común por riba.

Se o ficheiro é un .ovpn ou unha configuración de WireGuard, a resposta xa está clara: a ese cliente non se lle pide falar SSTP. Importalo nun cliente que só fai SSTP falla na etapa do perfil, moito antes de que comece calquera negociación do protocolo.

O que TLS non demostra sobre o despregamento

Un handshake TLS completado demostra que o servidor ten un certificado, e non demostra nada sobre se o seu cliente confía na cadea emisora ou fai coincidir o nome que contén. A validación ten que ter éxito contra o servidor previsto, incluída calquera CA privada que opere a organización, e un cliente que ofrece saltar os erros de certificado eliminou a comprobación en lugar de gañar compatibilidade co protocolo. A validación da cadea e a coincidencia do nome son dúas probas separadas, e unha pila que supera unha pode fallar na outra. Ambas pertencen aos criterios de aceptación, non ao anexo de resolución de problemas.

Despois confirme o método de autenticación PPP, porque un despregamento con EAP-TLS necesita un cliente que poida presentar un certificado dentro de PPP, mentres que un método baseado en contrasinal necesita soporte para ese intercambio. Un enderezo de servidor e un contrasinal non describen o requisito real da organización, sobre todo cando hai un segundo factor ou unha comprobación do dispositivo diante. Pregunte que método impón o servidor antes de supor que o cliente pode satisfacelo.

Siga a sesión por catro etapas

Observe como a conexión cruza catro fronteiras: TCP e TLS cara ao servidor, o intercambio de control SSTP, a negociación PPP e despois o recurso que realmente necesita. Un rexistro que se detén tras TLS describe un fallo distinto dun que se detén dentro de PPP, e ambos levan a responsables diferentes. Que un navegador cargue a páxina web do host só demostra que algo respondeu no 443, que é o falso positivo máis habitual neste eido. Se esa páxina carga mentres o cliente segue fallando, o problema está por riba de TLS e o servidor web non é o sospeitoso.

Remate cun recurso privado real e unha consulta de nome, porque unha sesión que se establece e non transporta nada vese igual que unha funcional na maioría das ventás de estado. Unha petición correcta ao recurso que necesita resolve unha pregunta que a icona non pode.

Cando falta compatibilidade, cambie o plan

Se o cliente non pode falar SSTP, consiga unha alternativa aprobada ou pida ao propietario do servidor un protocolo que ambos os extremos admitan. Borrar as opcións non recoñecidas ata que unha importación funcione produce un perfil que non conecta con nada, que é unha ruta máis lenta cara ao mesmo calexón sen saída. Un instalador de orixe descoñecida que anuncia compatibilidade universal engade unha vía de confianza non aprobada á máquina e a miúdo substitúe o cliente da plataforma por algo que a organización non pode actualizar. Ningunha das dúas manobras é unha solución, e ambas son máis difíciles de desfacer que o problema orixinal.

Trate a cuestión da compatibilidade por separado do rendemento e da elección do punto final, porque un servidor próximo non serve de nada cando o cliente non pode falar o seu protocolo. Axustar a latencia non repara unha etapa que nunca se completa.