StrongSwan envía un enderezo DNS que o Mac non pode alcanzar

Todo funciona ata que alguén abre un MacBook. O túnel establécese, os hosts internos responden por enderezo e a resolución de nomes morre. No iPhone o mesmo perfil compórtase igual, mentres que os clientes de Windows e Linux están ben. Normalmente o culpable é o atributo DNS enviado: o servidor reparte o seu propio enderezo público de interface, e o cliente IKEv2 de Apple non envía consultas alí a través do túnel. Mova o resolvedor dentro do pool e o síntoma desaparece sen tocar o cliente.

O síntoma apunta ao enderezo enviado

Cando só fallan algunhas plataformas, o túnel e as credenciais están case seguro ben, porque son compartidos. O que cambia é como cada cliente aplica a carga de configuración que recibe, incluído o servidor DNS interno. Un cliente que acepta o enderezo pero dirixe as consultas fóra do túnel acaba cun resolvedor que ve e non pode usar.

O enderezo público é a elección habitual porque é o único que o administrador xa coñece. Tamén é o único enderezo garantido fóra do propio prefixo do túnel, e xusto esa propiedade rompe os clientes de Apple.

Mire o valor antes de cambiar nada. Se o resolvedor enviado é o enderezo WAN do servidor, atopou a forma do problema e pode saltarse o resto das conxecturas. Compáreo tamén co prefixo do pool, porque un enderezo dentro do pool pero fóra do rango asignado é exactamente como será a solución. Dous minutos coa configuración valen máis que unha tarde de capturas de paquetes no cliente.

Corte o resolvedor do rango de asignación

Dea ao túnel un plan de enderezos no que o resolvedor sexa membro da propia subrede do pool e despois reserve ese enderezo para que nunca se asigne a ningún cliente. Neste exemplo o pool é 10.180.7.0/24, o servidor ten 10.180.7.1 e as asignacións comezan en 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

O prefixo do pool e o resolvedor comparten subrede, así que a ruta que xa transporta o tráfico do túnel tamén transporta as consultas. Esa única propiedade é o que fai a solución portátil entre clientes. Nunha configuración swanctl os mesmos dous feitos aparecen como definición de pool e axuste de DNS na conexión en lugar da sintaxe de ipsec.conf.

O servidor non necesita unha interface física nova para isto. Engadir 10.180.7.1 á interface de loopback abonda para que un resolvedor se ligue e responda, xa que os clientes chegan a el pola ruta do pool que xa existe. Manteña o enderezo fóra do rango de asignación para que ningún cliente o reclame por accidente. Se o pool o xestiona un servizo DHCP ou RADIUS externo, reserve o enderezo tamén alí, ou o primeiro cliente que pregunte levaráo.

Ligue o resolvedor e peche o porto 53

Asignar un enderezo non é o mesmo que escoitar nel. Un resolvedor que só escoita no enderezo LAN rexeitará ou ignorará as consultas enviadas ao enderezo do pool, e o cliente ve un tempo de espera que parece un fallo de encamiñamento.

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 do pool do túnel e rexeita todo o demais, que é a política que queren a maioría dos resolvedores corporativos. Se a mesma instancia tamén responde a clientes da LAN, engada o prefixo LAN explicitamente en lugar de ampliar o escoitador a todas as fontes.

Despois as regras de firewall teñen que coincidir co control de acceso do propio resolvedor. Acepte o porto 53 desde o pool e descárteo en todos os demais sitios, pero revise antes a orde da cadea.

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

Unha regra de aceptación anterior e máis ampla fai decorativas as dúas últimas liñas, e o resolvedor segue sendo accesible desde internet. Lea o conxunto efectivo de regras cos contadores en lugar de confiar na orde que pretendía. A política alternativa, enviar o enderezo público e permitir consultas desde calquera fonte, funciona para moitos clientes, pero pon o resolvedor en internet e necesita a súa propia limitación de velocidade e monitorización.

Verifique que recibiu realmente o cliente

Comprobe primeiro a visión do servidor e despois a do cliente, porque ambas discrepan de forma informativa. Unha listaxe do pool mostra que enderezo se asignou, e a listaxe de asociacións de seguridade mostra se a conexión está activa coa identidade esperada.

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

A consulta directa demostra que o resolvedor responde no enderezo do pool desde un host que pode alcanzalo. Non demostra que o Mac escollese ese servidor. En macOS, scutil --dns lista os resolvedores por servizo con ámbito e é máis informativo que o panel de resumo; en Windows, Get-DnsClientServerAddress mostra se o adaptador do túnel aceptou o valor enviado.

Se o cliente mostra o enderezo do pool e as consultas seguen esgotando o tempo, a culpa é da ruta do túnel ou da cadea de firewall. Un cliente que non informa de ningún resolvedor significa que a carga de configuración nunca chegou, así que mire como aplica esa plataforma os axustes enviados en lugar da rede. Anote cal dos dous casos observou antes de cambiar calquera outra cousa. Eses dous fallos parecen idénticos nun ticket de soporte e levan a reparacións opostas.