StrongSwan envoie une adresse DNS que le Mac ne peut pas atteindre

Tout fonctionne jusqu’à ce que quelqu’un ouvre un MacBook. Le tunnel s’établit, les hôtes internes répondent par adresse et la résolution de noms meurt. Sur l’iPhone, le même profil se comporte de la même manière, tandis que les clients Windows et Linux vont bien. Le coupable est généralement l’attribut DNS poussé : le serveur distribue sa propre adresse publique d’interface, et le client IKEv2 d’Apple n’y envoie pas de requêtes via le tunnel. Déplacez le résolveur dans le pool et le symptôme disparaît sans toucher au client.

Le symptôme pointe vers l’adresse poussée

Quand seules certaines plateformes échouent, le tunnel et les identifiants sont presque certainement corrects, car ils sont partagés. Ce qui diffère, c’est la façon dont chaque client applique la charge de configuration qu’il reçoit, y compris le serveur DNS interne. Un client qui accepte l’adresse mais achemine les requêtes en dehors du tunnel se retrouve avec un résolveur qu’il voit et ne peut pas utiliser.

L’adresse publique est le choix habituel car c’est la seule que l’administrateur connaît déjà. C’est aussi la seule adresse garantie hors du préfixe propre au tunnel, et c’est précisément cette propriété qui casse les clients Apple.

Regardez la valeur avant de changer quoi que ce soit. Si le résolveur poussé est l’adresse WAN du serveur, vous avez trouvé la forme du problème et pouvez sauter le reste des suppositions. Comparez-la aussi avec le préfixe du pool, car une adresse à l’intérieur du pool mais hors de la plage allouée est exactement à quoi ressemblera le correctif. Deux minutes avec la configuration valent mieux qu’un après-midi de captures de paquets sur le client.

Découpez le résolveur hors de la plage d’attribution

Donnez au tunnel un plan d’adressage où le résolveur est membre du sous-réseau propre au pool, puis réservez cette adresse pour qu’elle ne soit jamais attribuée à un client. Dans cet exemple, le pool est 10.180.7.0/24, le serveur détient 10.180.7.1 et les attributions commencent à 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Le préfixe du pool et le résolveur partagent un sous-réseau, donc la route qui transporte déjà le trafic du tunnel transporte aussi les requêtes. Cette seule propriété rend le correctif portable entre clients. Dans une configuration swanctl, les deux mêmes faits apparaissent comme définition de pool et réglage DNS sur la connexion plutôt que dans la syntaxe d’ipsec.conf.

Le serveur n’a pas besoin d’une nouvelle interface physique pour cela. Ajouter 10.180.7.1 à l’interface de bouclage suffit pour qu’un résolveur s’y lie et réponde, puisque les clients l’atteignent par la route du pool qui existe déjà. Gardez l’adresse hors de la plage d’attribution pour qu’aucun client ne la réclame par accident. Si le pool est géré par un service DHCP ou RADIUS externe, réservez aussi l’adresse là-bas, sinon le premier client qui demande la prendra.

Liez le résolveur et fermez le port 53

Attribuer une adresse n’est pas la même chose qu’y écouter. Un résolveur qui n’écoute que sur l’adresse LAN refusera ou ignorera les requêtes envoyées à l’adresse du pool, et le client voit un délai d’attente qui ressemble à une panne de routage.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Ce fragment unbound accepte les requêtes du pool du tunnel et refuse tout le reste, ce qui est la politique que veulent la plupart des résolveurs d’entreprise. Si la même instance répond aussi aux clients du LAN, ajoutez explicitement le préfixe LAN au lieu d’élargir l’écouteur à toutes les sources.

Les règles de pare-feu doivent alors s’accorder avec le contrôle d’accès propre au résolveur. Acceptez le port 53 depuis le pool et rejetez-le partout ailleurs, mais vérifiez d’abord l’ordre de la chaîne.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Une règle d’acceptation antérieure et plus large rend les deux dernières lignes décoratives, et le résolveur reste joignable depuis Internet. Lisez l’ensemble effectif des règles avec les compteurs plutôt que de faire confiance à l’ordre prévu. La politique alternative, pousser l’adresse publique et autoriser les requêtes de n’importe quelle source, fonctionne pour de nombreux clients, mais expose le résolveur sur Internet et nécessite sa propre limitation de débit et sa surveillance.

Vérifiez ce que le client a réellement reçu

Vérifiez d’abord la vue du serveur, puis celle du client, car les deux divergent de manière instructive. Une liste du pool montre quelle adresse a été attribuée, et la liste des associations de sécurité montre si la connexion est établie avec l’identité attendue.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

La requête directe prouve que le résolveur répond sur l’adresse du pool depuis un hôte qui peut l’atteindre. Elle ne prouve pas que le Mac a choisi ce serveur. Sur macOS, scutil --dns liste les résolveurs par service délimité et est plus instructif que le panneau de synthèse ; sur Windows, Get-DnsClientServerAddress montre si l’adaptateur du tunnel a accepté la valeur poussée.

Si le client affiche l’adresse du pool et que les requêtes expirent toujours, la route du tunnel ou la chaîne de pare-feu est en cause. Un client qui ne signale aucun résolveur signifie que la charge de configuration n’est jamais arrivée, alors regardez comment cette plateforme applique les paramètres poussés plutôt que le réseau. Notez lequel des deux cas vous avez observé avant de changer autre chose. Ces deux défaillances semblent identiques dans un ticket de support et mènent à des réparations opposées.