Pools VPN double pile : adresser les deux familles dans strongSwan

Les pools IPv4 et IPv6 internes, les préfixes protégés et la famille du tunnel externe sont trois décisions distinctes. Planifiez chacune avant de parler de double pile.

Une passerelle peut fournir à un travailleur nomade à la fois une adresse virtuelle IPv4 et une adresse IPv6, tandis que le tunnel externe circule encore sur IPv4. Ce sont des décisions indépendantes, et c’est en les traitant comme une seule que les plans double pile s’effondrent généralement. Les familles internes du client, les préfixes protégés qu’il peut joindre et le transport qui porte l’encapsulation sont trois choix distincts.

L’essentiel de la confusion vient de ce que l’expression double pile est appliquée à une conception qui n’est double pile qu’à un seul endroit. Un service peut être double pile en interne, simple pile sur son adresse externe, et néanmoins fonctionner parfaitement bien pour les clients. Ce qu’il ne peut pas faire, c’est fonctionner par accident.

Deux familles à l’intérieur, un seul chemin à l’extérieur

La connexion externe est IKE sur UDP, et elle a besoin d’une famille d’adresses joignable depuis l’endroit où se trouve le client. Une adresse IPv6 interne n’exige pas un fournisseur compatible IPv6, car le paquet interne est la charge utile à l’intérieur du paquet externe. Beaucoup de déploiements qui fonctionnent transportent des préfixes IPv6 par une liaison montante uniquement IPv4.

Ce que le chemin externe contraint réellement, c’est la joignabilité et la traversée NAT. Si la passerelle n’annonce qu’une adresse IPv4, un client sur un réseau uniquement IPv6 ne peut pas se connecter du tout, quels que soient les pools configurés. Décidez la famille externe d’après votre population de clients, pas d’après le plan d’adressage interne.

Donnez au client une adresse dans chaque famille

Demander les deux familles tient en une ligne côté client, à condition que la passerelle ait quelque chose à distribuer. Les pools nommés gardent les sources séparées des réseaux de service, et c’est cette propriété qui rend les règles de pare-feu lisibles six mois plus tard.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

La vips valeur demande une adresse de chaque famille, et la liste des pools décide d’où viennent ces adresses. La documentation strongSwan sur les IP virtuelles couvre les demandes multiples et l’attribution des pools, y compris le point qu’un client qui demande une adresse précise exprime une préférence que le répondeur peut outrepasser. Ne construisez pas de règle d’accès qui suppose que le client reçoit toujours la même valeur.

Générez votre propre préfixe local unique au lieu de copier celui de l’exemple. Deux organisations qui toutes deux fd42::/16 le déploient découvriront la collision la première fois qu’elles s’interconnectent, et le diagnostic n’est pas agréable.

Les sélecteurs décrivent des destinations, pas des sources

Les sélecteurs de trafic locaux de l’AS enfant indiquent quels réseaux protégés se trouvent derrière la passerelle, et les sélecteurs distants décrivent ce que le client peut utiliser comme source. Une adresse de pool virtuel appartient au côté source de cette politique ; la placer dans la liste des destinations est une mauvaise lecture courante de la configuration.

Les deux familles ont besoin de routes de retour et d’un transfert autorisé sur la passerelle. Ajouter un préfixe à un sélecteur sans route de retour vers le pool produit un tunnel qui s’établit, laisse passer un sens du trafic et abandonne la réponse en silence. Le sélecteur est de la politique, pas du routage.

Gardez les pools et les préfixes de service dans des blocs séparés de votre plan d’adressage. Quand ils se chevauchent, une route censée atteindre un hôte protégé peut correspondre à une adresse de pool et disparaître dans le tunnel.

Le DNS et le chemin de retour décident si cela semble terminé

Les réponses du résolveur sont indépendantes du transport utilisé pour l’atteindre. Un nom peut renvoyer un enregistrement A, un enregistrement AAAA ou les deux, et le client choisit selon ses propres règles de préférence . Si un service interne publie un enregistrement AAAA mais que rien ne route ce préfixe, les clients sur des réseaux double pile essaieront d’abord le chemin IPv6 et y resteront jusqu’à l’échec. Rien dans la configuration du tunnel ne semble faux pendant ce temps.

Décidez donc, nom par nom, quelles familles doivent être utilisables, puis vérifiez que le préfixe correspondant figure dans le sélecteur et possède une route de retour. C’est une décision service par service. Publier les deux types d’enregistrement sans discernement, c’est ainsi qu’un service qui fonctionne uniquement en IPv4 commence à expirer pour la moitié de ses utilisateurs.

Vérifiez les deux familles avant de le déclarer terminé

Une configuration qui se charge n’est pas une configuration qui fonctionne. Lisez l’état que rapporte le démon, confirmez les attributions de pools, puis regardez les routes que le client a réellement installées.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Les deux premières commandes montrent les AS enfants établies et quels pools ont encore des adresses disponibles, de sorte qu’un plan qui fonctionne pour le premier client et échoue pour le dixième devient visible. Les deux dernières montrent si le client a reçu une adresse IPv6 globale du pool et où le trafic vers un préfixe protégé irait réellement. Comparez l’adresse attribuée au pool que vous avez configuré, pas à l’adresse que vous espériez. Si le répondeur a choisi une autre valeur selon sa politique, les routes et les règles de pare-feu doivent toujours correspondre à ce qu’il a choisi.

Testez ensuite un hôte protégé par famille, et testez un nom qui résout vers les deux. Un test sur une seule famille ne vous dit rien de la moitié du plan que vous n’avez pas exercée, et c’est généralement là que se trouve la route manquante.

Articles similaires