Une seule interface WAN peut-elle servir la VPN inter-sites et l’accès distant ?

Une seule adresse publique peut servir en même temps un tunnel de branche et un bassin d’utilisateurs nomades. Elle ne peut pas servir une règle d’admission commune. Le pair de la branche et l’utilisateur nomade diffèrent par ce qu’ils déclarent être, par la manière dont cette preuve est contrôlée, par les adresses qu’ils reçoivent et par les préfixes autorisés à leur répondre. Dès que vous traitez l’adresse extérieure comme un détail de transport et non comme une identité, la conception devient bien plus simple.

Un test de bon sens rapide : essayez d’écrire les deux enregistrements d’admission avant de toucher au routeur. Si une seule condition d’appariement doit couvrir les deux, la politique est déjà ambiguë, et le premier symptôme ressemblera à une panne de routage ou de pare-feu alors qu’il s’agit en réalité d’une panne d’identité.

Deux enregistrements avant toute configuration

L’enregistrement de la branche est court et stable. Il liste l’adresse du pair ou le nom du certificat, la clé prépartagée ou le trustpoint du certificat, les sous-réseaux protégés des deux côtés, l’interface du tunnel et la route statique qui envoie le trafic destiné à la branche dans ce tunnel. Chaque champ concerne un pair connu et un ensemble fixe de préfixes.

L’enregistrement nomade est plus large et plus personnel. Il liste le protocole et le port du client, la manière dont un utilisateur ou un appareil s’authentifie, le bassin d’adresses remis à la connexion, les ressources que ce bassin peut atteindre, les préfixes du tunnel divisé, les serveurs DNS poussés vers le client et tout second facteur. Chaque champ répond à une question sur un nombre inconnu d’utilisateurs et non sur une seule passerelle.

Cette différence de granularité est toute la raison pour laquelle les deux rôles divergent. Un profil de branche peut faire confiance à une seule clé parce que la clé appartient à un seul appareil sur un seul site. Un profil nomade qui fait confiance à une clé de groupe pour tous effondre la responsabilité par utilisateur, ce qui se découvre généralement plus tard, lors du retour sur incident plutôt que lors du déploiement.

Où l’appariement des pairs et l’authentification divergent

Sur IOS XE, le profil IKEv2 porte les paramètres qui ne peuvent pas être négociés et les conditions servant à sélectionner le pair. Cela signifie que le côté branche et le côté nomade ont chacun besoin de leur propre profil, même lorsqu’ils aboutissent sur la même interface et même lorsqu’ils partagent une même PKI cryptographique. Cisco documente les rôles du profil, de l’authentification et de l’appariement dans son guide de configuration IKEv2 pour IOS XE 17.

Le profil de la branche correspond généralement à une identité étroite : une adresse distante, un FQDN ou un sujet de certificat. Quelque chose comme match identity remote address 198.51.100.10 255.255.255.255 épingle un seul pair, et authentication remote pre-share avec une clé stockée par site suffit. Gardez l’appariement aussi précis que l’inventaire des pairs le permet, car un joker qui se chevauche plus haut dans l’ordre de sélection peut tirer le trafic de la branche vers le mauvais profil.

Le profil nomade ne peut pas épingler une adresse, il correspond donc à un groupe, à un key-id ou à un champ du certificat, puis remet la véritable vérification de l’utilisateur à AAA ou à la politique d’autorisation attachée au profil. Cette séparation compte : l’authentification du pair répond si le client a le droit de construire un tunnel, et l’autorisation par utilisateur répond du bassin et des ressources obtenus. Utiliser la clé de la branche comme identifiant universel jette la seconde réponse.

Le transfert et la traduction ont besoin de la même séparation

L’admission et l’accessibilité sont deux problèmes distincts. Un échange IKE et IPsec réussi prouve que les parties s’accordent sur les clés ; il ne crée pas de route vers le bassin que le client a reçu. Les bassins d’accès distant ont donc besoin d’un chemin de retour, soit une route statique pointant vers l’interface du tunnel, soit un protocole de routage qui injecte le résumé du bassin. Les préfixes de la branche arrivent généralement par le même processus de routage que le reste du site.

La traduction est l’endroit où les deux rôles entrent le plus souvent en collision. Le trafic inter-sites qui doit conserver ses adresses privées a besoin d’une exemption NAT limitée à ces deux préfixes, dans les deux sens. Les clients nomades ont généralement aussi besoin de l’exemption pour leur trafic dans le tunnel, mais leur trafic vers internet soit contourne le tunnel par le tunnel divisé, soit sort au concentrateur après le NAT. Exempter tout ce qui arrive d’un tunnel est l’erreur classique, car cela retire aussi la traduction à du trafic qui en a vraiment besoin.

Gardez les règles d’exemption aussi étroites que les règles d’admission. Si un résumé de bassin et un préfixe de branche se chevauchent, le chemin de retour devient ambigu bien avant qu’un seul paquet ne soit rejeté, et le symptôme apparaît comme un site qui perd un sous-réseau par intermittence plutôt que comme une panne nette du tunnel.

Des cas de recette qui révèlent une politique croisée

Construisez quatre cas et exécutez-les dans l’ordre. Un hôte de la branche atteint une ressource réservée à la branche. Un client nomade atteint la même ressource via l’adresse de son bassin. Un client nomade tente un préfixe de la branche qu’il ne devrait pas toucher. Un pair de la branche tente d’obtenir une adresse du bassin d’accès distant. Les deux derniers sont ceux qui attrapent un profil partagé, car ils échouent en silence dans la supervision habituelle.

Confirmez ensuite le plan de données plutôt que la configuration. show crypto ikev2 sa et show crypto ipsec sa indiquent quel profil et quels sélecteurs ont porté chaque flux, tandis que show ip nat translations et les compteurs du tunnel montrent si le chemin de retour et l’exemption ont réellement correspondu. Un tracer ou une capture de paquets sur l’interface du tunnel ferme la boucle.

Notez l’identité observée, l’adresse du bassin et la politique retenue à côté de chaque résultat. La campagne est terminée quand chaque cas correspond exactement à un enregistrement et qu’aucun cas n’a besoin d’une exception temporaire pour passer.