StrongSwan envía una dirección DNS que el Mac no puede alcanzar

Todo funciona hasta que alguien abre un MacBook. El túnel se establece, los hosts internos responden por dirección y la resolución de nombres muere. En el iPhone el mismo perfil se comporta igual, mientras que los clientes de Windows y Linux están bien. Normalmente el culpable es el atributo DNS enviado: el servidor reparte su propia dirección pública de interfaz y el cliente IKEv2 de Apple no envía consultas allí a través del túnel. Mueva el resolver dentro del pool y el síntoma desaparece sin tocar el cliente.

El síntoma apunta a la dirección enviada

Cuando solo fallan algunas plataformas, el túnel y las credenciales casi seguro que están bien, porque son compartidos. Lo que cambia es cómo cada cliente aplica la carga de configuración que recibe, incluido el servidor DNS interno. Un cliente que acepta la dirección pero dirige las consultas por fuera del túnel acaba con un resolver que ve y no puede usar.

La dirección pública es la elección habitual porque es la única que el administrador ya conoce. También es la única dirección garantizada fuera del propio prefijo del túnel, y justo esa propiedad rompe los clientes de Apple.

Mire el valor antes de cambiar nada. Si el resolver enviado es la dirección WAN del servidor, ha encontrado la forma del problema y puede saltarse el resto de las conjeturas. Compárelo también con el prefijo del pool, porque una dirección dentro del pool pero fuera del rango asignado es exactamente como será la solución. Dos minutos con la configuración valen más que una tarde de capturas de paquetes en el cliente.

Recorte el resolver del rango de asignación

Dé al túnel un plan de direcciones en el que el resolver sea miembro de la propia subred del pool y luego reserve esa dirección para que nunca se asigne a ningún cliente. En este ejemplo el pool es 10.180.7.0/24, el servidor tiene 10.180.7.1 y las asignaciones empiezan en 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

El prefijo del pool y el resolver comparten subred, así que la ruta que ya transporta el tráfico del túnel también transporta las consultas. Esa única propiedad es lo que hace la solución portátil entre clientes. En una configuración swanctl los mismos dos hechos aparecen como definición de pool y ajuste de DNS en la conexión en lugar de la sintaxis de ipsec.conf.

El servidor no necesita una interfaz física nueva para esto. Añadir 10.180.7.1 a la interfaz de loopback basta para que un resolver se enlace y responda, ya que los clientes llegan a él por la ruta del pool que ya existe. Mantenga la dirección fuera del rango de asignación para que ningún cliente la reclame por accidente. Si el pool lo gestiona un servicio DHCP o RADIUS externo, reserve la dirección también allí, o el primer cliente que pregunte se la llevará.

Enlace el resolver y cierre el puerto 53

Asignar una dirección no es lo mismo que escuchar en ella. Un resolver que solo escucha en la dirección LAN rechazará o ignorará las consultas enviadas a la dirección del pool, y el cliente ve un tiempo de espera que parece un fallo de enrutamiento.

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

Ese fragmento de unbound acepta consultas del pool del túnel y rechaza todo lo demás, que es la política que quieren la mayoría de los resolvers corporativos. Si la misma instancia también responde a clientes de la LAN, añada el prefijo LAN explícitamente en lugar de ampliar el escucha a todas las fuentes.

Luego las reglas de firewall tienen que coincidir con el control de acceso del propio resolver. Acepte el puerto 53 desde el pool y descártelo en todos los demás sitios, pero revise antes el orden 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 de aceptación anterior y más amplia hace decorativas las dos últimas líneas, y el resolver sigue siendo accesible desde internet. Lea el conjunto efectivo de reglas con los contadores en lugar de confiar en el orden que pretendía. La política alternativa, enviar la dirección pública y permitir consultas desde cualquier fuente, funciona para muchos clientes, pero pone el resolver en internet y necesita su propia limitación de velocidad y monitorización.

Verifique qué recibió realmente el cliente

Compruebe primero la vista del servidor y luego la del cliente, porque ambas discrepan de forma informativa. Un listado del pool muestra qué dirección se asignó, y el listado de asociaciones de seguridad muestra si la conexión está activa con la identidad esperada.

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

La consulta directa demuestra que el resolver responde en la dirección del pool desde un host que puede alcanzarla. No demuestra que el Mac haya elegido ese servidor. En macOS, scutil --dns lista los resolvers por servicio con ámbito y es más informativo que el panel de resumen; en Windows, Get-DnsClientServerAddress muestra si el adaptador del túnel aceptó el valor enviado.

Si el cliente muestra la dirección del pool y las consultas siguen agotando el tiempo, la culpa es de la ruta del túnel o de la cadena de firewall. Un cliente que no informa de ningún resolver significa que la carga de configuración nunca llegó, así que mire cómo aplica esa plataforma los ajustes enviados en lugar de la red. Anote cuál de los dos casos observó antes de cambiar cualquier otra cosa. Esos dos fallos parecen idénticos en un ticket de soporte y llevan a reparaciones opuestas.