Concentrateur ou passerelle ? Où se trouve le terminateur VPN sur votre chemin

Deux fournisseurs peuvent appeler la même machine concentrateur et passerelle, et aucun des deux mots ne vous dira où le trafic est déchiffré. Les étiquettes décrivent des rôles de déploiement plutôt que des protocoles, et les rôles se recoupent dans toutes les directions. Ce qui compte lors d'une revue de conception, c'est l'équipement qui termine le tunnel, les contrôles qui l'entourent et le chemin d'une requête déchiffrée. Décidez à partir de ces trois éléments, et le nom sur la fiche technique cesse d'être un argument.

Deux étiquettes, une décision

Un concentrateur désigne généralement le système central qui reçoit et gère de nombreuses connexions à la fois, et le mot porte une idée d'échelle. Une passerelle est le terme plus large pour un point d'extrémité qui relie un tunnel aux réseaux situés derrière, et elle peut décrire un routeur, un pare-feu ou un service géré. Aucun des deux mots ne nomme un protocole, et aucun ne promet un ensemble de fonctions précis. Le même appareil peut être vendu sous les deux noms par deux fournisseurs, et c'est pourquoi le débat terminologique ne se règle jamais.

Traitez l'étiquette comme un indice sur l'usage prévu et rien de plus. La décision appartient aux fonctions que vous pouvez vérifier dans la configuration, pas aux mots de la brochure.

Trouvez l'équipement qui termine réellement

Suivez une connexion cliente de l'extérieur vers l'intérieur. Quelque chose accepte le transport, quelque chose authentifie le pair, quelque chose attribue une adresse au client, quelque chose autorise une destination et quelque chose fournit une route de retour. Ces cinq fonctions peuvent vivre sur un seul équipement ou sur cinq, et la seule question utile est de savoir quel équipement fait quoi. Un routeur en amont peut transporter les paquets externes sans jamais les déchiffrer, et c'est exactement le cas où un schéma de topologie amène le relecteur à nommer la mauvaise machine.

Confirmez la terminaison sur le candidat lui-mêmeplutôt qu'à partir du schéma. Une socket en écoute sur le port attendu, accompagnée d'une entrée d'état établie, est une preuve plus solide qu'un schéma de réseau, et l'absence des deux l'est encore plus.

sudo ss -lunp | grep -E ":500|:4500"
sudo ip xfrm state
sudo traceroute -n -U -p 4500 vpn.example.com

Décidez selon cinq propriétés, pas selon le nom du produit

Cinq propriétés séparent les candidats, et chacune peut être renseignée à partir de la documentation plutôt que du marketing. Quels rôles VPN cette version prend-elle en charge, quelles sources d'identité peut-elle utiliser, quelle portée de transfert autorise-t-elle, quelle capacité soutient-elle et comment se comporte-t-elle en cas de panne. Demandez ces cinq points par écrit, et l'étiquette devient sans importance pour la décision.

La capacité est la propriété que l'étiquette de concentrateur suggère le plus fortement, et c'est celle qui reste le plus souvent vague. Les limites de simultanéité, le débit par tunnel et le débit total sont trois nombres différents, et un équipement peut être généreux sur l'un et avare sur l'autre. La haute disponibilité est une propriété de la paire et non de l'une des machines, et elle relève de la question de la reprise. Une étiquette qui suggère l'échelle n'est pas une spécification de l'échelle.

La reprise fait partie de la même conversation. Demandez comment un administrateur atteint l'équipement lorsque le tunnel lui-même est le composant en panne, car un chemin hors bande est une décision de conception et non un accessoire.

Vérifiez les preuves avant l'étiquette

Un service actuel doit être évalué sur les rôles pris en charge, la politique d'identité, la portée de transfert, la capacité et le comportement de reprise, avec des réponses propres à la version que vous déploieriez. Un aperçu historique peut expliquer pourquoi le mot concentrateur existe, mais il ne peut pas vous dire ce que prend en charge une version actuelle.Présentation de Cisco VPNest un contexte terminologique utile précisément pour cette raison, et la traiter comme une liste de fonctions actuelle est la façon dont une revue de conception tourne mal.

Vérifiez ensuite une affirmation de bout en bout. Choisissez la propriété qui compte le plus, comme le débit par tunnel ou le temps de basculement, et demandez la méthode de mesure plutôt que le chiffre. Une vérification locale rapide de ce que l'équipement expose réellement est un début raisonnable.

sudo ip xfrm state | grep -c '^src '
sudo swanctl --list-sas

Sous Linux, la première ligne compte les associations de sécurité, et un tunnel en a normalement deux, une par direction, donc divisez le compte par deux avant de le comparer à une affirmation sur les tunnels. Sur un hôte strongSwan, la seconde ligne nomme directement les tunnels. Le décompte des sockets ne remplace pas cela : IPsec NAT-T maintient une seule socket UDP 4500 partagée par tous les tunnels, donc compter les sockets sur ce port renvoie zéro ou un, quel que soit le nombre de tunnels. Aucune des deux lignes n'est une mesure de débit, et aucune ne prédit le comportement sous charge. Ce qu'elles vous donnent, c'est l'unité sur laquelle interroger, et un fournisseur capable de décrire la méthode possède une spécification là où celui qui ne le peut pas possède une brochure.

Écrivez le chemin et les étiquettes cessent d'importer

Décrivez l'architecture comme une liste de fonctions avec des responsables : terminaison, authentification, attribution d'adresses, autorisation, routage de retour, journalisation et reprise. Cette description survit à un changement de nom de produit, à un changement de fournisseur et à une acquisition, et aucun d'eux ne mettra votre schéma à jour.

Révisez-la face à une véritable session cliente une fois par trimestre, car une fonction peut se déplacer sans que personne ne modifie le dessin. Les étiquettes continueront de changer, et la liste des responsables continuera d'être ce qui explique réellement le réseau.