strongSwan vips : demander une adresse virtuelle à IKEv2

vips demande une adresse IKEv2 interne ; la passerelle décide de ce qu’elle accorde. Configurez la demande, chargez-la, puis vérifiez ce que le répondeur a réellement attribué.

Votre client IKEv2 peut demander une adresse interne à la passerelle, et c’est la passerelle qui décide de ce qu’elle renvoie. Dans strongSwan, cette demande est le réglage vips, et elle reste une demande même lorsque vous y écrivez une adresse précise. Le guide ci-dessous configure la demande, la charge et lit ce qui est revenu, car ces trois étapes échouent de trois manières différentes. Aucune d’elles ne raccourcit en tapant plus fort.

Ce que vips demande, et ce qu’il ne peut pas promettre

vips appartient à une définition de connexion et demande une adresse virtuelle au répondeur. Le guide strongSwan des adresses virtuelles précise que la réponse peut être une autre adresse, ou rien du tout, et c’est précisément la phrase que l’on saute quand on écrit une valeur en s’attendant à la voir apparaître. La demande vaut quand même la peine, car ce que vous vérifiez, c’est la réponse. Traitez le réglage comme une instruction pour demander, non comme la configuration du résultat.

Demander 0.0.0.0 revient à demander n’importe quelle adresse virtuelle IPv4 disponible, ce qui est généralement correct quand la valeur exacte n’a pas d’importance. Demander une adresse précise est une indication pour la passerelle, pas une exigence envers elle.

Le fragment swanctl et où il va

Le réglage se trouve à l’intérieur du bloc de connexion, ni dans son propre fichier ni dans un profil du système d’exploitation. Ce fragment isolé montre la forme :

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Chargez-le avec le fichier qui possède la connexion, puis lancez la connexion et lisez le résultat. Un fragment collé dans la mauvaise section produit une erreur d’analyse ou, pire, une connexion qui se charge sans la demande que vous croyiez avoir faite. Exécutez les trois commandes dans l’ordre et conservez la sortie.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts choisit le trafic, il ne crée pas d’adresse

local_ts nomme l’ensemble du trafic que la SA enfant protège ; il ne place pas d’adresse sur une interface. Une fois une IP virtuelle négociée, strongSwan cesse d’utiliser son sélecteur dynamique par défaut et utilise à la place l’adresse accordée. Si vous fixez le sélecteur sur une adresse littérale, vous affirmez quelque chose que la passerelle n’a peut-être pas accordé, et c’est pourquoi la panne se présente comme une SA qui fonctionne avec un trafic qui ne va nulle part. Le sélecteur décrit le trafic, tandis que l’attribution vient de l’autre échange.

L’autre façon d’obtenir une adresse interne stable est de la posséder localement. Placez l’adresse sur une interface avant que le tunnel ne monte, pointez le sélecteur vers ce qui existe déjà et organisez le pair et la route autour de cela.

Rien n’est négocié dans cette conception, donc rien ne peut être réattribué, et c’est là l’échange : le déterminisme contre le fait de faire soi-même le travail d’adressage. C’est un mécanisme différent, et non une variante de vips, ce qui explique pourquoi les deux ne doivent pas être mélangés dans une même connexion. Un sélecteur figé à côté d’une adresse négociée est une connexion qui fonctionne jusqu’à ce que la passerelle attribue autre chose.

Vérifiez ce que le répondeur a réellement attribué

Lisez la liste des SA pour trouver l’adresse que la passerelle a accordée, puis confirmez que l’adresse existe sur l’interface. Si les deux ne concordent pas, le tunnel est monté et le trafic ne va pas là où vous pensez. Une adresse accordée qui n’atteint jamais l’interface est la panne la plus déroutante de cette séquence, car chaque moitié semble correcte prise isolément.

Gardez quatre adresses distinctes dans vos notes : l’adresse interne demandée, celle qui a été accordée, l’adresse LAN de la machine et la sortie publique qu’un site web rapporte. Elles appartiennent à des couches différentes et apparaissent à des endroits différents. Un guide qui consigne les quatre est un guide qu’une autre personne peut suivre sans demander de quelle adresse vous parliez. Relisez-les après chaque rechargement, car la valeur accordée est la seule qui décrive le tunnel actif.

Gardez la conception statique à part

Si vous avez besoin d’une adresse interne fixe, organisez la réservation sur la passerelle et laissez la demande du client être une demande. Mélanger un sélecteur figé et une adresse négociée donne une connexion qui fonctionne jusqu’à ce que la passerelle attribue autre chose. Notez la règle de réservation à côté de la connexion, car c’est la partie qu’un collègue ne peut pas déduire du fichier de configuration. Un nouveau client hérite alors de la règle au lieu de la redécouvrir.

Sur le client Mac intégré, aucun de ces noms d’option n’existe. Utilisez l’attribution ou la réservation proposée par la passerelle ainsi que le profil publié par l’opérateur, et traitez toute valeur côté client comme une indication jusqu’à avoir relu l’attribution. Le retour arrière consiste à supprimer la ligne vips et à recharger, ce qui vous ramène à ce que la passerelle attribue par défaut.

Articles similaires