Attention, malheureusement SSTP (à partir de Novembre 2011) ne fonctionnera pas sur un serveur proxy avec une authentification . Ceci est documenté, bien que peu de gens le réalisent.
Il est également possible pour l'administrateur réseau d'un proxy non authentifié de détecter les en-têtes SSTP et d'interrompre les connexions. Donc, l'affirmation selon laquelle il traverse n'importe quel pare-feu, etc... est vraie. avec quelques réserves .
OpenVPN est capable de passer par HTTPS sur un proxy. avec authentification . Il est beaucoup plus difficile de bloquer ce trafic car il ressemble à un "SSL" normal, mais ce n'est pas le cas ! Il est possible avec une inspection des paquets sur les premiers octets du contenu de bloquer ces paquets. OpenVPN dans ce mode perd le gain de performance "UDP", car OpenVPN fonctionnerait en mode TCP. Donc, dans ce sens, il est égal à SSTP.
Pour OpenVPN, du côté serveur, vous devez avoir deux IPs publiques si vous avez aussi un serveur web sur le port 443, ceci pour l'édition commerciale. Pour l'édition communautaire, il est possible de partager le port 443 sur la même IP, car le serveur détecte le protocole non-OpenVPN et redirige le trafic vers un serveur web alternatif (443). Ceci ne fonctionne que dans la version Linux du serveur OpenVPN.
Sur SSTP, il est possible de partager la même IP/port 443, à la fois pour le trafic SSTP et pour les pages protégées du serveur web normal.
Sur SSTP, il peut y avoir un dispositif de délestage SSL sur le réseau avant d'atteindre le serveur RRAS. Sur OpenVPN, comme le trafic n'est pas vraiment du "vrai" SSL, c'est-à-dire que le protocole OpenVPN encapsule une charge utile SSL, ce n'est pas faisable.
Sur OpenVPN community, vous devez gérer l'infrastructure KPI, les certificats, etc, ce qui peut être une courbe d'apprentissage plus difficile parfois... (sur l'édition community). Sur l'édition commerciale, cette tâche est facilitée.
Sur OpenVPN commercial, l'authentification peut être intégrée avec LDAP (par exemple sur un AD). Sur le communautaire, ce n'est pas possible (pas complètement sûr, mais presque !). L'idée est plus autour des certificats clients ; bien qu'il soit possible d'utiliser des schémas de certificats plus simples.
O SSTP, ceci est inclus évident.
OpenVPN fonctionne en mode UDP, ce qui est très bien, mais PPTP fonctionne également en mode UDP pour le canal de données (protocole GRE). Puisque la question est la comparaison entre SSTP et OpenVPN, supposons simplement que nous comparons le trafic TCP.
Donc vous voyez... il n'y a pas de meilleur ou de pire... Dans mon cas, je me suis battu pour en choisir un en raison de mes exigences fonctionnelles... et je ne suis toujours pas entièrement satisfait de celui que j'ai dû choisir (SSTP), mais assez satisfait. Je dis cela parce que si le réseau (hôtel) bloque PPTP alors SSTP peut être utilisé... ceci est géré automatiquement par le client VPN.
Le client OpenVPN dispose d'un mécanisme de repli similaire.
SSTP est déjà pris en charge par Linux, mais le projet semble en être au stade initial.
0 votes
Quelques brèves observations concernant le PPTP : De nombreux dispositifs NAT gèrent le PPTP sans problème. En 2000, il était difficile de s'assurer qu'un dispositif NAT pouvait faire transiter plusieurs flux GRE simultanément et de manière stable, mais ce n'est plus le cas depuis quelques années. Le PPTP avec cryptage 128 bits offre un niveau de sécurité très raisonnable. Les problèmes liés au cryptage avec le PPTP proviennent de l'utilisation de clés de 40 bits. Personne ne devrait utiliser des clés de 40 bits pour quoi que ce soit !
0 votes
Comme décrit ci-dessous, le PPTP passthrough ne fonctionne pas dans les hôtels ou les entreprises, bien que les principaux routeurs puissent le gérer par défaut. Parfois, nous recevons des plaintes de vendeurs qui ne peuvent pas joindre le bureau en passant par l'hôtel. Et oui, je suis d'accord pour dire qu'une sécurité de 128 bits est suffisante. C'est plus sûr que d'essayer de pirater socialement les employés !
2 votes
Au cas où quelqu'un se méprendrait sur ce point, 5+ ans plus tard, PPTP n'est plus une solution raisonnable pour personne (et ne l'a plus été depuis 2012) : cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2