StrongSwan envia una adreça DNS que el Mac no pot assolir

Tot funciona fins que algú obre un MacBook. El túnel s’estableix, els hosts interns responen per adreça i la resolució de noms mor. A l’iPhone, el mateix perfil es comporta igual, mentre que els clients de Windows i Linux van bé. Normalment el culpable és l’atribut DNS enviat: el servidor reparteix la seva pròpia adreça pública d’interfície, i el client IKEv2 d’Apple no hi envia consultes a través del túnel. Moveu el resolutor dins del pool i el símptoma desapareix sense tocar el client.

El símptoma apunta a l’adreça enviada

Quan només fallen algunes plataformes, el túnel i les credencials gairebé segur que estan bé, perquè són compartits. El que canvia és com cada client aplica la càrrega de configuració que rep, inclòs el servidor DNS intern. Un client que accepta l’adreça però encamina les consultes per fora del túnel acaba amb un resolutor que veu i no pot fer servir.

L’adreça pública és l’elecció habitual perquè és l’única que l’administrador ja coneix. També és l’única adreça garantida fora del propi prefix del túnel, i justament aquesta propietat trenca els clients d’Apple.

Mireu el valor abans de canviar res. Si el resolutor enviat és l’adreça WAN del servidor, heu trobat la forma del problema i us podeu estalviar la resta d’endevinalles. Compareu-lo també amb el prefix del pool, perquè una adreça dins del pool però fora del rang assignat és exactament com serà la solució. Dos minuts amb la configuració valen més que una tarda de captures de paquets al client.

Retalleu el resolutor del rang d’assignació

Doneu al túnel un pla d’adreces on el resolutor sigui membre de la pròpia subxarxa del pool, i després reserveu aquesta adreça perquè mai s’assigni a cap client. En aquest exemple el pool és 10.180.7.0/24, el servidor té 10.180.7.1 i les assignacions comencen a 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

El prefix del pool i el resolutor comparteixen subxarxa, així que la ruta que ja porta trànsit del túnel també porta les consultes. Aquesta única propietat és el que fa la solució portable entre clients. En una configuració swanctl, els mateixos dos fets apareixen com a definició de pool i paràmetre DNS a la connexió en lloc de la sintaxi d’ipsec.conf.

El servidor no necessita cap interfície física nova per això. Afegir 10.180.7.1 a la interfície de loopback és prou perquè un resolutor s’hi uneixi i respongui, ja que els clients hi arriben per la ruta del pool que ja existeix. Manteniu l’adreça fora del rang d’assignació perquè cap client no la reclami per accident. Si el pool el gestiona un servei DHCP o RADIUS extern, reserveu-hi l’adreça també, o el primer client que pregunti se la quedarà.

Enllaceu el resolutor i tanqueu el port 53

Assignar una adreça no és el mateix que escoltar-hi. Un resolutor que només escolta a l’adreça LAN refusarà o ignorarà les consultes enviades a l’adreça del pool, i el client veu un temps d’espera que sembla un error d’encaminament.

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

Aquest fragment d’unbound accepta consultes del pool del túnel i refusa tota la resta, que és la política que volen la majoria de resolutors corporatius. Si la mateixa instància també respon clients de la LAN, afegiu el prefix LAN explícitament en lloc d’ampliar l’oient a totes les fonts.

Aleshores les regles de firewall han de coincidir amb el control d’accés del propi resolutor. Accepteu el port 53 des del pool i descarteu-lo a tota la resta, però comproveu primer l’ordre de la cadena.

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 regla d’acceptació anterior i més àmplia fa decoratives les dues últimes línies, i el resolutor continua sent accessible des d’internet. Llegiu el conjunt efectiu de regles amb els comptadors en lloc de confiar en l’ordre que preteníeu. La política alternativa, enviar l’adreça pública i permetre consultes de qualsevol font, funciona per a molts clients, però posa el resolutor a internet i necessita la seva pròpia limitació de ritme i monitoratge.

Verifiqueu què ha rebut realment el client

Mireu primer la visió del servidor i després la del client, perquè les dues discrepen de manera informativa. Un llistat del pool mostra quina adreça s’ha assignat, i el llistat d’associacions de seguretat mostra si la connexió està activa amb la identitat esperada.

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

La consulta directa demostra que el resolutor respon a l’adreça del pool des d’un host que hi pot arribar. No demostra que el Mac hagi triat aquell servidor. A macOS, scutil --dns llista els resolutors per servei amb abast i és més informatiu que el panell de resum; a Windows, Get-DnsClientServerAddress mostra si l’adaptador del túnel ha acceptat el valor enviat.

Si el client mostra l’adreça del pool i les consultes encara fan temps d’espera, la culpa és de la ruta del túnel o de la cadena de firewall. Un client que no informa de cap resolutor vol dir que la càrrega de configuració no ha arribat mai, així que mireu com aquella plataforma aplica els paràmetres enviats i no la xarxa. Anoteu quin dels dos casos heu observat abans de canviar res més. Aquestes dues fallades semblen idèntiques en un tiquet de suport i porten a reparacions oposades.