Planifier un accès privé IKEv2 double pile avec strongSwan

Un tunnel double pile n’est pas une décision mais trois, et on peut y répondre différemment. Sur quelle famille le tunnel extérieur circule, quelles familles le client reçoit à l’intérieur et sur quelles familles les services protégés répondent réellement. Une conception qui les traite comme un seul choix transporte soit de l’IPv6 dont on n’a jamais eu besoin, soit distribue des adresses que rien ne peut router en retour. Séparez les trois et le reste de la configuration devient presque mécanique.

Trois types d’adresse, décidés séparément

L’adresse extérieure est la manière dont les deux passerelles se joignent, et elle peut être en IPv4 tandis que le trafic intérieur transporte les deux familles. L’adresse virtuelle intérieure est l’identité du client dans le tunnel, et chaque famille a besoin de son propre bassin. Les préfixes protégés sont ce que le client peut atteindre, et ils appartiennent aux services et non au tunnel. Confondre le troisième avec le second cause la plupart des erreurs de planification, parce que les deux ressemblent à des plages privées.

Un transport extérieur en IPv4 seul avec un trafic intérieur double pile est un agencement normal et bien pris en charge.

Décidez chacune explicitement et écrivez les décisions. Si le chemin extérieur est en IPv4 seul, dites-le et cessez de vous inquiéter de l’accessibilité des points d’extrémité IPv6. Si une famille est attribuée à l’intérieur mais que rien n’y répond, soit retirez-la du plan, soit rendez ces services réellement double pile.

Attribuez une adresse virtuelle dans chaque famille

Dans une configuration swanctl, le client demande des adresses virtuelles, et un joker dans chaque famille demande au répondeur d’en attribuer une de chacune. Le répondeur les tire de bassins, et les bassins sont des objets distincts des réseaux derrière la passerelle. Gardez-les distincts dans le plan aussi, car un bassin qui chevauche un préfixe de service produit un routage qui paraît correct jusqu’au moment où le trafic atterrit quelque part d’inattendu.

Demandez les deux familles quand vous avez besoin des deux, et une seule quand vous n’en avez pas besoin, car une adresse inutilisée est une surface de politique sans bénéfice. Une demande précise est une demande et non une réservation, et le répondeur peut renvoyer une autre valeur selon sa propre politique. Ce détail compte partout où une adresse est codée en dur dans une règle de pare-feu ou une vérification de supervision. Référencez les bassins par leur nom dans la connexion et gardez les réseaux de services hors d’eux.

vips = 0.0.0.0, ::

Générez votre propre préfixe local unique pour le bassin IPv6 au lieu d’adopter une courte valeur d’exemple. L’exemple montre la forme du réglage, pas une valeur par défaut à hériter.

Décrivez les destinations à part des bassins

Les sélecteurs de trafic décrivent ce que chaque côté s’attend à échanger, donc les sélecteurs locaux de la passerelle doivent nommer des préfixes de services protégés et non des bassins de clients. Les sélecteurs distants du client reflètent cette intention. Quand les deux listes décrivent des objets différents, le tunnel peut monter et ne rien transporter d’utile.

Ces mêmes préfixes ont besoin de routes de retour et d’un transfert autorisé à l’intérieur du réseau de la passerelle, pour chaque famille que vous activez.

C’est ici qu’un plan IPv6 privé cesse de suffire. L’adressage local unique achète une atteignabilité privée et ne crée pas de sortie IPv6 publique, donc une conception qui suppose que la famille non numérotée suivra simplement les règles de masquage IPv4 décevra ses utilisateurs. Si l’accès IPv6 public fait partie de l’exigence, il faut un plan routé et un amont qui l’accepte. Sinon, dites clairement que le côté IPv6 est privé uniquement, ce qui est une frontière honnête et non une limitation à cacher.

Rendez le DNS et les chemins de retour intentionnels

La résolution de noms ne suit pas le transport. Un résolveur peut renvoyer des enregistrements A et AAAA à travers un tunnel IPv4 seul, et le client essaiera alors une famille que vous n’avez jamais planifiée. Décidez quels noms de service doivent porter des réponses double pile utilisables et rendez ces deux chemins intentionnels. Un nom qui résout vers une famille sans chemin fonctionnel produit un blocage plutôt qu’une erreur propre, et les blocages sont bien plus difficiles à diagnostiquer.

Documentez l’accessibilité du point d’extrémité extérieur séparément, y compris si une traversée NAT est en jeu et quelle famille elle utilise.

Écrivez ensuite le plan en six lignes : point d’extrémité extérieur, bassin IPv4, bassin IPv6, préfixe de service IPv4, préfixe de service IPv6 et le routeur qui possède les réponses pour chacun. Un plan de cette forme répond aux questions qu’un opérateur pose réellement à trois heures du matin. Tout ce qui est plus court laisse la double pile comme une seconde adresse boulonnée à une politique IPv4 seule, et c’est ainsi qu’elle finit généralement à moitié fonctionnelle.