StrongSwan invia un indirizzo DNS che il Mac non riesce a raggiungere

Tutto funziona finché qualcuno non apre un MacBook. Il tunnel si stabilisce, gli host interni rispondono per indirizzo e la risoluzione dei nomi muore. Sull’iPhone lo stesso profilo si comporta allo stesso modo, mentre i client Windows e Linux stanno bene. Di solito il colpevole è l’attributo DNS inviato: il server distribuisce il proprio indirizzo pubblico di interfaccia e il client IKEv2 di Apple non invia lì le query attraverso il tunnel. Sposta il resolver nel pool e il sintomo scompare senza toccare il client.

Il sintomo punta all’indirizzo inviato

Quando falliscono solo alcune piattaforme, il tunnel e le credenziali sono quasi certamente a posto, perché sono condivisi. Ciò che cambia è come ogni client applica il payload di configurazione che riceve, incluso il server DNS interno. Un client che accetta l’indirizzo ma instrada le query fuori dal tunnel finisce con un resolver che vede e non può usare.

L’indirizzo pubblico è la scelta abituale perché è l’unico che l’amministratore già conosce. È anche l’unico indirizzo garantito fuori dal prefisso del tunnel stesso, ed è proprio questa proprietà a rompere i client di Apple.

Guarda il valore prima di cambiare qualcosa. Se il resolver inviato è l’indirizzo WAN del server, hai trovato la forma del problema e puoi saltare il resto delle congetture. Confrontalo anche con il prefisso del pool, perché un indirizzo dentro il pool ma fuori dall’intervallo assegnato è esattamente come sarà la correzione. Due minuti con la configurazione valgono più di un pomeriggio di catture di pacchetti sul client.

Ritaglia il resolver fuori dall’intervallo di assegnazione

Dai al tunnel un piano di indirizzi in cui il resolver è membro della sottorete del pool stesso, poi riserva quell’indirizzo in modo che non venga mai assegnato a un client. In questo esempio il pool è 10.180.7.0/24, il server tiene 10.180.7.1 e le assegnazioni iniziano da 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Il prefisso del pool e il resolver condividono una sottorete, quindi la rotta che già trasporta il traffico del tunnel trasporta anche le query. È proprio questa unica proprietà a rendere la correzione portabile tra i client. In una configurazione swanctl gli stessi due fatti compaiono come definizione del pool e impostazione DNS sulla connessione invece che nella sintassi di ipsec.conf.

Il server non ha bisogno di una nuova interfaccia fisica per questo. Aggiungere 10.180.7.1 all’interfaccia di loopback basta perché un resolver si associ e risponda, dato che i client lo raggiungono tramite la rotta del pool che esiste già. Tieni l’indirizzo fuori dall’intervallo di assegnazione così nessun client lo rivendichi per caso. Se il pool è gestito da un servizio DHCP o RADIUS esterno, riserva l’indirizzo anche lì, altrimenti il primo client che chiede se lo prende.

Associa il resolver e chiudi la porta 53

Assegnare un indirizzo non è la stessa cosa che ascoltarci sopra. Un resolver che ascolta solo sull’indirizzo LAN rifiuterà o ignorerà le query inviate all’indirizzo del pool, e il client vede un timeout che sembra un guasto di routing.

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

Quel frammento unbound accetta query dal pool del tunnel e rifiuta tutto il resto, che è la politica che vogliono la maggior parte dei resolver aziendali. Se la stessa istanza risponde anche ai client LAN, aggiungi esplicitamente il prefisso LAN invece di ampliare l’ascoltatore a tutte le sorgenti.

Poi le regole del firewall devono essere coerenti con il controllo degli accessi del resolver stesso. Accetta la porta 53 dal pool e scartala ovunque altrove, ma controlla prima l’ordine della catena.

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

Una regola di accettazione precedente e più ampia rende decorative le ultime due righe, e il resolver resta raggiungibile da internet. Leggi l’insieme effettivo delle regole con i contatori invece di fidarti dell’ordine che intendevi. La politica alternativa, inviare l’indirizzo pubblico e consentire query da qualsiasi sorgente, funziona per molti client, ma mette il resolver su internet e richiede la propria limitazione di velocità e il proprio monitoraggio.

Verifica cosa ha ricevuto davvero il client

Controlla prima la vista del server, poi quella del client, perché le due discordano in modo istruttivo. Un elenco del pool mostra quale indirizzo è stato assegnato, e l’elenco delle associazioni di sicurezza mostra se la connessione è attiva con l’identità prevista.

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

La query diretta dimostra che il resolver risponde sull’indirizzo del pool da un host che può raggiungerlo. Non dimostra che il Mac abbia scelto quel server. Su macOS, scutil --dns elenca i resolver per servizio con ambito ed è più istruttivo del pannello di riepilogo; su Windows, Get-DnsClientServerAddress mostra se l’adattatore del tunnel ha accettato il valore inviato.

Se il client mostra l’indirizzo del pool e le query continuano ad andare in timeout, la colpa è della rotta del tunnel o della catena del firewall. Un client che non segnala alcun resolver significa che il payload di configurazione non è mai arrivato, quindi guarda come quella piattaforma applica le impostazioni inviate invece della rete. Annota quale dei due casi hai osservato prima di cambiare qualsiasi altra cosa. Quei due guasti sembrano identici in un ticket di supporto e portano a riparazioni opposte.