StrongSwan pusht een DNS-adres dat de Mac niet kan bereiken

Alles werkt tot iemand een MacBook opent. De tunnel komt tot stand, interne hosts antwoorden op adres en naamresolutie sterft. Op de iPhone gedraagt hetzelfde profiel zich hetzelfde, terwijl de Windows- en Linux-clients in orde zijn. Meestal is het gepushte DNS-attribuut de schuldige: de server deelt zijn eigen openbare interfaceadres uit, en Apples IKEv2-client stuurt daar geen queries door de tunnel heen. Verplaats de resolver naar de pool en het symptoom verdwijnt zonder de client aan te raken.

Het symptoom wijst naar het gepushte adres

Wanneer alleen sommige platforms falen, zijn de tunnel en de inloggegevens vrijwel zeker in orde, want die worden gedeeld. Wat verschilt, is hoe elke client de ontvangen configuratielading toepast, inclusief de interne DNS-server. Een client die het adres accepteert maar queries om de tunnel heen leidt, houdt een resolver over die hij ziet en niet kan gebruiken.

Het openbare adres is de gebruikelijke keuze omdat het het enige is dat de beheerder al kent. Het is ook het enige adres dat gegarandeerd buiten het eigen prefix van de tunnel ligt, en precies die eigenschap breekt de clients van Apple.

Kijk naar de waarde voordat je iets verandert. Als de gepushte resolver het WAN-adres van de server is, heb je de vorm van het probleem gevonden en kun je de rest van het giswerk overslaan. Vergelijk het ook met het poolprefix, want een adres binnen de pool maar buiten het leasebereik is precies hoe de oplossing eruit komt te zien. Twee minuten met de configuratie verslaan een middag pakketopnames op de client.

Snijd de resolver uit het leasebereik

Geef de tunnel een adresplan waarin de resolver lid is van het eigen subnet van de pool, en reserveer dat adres vervolgens zodat het nooit aan een client wordt verhuurd. In dit voorbeeld is de pool 10.180.7.0/24, houdt de server 10.180.7.1 en beginnen de leases bij 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Het poolprefix en de resolver delen een subnet, dus de route die al tunnelverkeer draagt, draagt ook de queries. Precies die ene eigenschap maakt de oplossing overdraagbaar tussen clients. In een swanctl-configuratie verschijnen dezelfde twee feiten als pooldefinitie en DNS-instelling op de verbinding in plaats van in ipsec.conf-syntaxis.

De server heeft hiervoor geen nieuwe fysieke interface nodig. 10.180.7.1 toevoegen aan de loopback-interface is genoeg voor een resolver om te binden en te antwoorden, omdat clients hem bereiken via de poolroute die al bestaat. Houd het adres buiten het leasebereik zodat geen enkele client het per ongeluk claimt. Als de pool door een externe DHCP- of RADIUS-dienst wordt beheerd, reserveer het adres daar dan ook, anders neemt de eerste client die vraagt het.

Bind de resolver en sluit poort 53

Een adres toewijzen is niet hetzelfde als erop luisteren. Een resolver die alleen op het LAN-adres luistert, weigert of negeert queries die naar het pooladres worden gestuurd, en de client ziet een time-out die op een routeringsfout lijkt.

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

Dat unbound-fragment accepteert queries uit de tunnelpool en weigert al het andere, wat het beleid is dat de meeste bedrijfsresolvers willen. Als dezelfde instantie ook LAN-clients antwoordt, voeg dan expliciet het LAN-prefix toe in plaats van de listener naar alle bronnen te verbreden.

Daarna moeten de firewallregels overeenkomen met de eigen toegangscontrole van de resolver. Accepteer poort 53 uit de pool en laat hem overal elders vallen, maar controleer eerst de volgorde van de keten.

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

Een eerdere, bredere acceptatieregel maakt de laatste twee regels decoratief, en de resolver blijft bereikbaar vanaf het internet. Lees de effectieve regelset met de tellers in plaats van te vertrouwen op de volgorde die je bedoelde. Het alternatieve beleid, het openbare adres pushen en queries van elke bron toestaan, werkt voor veel clients, maar zet de resolver op het internet en vereist zijn eigen snelheidsbeperking en monitoring.

Controleer wat de client werkelijk heeft ontvangen

Bekijk eerst het beeld van de server, dan dat van de client, want de twee verschillen op informatieve manieren. Een poollijst toont welk adres is verhuurd, en de lijst met beveiligingsassociaties toont of de verbinding omhoog is met de verwachte identiteit.

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

De directe query bewijst dat de resolver antwoordt op het pooladres vanaf een host die hem kan bereiken. Het bewijst niet dat de Mac die server heeft gekozen. Op macOS somt scutil --dns resolvers per afgebakende dienst op en is informatiever dan het samenvattingspaneel; op Windows toont Get-DnsClientServerAddress of de tunneladapter de gepushte waarde heeft geaccepteerd.

Als de client het pooladres toont en queries nog steeds time-out geven, is de tunnelroute of de firewallketen schuld. Een client die geen enkele resolver meldt, betekent dat de configuratielading nooit is aangekomen, dus kijk hoe dat platform gepushte instellingen toepast in plaats van naar het netwerk. Schrijf op welke van de twee gevallen je zag voordat je iets anders verandert. Die twee storingen lijken identiek in een supportticket en leiden tot tegengestelde reparaties.