StrongSwan überträgt eine DNS-Adresse, die der Mac nicht erreicht

Alles funktioniert, bis jemand ein MacBook öffnet. Der Tunnel steht, interne Hosts antworten per Adresse, und die Namensauflösung stirbt. Auf dem iPhone verhält sich dasselbe Profil genauso, während die Windows- und Linux-Clients einwandfrei laufen. Meist ist das gepushte DNS-Attribut schuld: Der Server verteilt seine eigene öffentliche Schnittstellenadresse, und Apples IKEv2-Client schickt dorthin keine Anfragen durch den Tunnel. Verlegen Sie den Resolver in den Pool, und das Symptom verschwindet, ohne den Client anzufassen.

Das Symptom deutet auf die gepushte Adresse hin

Wenn nur einige Plattformen scheitern, sind Tunnel und Anmeldedaten fast sicher in Ordnung, denn die sind gemeinsam. Unterschiedlich ist, wie jeder Client die empfangene Konfigurationsnutzlast anwendet, einschließlich des internen DNS-Servers. Ein Client, der die Adresse akzeptiert, aber Anfragen am Tunnel vorbei leitet, landet bei einem Resolver, den er sieht und nicht nutzen kann.

Die öffentliche Adresse ist die übliche Wahl, weil sie die einzige ist, die der Administrator bereits kennt. Sie ist außerdem die eine Adresse, die garantiert außerhalb des eigenen Präfixes des Tunnels liegt, und genau diese Eigenschaft bricht die Apple-Clients.

Sehen Sie sich den Wert an, bevor Sie etwas ändern. Ist der gepushte Resolver die WAN-Adresse des Servers, haben Sie die Form des Problems gefunden und können sich den Rest des Ratens sparen. Vergleichen Sie ihn auch mit dem Pool-Präfix, denn eine Adresse innerhalb des Pools, aber außerhalb des vergebenen Bereichs ist genau das, wie die Lösung aussehen wird. Zwei Minuten mit der Konfiguration schlagen einen Nachmittag Paketmitschnitte auf dem Client.

Den Resolver aus dem Lease-Bereich herausschneiden

Geben Sie dem Tunnel einen Adressplan, in dem der Resolver Mitglied des eigenen Subnetzes des Pools ist, und reservieren Sie diese Adresse dann, damit sie niemals an einen Client vergeben wird. In diesem Beispiel ist der Pool 10.180.7.0/24, der Server hält 10.180.7.1, und die Leases beginnen bei 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Pool-Präfix und Resolver teilen sich ein Subnetz, sodass die Route, die bereits Tunnelverkehr trägt, auch die Anfragen trägt. Diese eine Eigenschaft macht die Lösung über alle Clients hinweg übertragbar. In einer swanctl-Konfiguration erscheinen dieselben zwei Fakten als Pool-Definition und DNS-Einstellung an der Verbindung statt in der ipsec.conf-Syntax.

Der Server braucht dafür keine neue physische Schnittstelle. 10.180.7.1 zur Loopback-Schnittstelle hinzuzufügen genügt, damit ein Resolver binden und antworten kann, denn Clients erreichen ihn über die Pool-Route, die bereits existiert. Halten Sie die Adresse aus dem Lease-Bereich heraus, damit kein Client sie versehentlich beansprucht. Wenn der Pool von einem externen DHCP- oder RADIUS-Dienst verwaltet wird, reservieren Sie die Adresse auch dort, sonst nimmt sie der erste Client, der danach fragt.

Den Resolver binden und Port 53 schließen

Eine Adresse zuzuweisen ist nicht dasselbe wie darauf zu lauschen. Ein Resolver, der nur auf der LAN-Adresse lauscht, weist Anfragen an die Pool-Adresse ab oder ignoriert sie, und der Client sieht einen Timeout, der wie ein Routing-Fehler aussieht.

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

Dieses unbound-Fragment akzeptiert Anfragen aus dem Tunnel-Pool und weist alles andere ab, was der Richtlinie entspricht, die die meisten Unternehmens-Resolver wollen. Wenn dieselbe Instanz auch LAN-Clients beantwortet, fügen Sie das LAN-Präfix ausdrücklich hinzu, statt den Listener auf alle Quellen zu erweitern.

Die Firewall-Regeln müssen dann mit der Zugriffskontrolle des Resolvers übereinstimmen. Akzeptieren Sie Port 53 aus dem Pool und verwerfen Sie ihn überall sonst, aber prüfen Sie zuerst die Reihenfolge der Kette.

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

Eine frühere, breitere Accept-Regel macht die letzten beiden Zeilen zur Dekoration, und der Resolver bleibt aus dem Internet erreichbar. Lesen Sie das effektive Regelset mit den Zählern, statt der beabsichtigten Reihenfolge zu vertrauen. Die alternative Richtlinie, die öffentliche Adresse zu pushen und Anfragen von jeder Quelle zu erlauben, funktioniert für viele Clients, setzt den Resolver aber ins Internet und braucht eigene Ratenbegrenzung und Überwachung.

Prüfen, was der Client tatsächlich erhalten hat

Prüfen Sie zuerst die Sicht des Servers, dann die des Clients, denn die beiden widersprechen sich auf informative Weise. Eine Pool-Auflistung zeigt, welche Adresse vergeben wurde, und die Auflistung der Security Associations zeigt, ob die Verbindung mit der erwarteten Identität steht.

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

Die direkte Abfrage beweist, dass der Resolver auf der Pool-Adresse von einem Host aus antwortet, der sie erreichen kann. Sie beweist nicht, dass der Mac diesen Server gewählt hat. Unter macOS listet scutil --dns Resolver pro zugeordnetem Dienst auf und ist informativer als das Übersichtsfenster; unter Windows zeigt Get-DnsClientServerAddress, ob der Tunneladapter den gepushten Wert übernommen hat.

Wenn der Client die Pool-Adresse anzeigt und Anfragen trotzdem in einen Timeout laufen, liegt der Fehler an der Tunnel-Route oder an der Firewall-Kette. Ein Client, der keinen Resolver meldet, bedeutet, dass die Konfigurationsnutzlast nie angekommen ist; schauen Sie also darauf, wie diese Plattform gepushte Einstellungen anwendet, statt auf das Netzwerk. Notieren Sie, welchen der beiden Fälle Sie beobachtet haben, bevor Sie etwas anderes ändern. Diese beiden Fehler sehen in einem Support-Ticket identisch aus und führen zu entgegengesetzten Reparaturen.