Pourquoi SSL VPN et VPN site à site ne sont pas opposés

Demandez à deux administrateurs de décrire le même VPN : l'un répondra peut-être « SSL VPN » tandis que l'autre dit « site à site », comme si les deux étaient des options concurrentes dans un menu. Ce sont des réponses à des questions différentes, et les traiter comme des alternatives produit des comparaisons qui ne peuvent pas être tranchées. Une étiquette dit quels extrémités sont jointes ; l'autre dit ce qui transporte le trafic entre elles. Gardez les axes séparés et l'essentiel de la discussion disparaît.

Deux étiquettes, deux questions distinctes

La topologie répond à qui rejoint quoi. Une conception d'accès distant rattache des utilisateurs ou des appareils individuels à une passerelle, généralement avec une identité par utilisateur et un pool d'adresses. Une conception site à site relie deux réseaux par des passerelles, si bien que l'identité intéressante est la passerelle homologue et non la personne devant un clavier. Ce sont des problèmes opérationnels différents, de la planification des adresses à qui peut révoquer l'accès à 2 heures du matin.

Le mécanisme répond à comment le tunnel est construit et authentifié. IPsec avec IKEv2, un produit fondé sur TLS qui transporte de l'IP à l'intérieur, et un portail d'applications tourné vers le navigateur sont des choix de mécanisme, et chacun a sa propre négociation, ses suites de chiffrement et ses modes de défaillance. Aucun n'implique une topologie, et une topologie ne choisit pas un mécanisme.

Placez les deux axes dans un seul tableau et la confusion devient visible, car chaque cellule de la grille peut être remplie. Ce que la grille ne peut pas faire, c'est vous dire quelle combinaison votre fournisseur a livrée, puisque les noms de produits écrasent les deux axes en une seule formule marketing.

D'où vient l'erreur de catégorie

Les fournisseurs ont vendu « SSL VPN » pendant des années comme l'opposé de « IPsec VPN », ce qui faisait ressembler une comparaison de mécanismes à un choix de topologie. L'expression a aussi mal vieilli en ses propres termes, car les conceptions actuelles utilisent des versions de TLS prises en charge et le nom SSL ne survit surtout que comme catégorie de produit.

Deux mythes liés découlent du même écrasement. Le premier est qu'IPsec signifie site à site ; IKEv2 a aussi été conçu pour des relations client-passerelle, si bien qu'un ordinateur portable individuel peut se joindre avec IPsec. Le second est qu'un produit fondé sur TLS signifie uniquement un accès distant ; OpenVPN est couramment utilisé pour transporter du trafic entre deux sites, et son usage de TLS se concentre sur l'échange de contrôle et d'authentification plutôt que sur une session de navigateur.

Un test utile pour toute description : si remplacer un mot change à la fois les extrémités et le protocole, la phrase mélange les axes. « SSL VPN contre site à site » échoue à ce test, car le premier terme nomme une famille de mécanismes et le second une topologie.

Décrivez un déploiement pour qu'il puisse être comparé

Écrivez quatre champs et remplissez-les : extrémités, mécanisme, authentification et surface d'accès. Une liaison de succursale pourrait se lire comme une paire de passerelles IKEv2 entre deux préfixes nommés, avec authentification par certificat et sans portail au niveau utilisateur. Un service d'accès distant pourrait se lire comme un client fondé sur TLS qui attribue des adresses par utilisateur, exige un second facteur à la connexion et ne publie qu'une zone DNS interne.

Ces phrases sont comparables d'une manière que les noms de produits ne sont pas. Deux conceptions d'accès distant peuvent être mesurées au regard du même flux de travail utilisateur et du même chemin de révocation, et deux conceptions intersites au regard de la même liste de préfixes, de la même politique de trafic et des mêmes exigences de défaillance. Les étiquettes organisent la comparaison ; elles ne la remplacent pas.

La terminologie a aussi un ancrage publié. Le document de terminologie VPN de l'IETF sépare plusieurs modèles de service, dont l'accès distant et le site à site, des mécanismes utilisés pour les construire, et c'est exactement la distinction qui ne cesse de se perdre.

Lisez le protocole négocié, pas le nom du produit

L'étiquette sur la boîte n'établit pas ce sur quoi un tunnel en fonctionnement s'est accordé. Interrogez l'homologue directement, côté TLS, et lisez la version de protocole et le chiffrement produits par la poignée de main plutôt que la version de la brochure.

openssl s_client -connect vpn.example.net:443 -tls1_3 -brief

Pour une passerelle IPsec, l'observation équivalente vient de la sortie d'état de l'implémentation elle-même, qui rapporte les propositions IKE et ESP utilisées. Quoi qu'il en soit, le point est le même : l'axe du mécanisme doit être lu dans la session vivante, car un client et une passerelle peuvent négocier vers quelque chose de plus ancien que ce que l'un ou l'autre administrateur attendait.

ipsec statusall | grep -E "IKE|ESP"

Ensuite, les questions qui restent sont celles auxquelles aucune étiquette ne répond. Quelles versions de protocole sont encore acceptées, comment l'identité de la passerelle est validée, quel jeu d'algorithmes est autorisé, qui autorise un utilisateur donné pour une ressource donnée et ce qui révoque l'accès lorsqu'un appareil est perdu. Un schéma de topologie et un nom de mécanisme sont le début de cette liste, pas un substitut.

Gardez donc les deux étiquettes, mais utilisez-les pour ce qu'elles sont : une façon courte de dire quelles extrémités sont jointes et comment le tunnel est construit. Dès que l'une sert à exclure l'autre, la description a cessé de décrire quoi que ce soit.