Le tunnel complet dans strongSwan exige 0.0.0.0/0 des deux côtés

Un tunnel complet exige 0.0.0.0/0 comme remote_ts du client et comme local_ts de la passerelle, plus le transfert, le NAT et une route de retour. Vérifiez les quatre.

Une connexion strongSwan qui fonctionne pour un seul sous-réseau privé ne transportera pas le trafic internet simplement parce que quelqu'un a modifié une ligne. Un tunnel complet est un accord entre deux pairs sur les adresses que la child SA protège, et chaque pair nomme l'autre côté par rapport à lui-même. Juste d'un côté et faux de l'autre, et la child SA ne monte pas ou monte plus étroite que prévu. Les cinq vérifications ci-dessous suivent cet accord du client, à travers la passerelle, jusqu'à internet.

Vérifiez d'abord le sélecteur du client

Le client décrit ce qu'il veut protéger de l'autre côté comme remote_ts, et tout ce qu'il envoie part de sa propre adresse attribuée. Pour le trafic internet, cette valeur doit couvrir les destinations que l'utilisateur atteindra réellement, ce qui signifie en pratique tout l'espace IPv4. Un client qui liste encore un sous-réseau demande un tunnel divisé, quel que soit le nom du profil dans l'interface. Le côté source est généralement dynamic, car l'adresse est attribuée à la connexion. Une source fixe écrite là casse dès que le pool change.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Le fragment n'est pas un fichier de connexion complet, et celui-ci suppose que l'authentification, les identités et le pool d'adresses virtuelles sont déjà configurés. Le sélecteur de source du client et l'adresse attribuée par le serveur doivent encore s'accorder, sinon la child SA monte avec une portée qu'aucun des deux côtés n'attendait. Chargez-le avec swanctl --load-all et lisez la sortie avant de supposer le succès. Un fichier qui s'analyse peut toujours être rejeté à cause d'un sélecteur qui ne recoupe pas la proposition de l'autre pair.

Vérifiez le sélecteur de la passerelle de son côté

La passerelle lit le même concept dans la direction opposée. Les destinations internet sont locales pour la passerelle, donc son local_ts est le large et son remote_ts décrit le pool de clients. Cette inversion est l'erreur la plus courante dans une configuration de tunnel complet, et elle survit à la relecture parce que les deux lignes semblent plausibles séparément.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copier le fragment du client dans le fichier de la passerelle produit une paire de sélecteurs qui ne décrit rien d'utile, car les deux côtés revendiqueraient le même rôle. Le guide de transfert de strongSwan documente explicitement l'appariement client-passerelle, et il vaut la peine de le lire à côté du fichier de connexion plutôt qu'après l'échec. Le fichier de la passerelle a aussi besoin de la définition du pool auquel remote_ts fait référence. Un sélecteur qui nomme un pool inexistant se charge sans broncher et échoue à la connexion.

L'ancien ipsec.conf utilise des rôles gauche et droit avec des clés différentes, et une ligne rightsubnet n'est pas un remplacement direct de la valeur swanctl. Gardez les deux syntaxes dans des fichiers séparés au lieu de coller l'une dans l'autre. Les mélanger dans un même répertoire est la façon dont une connexion qui fonctionne revient en silence après un redémarrage.

Vérifiez la child SA négociée, pas le fichier

Une configuration enregistrée prouve l'intention et rien de plus. L'autre pair peut réduire ce qui a été demandé, et une child SA existante n'est pas remplacée simplement parce que le fichier en dessous a changé. Confirmez ce qui est réellement installé avant de changer quoi que ce soit d'autre.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

La première commande montre ce que le démon a chargé, la deuxième montre les child SA établies et la troisième les politiques que le noyau appliquera. Si le fichier dit 0.0.0.0/0 et que la liste montre un seul sous-réseau, la négociation a réduit la portée et relire le fichier ne l'expliquera pas. Terminez la child, relancez-la et comparez à nouveau les trois sorties. Une child qui revient avec la même portée étroite est réduite par l'autre côté et non par le fichier local, et c'est une conversation avec l'autre administrateur plutôt qu'une modification locale.

Lisez les deux directions dans la liste des politiques, car un tunnel qui installe une direction et pas l'autre est un problème de routage déguisé en configuration. Les politiques aller et retour doivent nommer la même paire de sélecteurs en miroir, et un miroir manquant est un défaut du démon ou de la proposition, pas du texte du sélecteur.

Vérifiez le transfert et la route de retour

Un sélecteur admet le trafic vers la passerelle ; il ne fait pas acheminer ce trafic plus loin par la passerelle. Le transfert doit être activé, le pare-feu doit autoriser le flux et la réponse doit trouver le chemin du retour vers le pool de clients. Ce sont trois exigences distinctes, et chacune échoue avec un symptôme différent. Une règle de transfert manquante se comporte comme un trou noir, tandis qu'une route de retour manquante se comporte comme un tunnel à sens unique.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Les adresses privées des clients ont généralement besoin d'une traduction de source délibérée avant de quitter une interface publique, tandis qu'une allocation routée explicitement demande un autre traitement. Si le NAT entre en jeu, conservez les exceptions prises en charge par l'implémentation pour que le trafic qu'une politique de sécurité doit inspecter ne soit pas traduit au-delà. Une règle masquerade large copiée d'une autre passerelle modifie bien plus de flux que son auteur ne l'entendait. Écrivez la règle uniquement pour le pool de clients et laissez un commentaire expliquant pourquoi elle existe.

Sur le client, confirmez les routes installées par le backend plutôt que les routes que vous avez supposées. Un gestionnaire dont l'installation des routes est désactivée a besoin d'une conception de routage maintenue à la main, et cette conception doit être mise à jour chaque fois que le tunnel change. Vérifiez la table de routage après une reconnexion, pas seulement après un démarrage propre.

Vérifiez ce que le tunnel ne couvre toujours pas

La paire de sélecteurs couvre IPv4 et rien d'autre. IPv6, le DNS et toute politique au niveau applicatif sont des décisions distinctes qu'un sélecteur IPv4 large ignore en silence. Un tunnel qui transporte chaque paquet IPv4 peut encore laisser fuir chaque résolution de nom.

Énoncez explicitement le chemin DNS prévu, car un tunnel complet qui résout encore les noms via le résolveur local fait fuir les requêtes hors du tunnel et casse les noms privés. Si une adresse IPv6 est attribuée au client, cette famille d'adresses a besoin du même traitement, sinon l'hôte préférera un chemin que le tunnel ne protège pas. Testez avec un nom que seul le côté privé peut résoudre, et traitez une réponse publique comme une fuite.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirmez la chaîne avec ces deux commandes plus les sélecteurs négociés de la liste ci-dessus. Si le traceroute montre le routeur local comme premier saut, le trafic n'utilise pas le tunnel quoi qu'affirment les sélecteurs. L'accès à internet n'est complet que lorsque le trafic choisi est admis, transféré et renvoyé par la passerelle conçue. Trouver 0.0.0.0/0 dans un profil est le début de cette chaîne, pas sa preuve.

Articles similaires