Commencez par l'agence elle-même, sur la page d'état WAN du routeur 4G. Si l'adresse que vous voyez se trouve dans la plage privée de l'opérateur plutôt que dans une plage publique, aucune redirection de port sur cet équipement ne permettra jamais au concentrateur d'appeler vers l'intérieur, et le tunnel doit être construit vers l'extérieur depuis l'agence. Cette seule observation décide de la conception. Le reste du travail consiste à faire en sorte que le concentrateur reconnaisse l'agence par autre chose qu'une adresse qui change toutes les quelques heures.

Où le tunnel doit commencer

Vérifiez l'adresse par rapport à l'espace d'adressage partagé que les opérateurs utilisent pour leur propre NAT, 100.64.0.0/10, et par rapport aux plages privées ordinaires. En voir une sur une liaison mobile signifie généralement qu'un NAT d'opérateur se trouve entre l'agence et l'internet, et que les connexions entrantes ne sont disponibles à aucun prix que l'agence puisse payer. Quand l'adresse WAN est publique mais change, vous avez un autre problème, plus simple.

Le DNS dynamique n'aide que dans le second cas. Il donne à une adresse publique changeante un nom stable à appeler, et il ne peut pas créer une correspondance que l'opérateur n'a jamais fournie. Il vaut tout de même la peine d'être configuré pour le cas public, car il supprime la seule étape manuelle d'une renumérotation. Ce qu'il ne doit pas devenir, c'est la réponse pour une agence que l'opérateur n'a jamais rendue joignable.

Séparez l'adresse que vous appelez de l'identité que vous comparez

Le concentrateur a besoin de quelque chose de stable où être trouvé, une adresse fixe approuvée ou un nom d'hôte maintenu. L'agence a besoin d'un moyen stable d'être reconnue, et en IKEv2 c'est la charge utile d'identité qu'elle présente lors de l'authentification, indépendamment de l'adresse source que ses paquets transportent. Une chaîne comme @branch-a.vpn.example sert d'identité même lorsque l'adresse mobile change toutes les heures.

Cette chaîne est comparée à la politique, pas résolue par DNS, donc n'attendez pas de recherche à l'établissement du tunnel. La configuration du concentrateur doit nommer explicitement l'identité attendue, et avec l'authentification par certificat, l'identité doit aussi correspondre à ce que le certificat affirme réellement.

Accepter n'importe quelle identité parce que l'adresse source semble plausible est le mode de défaillance à éviter. Côté répondeur, cela signifie accepter n'importe quel pair, avec un joker d'identité et un secret partagé, ce qui authentifie une chaîne plutôt qu'un appareil.

Écrivez le côté concentrateur comme un pair nommé

En termes strongSwan, le côté répondeur est une connexion avec right=%any, qui accepte un pair depuis n'importe quelle adresse source, plus [email protected], qui épingle ce que ce pair doit déclarer être. Ajoutez rightsubnet=10.20.0.0/16 pour les LAN de l'agence, auto=add pour que la connexion soit chargée sans être appelée, dpd_delay=30s pour la vivacité, et mobike=yes pour qu'un changement d'adresse soit absorbé plutôt que traité comme un nouveau pair.

D'autres fournisseurs expriment les mêmes objets sous d'autres noms, généralement un type de pair dynamique ou d'agence avec un champ d'identité et un champ de sous-réseau protégé. Remplissez les deux ; une case dynamique générique n'est pas un plan de compatibilité.

Gardez l'agence comme initiateur

Sur l'agence, l'image miroir s'applique : left=%defaultroute pour que l'adresse mobile locale soit utilisée telle quelle, [email protected] pour présenter l'identité, right=hub.example.com pour le nom stable du concentrateur, et auto=start pour que le tunnel monte sans intervention humaine. Quand la liaison mobile se reconnecte, l'agence reprend l'initiative et le concentrateur compare la même identité au même objet de politique.

Autorisez IKE sur UDP 500, la traversée NAT sur UDP 4500 et l'ESP encapsulé qui suit, des deux côtés. Puis laissez-les autorisés : une règle qui ne s'ouvre qu'aux heures de bureau ressemblera à un tunnel intermittent.

Testez le changement d'adresse, pas seulement la première poignée de main

Montez le tunnel, confirmez-le, puis forcez l'agence sur une nouvelle adresse en activant et désactivant les données mobiles ou le mode avion pendant une minute. Surveillez la liste des associations de sécurité sur le concentrateur et vérifiez que l'adresse du pair a changé alors que l'identité non. Un tunnel qui ne fonctionne que jusqu'à la première réaffectation de l'opérateur n'a pas été testé du tout.

Ensuite, vérifiez les sous-réseaux protégés séparément. Une SA établie dit que les pairs se sont authentifiés ; elle ne dit pas que le concentrateur a une route vers le LAN de l'agence ni que l'agence accepte le trafic venant du côté concentrateur. Lisez la table de routage et la politique du pare-feu séparément, puis envoyez un ping depuis un hôte plutôt que depuis la passerelle, car la passerelle est l'équipement le moins représentatif de tout réseau.

Une identité stable transforme l'agence en objet de politique que le concentrateur peut nommer. Elle ne rend pas une adresse NAT d'opérateur joignable et ne donne pas à elle seule au reste de l'organisation l'accès à l'agence.

Articles similaires