SSTP face à OpenVPN : le même port 443, un autre protocole

Les deux options peuvent se trouver derrière TCP 443, alors les gens supposent qu’elles sont des extrémités interchangeables. Elles ne le sont pas : SSTP serveur parle PPP à l’intérieur de HTTPS, tandis qu’un serveur OpenVPN parle son propre protocole par-dessus TLS ou via un flux UDP brut. Pointer un client vers le port de l’autre produit une connexion qui n’atteint jamais une invite de connexion. Le choix porte sur le client et le transport que vous pouvez prendre en charge, pas sur le numéro.

Un port partagé ne fait pas un protocole partagé

La poignée de main TLS peut se terminer et ne mener nulle part, car ensuite le client et le serveur ne sont pas d’accord sur ce qu’il faut dire. Dans une capture de paquets, vous voyez une poignée de main propre suivie de données applicatives que l’homologue rejette ou ignore. Ce schéma est la signature d’une incompatibilité de protocole, non d’un blocage par pare-feu.

Ni un profil renommé ni une autre entrée de menu ne convertit l’un en l’autre. Une connexion SSTP se crée depuis les paramètres VPN de Windows avec une adresse de serveur et les informations d’authentification de l’opérateur, tandis qu’une connexion OpenVPN a besoin du client et du fichier de configuration correspondant. La spécification SSTP de Microsoft décrit la première et ne décrit pas une poignée de main OpenVPN.

Le port 443 est une commodité de politique. Il traverse des réseaux qui permettent peu d’autre chose, et c’est un vrai avantage, mais il ne dit rien sur le protocole qui tourne derrière.

SSTP tunnelise PPP à l’intérieur de HTTPS

Le nom décrit la construction : des trames PPP transportées dans une session HTTPS, donc TLS en dessous et un certificat que le client peut vérifier. Windows l’inclut comme type de VPN natif, si bien qu’un ordinateur portable géré peut souvent se connecter sans logiciel supplémentaire au-delà du profil que fournit l’opérateur.

Les autres plateformes sont une autre histoire. Un client Linux ou macOS a besoin d’une implémentation maintenue, et celles-ci varient dans ce qu’elles prennent en charge et dans la manière dont elles signalent les erreurs. Vérifiez le client que vous comptez réellement utiliser au lieu de supposer que la capacité intégrée de Windows se transpose, et confirmez que le nom du serveur dans le profil correspond au certificat présenté par le serveur.

SSTP est généralement TCP uniquement. Ce transport unique influence son comportement sur une liaison avec pertes, car la retransmission a lieu à l’intérieur du tunnel comme en dessous.

OpenVPN apporte son propre client et un choix de transport

OpenVPN fournit son propre client et son profil, ce qui vous donne des diagnostics qu’une boîte de dialogue Windows native n’expose pas. Le serveur peut écouter en UDP ou en TCP, et la configuration de l’opérateur décide lequel votre client doit utiliser. Un profil pointé vers le mauvais transport échoue avant l’authentification.

L’authentification dépend tout autant de la configuration. Un déploiement peut exiger seulement des certificats, des certificats plus un nom d’utilisateur et un mot de passe, ou un second facteur en plus, et le client doit correspondre exactement à cette disposition. Le fait qu’une connexion atteigne l’étape TLS ne vous dit pas quels identifiants elle demandera ensuite.

UDP est la valeur par défaut habituelle car il évite d’imbriquer un flux fiable dans un autre flux fiable. Le mode TCP existe pour les réseaux qui bloquent UDP, et il fonctionne, mais une perte importante peut le rendre plus désagréable que le chemin UDP qu’il a remplacé. Choisissez TCP quand vous devez, pas parce que cela sonne plus fiable.

Choisir selon le client, le transport et le support

Trois questions règlent la plupart de ces décisions. Chaque appareil client a-t-il besoin d’une connexion qui fonctionne sans logiciel supplémentaire ? Le réseau dont vous dépendez autorise-t-il UDP, ou TCP 443 est-il la seule sortie ? Et qui assure le support du client, de ses mises à jour et de sa remise en état lorsqu’un profil expire ?

Quand vous comparez les deux, testez sur le même appareil et le même réseau d’accès. Si l’extrémité SSTP et l’extrémité OpenVPN sont des serveurs différents ou des sites différents, votre résultat inclut ces routes et ces machines au lieu d’isoler le protocole. C’est la façon la plus courante dont ces comparaisons produisent une réponse assurée mais fausse.

Confirmez ensuite laquelle vous avez réellement établie avant de déboguer quoi que ce soit d’autre :

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

Quoi qu’il en soit, terminez en testant la ressource et le DNS dont vous avez besoin plutôt qu’en déclarant le succès à l’état du tunnel. Les deux protocoles peuvent être configurés pour ne transporter que du trafic privé sélectionné, et un tunnel connecté sans résolution de noms fonctionnelle ressemble à un VPN cassé alors qu’il s’agit en réalité d’une conception de tunnel divisé ou de DNS.

Dans un parc géré, la distribution des profils et le support des mises à jour tranchent généralement la question bien avant tout banc d’essai de transport.