StrongSwan envia um endereço DNS que o Mac não consegue alcançar

Tudo funciona até alguém abrir um MacBook. O túnel estabelece-se, os hosts internos respondem por endereço e a resolução de nomes morre. No iPhone, o mesmo perfil comporta-se da mesma forma, enquanto os clientes Windows e Linux estão bem. Normalmente o culpado é o atributo DNS enviado: o servidor distribui o seu próprio endereço público de interface, e o cliente IKEv2 da Apple não envia consultas para lá através do túnel. Mova o resolver para dentro do pool e o sintoma desaparece sem tocar no cliente.

O sintoma aponta para o endereço enviado

Quando apenas algumas plataformas falham, o túnel e as credenciais estão quase de certeza bem, porque são partilhados. O que difere é como cada cliente aplica a carga de configuração que recebe, incluindo o servidor DNS interno. Um cliente que aceita o endereço mas encaminha as consultas por fora do túnel acaba com um resolver que vê e não consegue usar.

O endereço público é a escolha habitual porque é o único que o administrador já conhece. É também o único endereço garantidamente fora do próprio prefixo do túnel, e é precisamente essa propriedade que quebra os clientes da Apple.

Veja o valor antes de mudar qualquer coisa. Se o resolver enviado for o endereço WAN do servidor, encontrou a forma do problema e pode saltar o resto das suposições. Compare-o também com o prefixo do pool, porque um endereço dentro do pool mas fora do intervalo atribuído é exatamente como será a correção. Dois minutos com a configuração valem mais do que uma tarde de capturas de pacotes no cliente.

Recorte o resolver do intervalo de atribuição

Dê ao túnel um plano de endereços em que o resolver seja membro da própria sub-rede do pool e, em seguida, reserve esse endereço para que nunca seja atribuído a nenhum cliente. Neste exemplo, o pool é 10.180.7.0/24, o servidor detém 10.180.7.1 e as atribuições começam em 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

O prefixo do pool e o resolver partilham uma sub-rede, pelo que a rota que já transporta o tráfego do túnel também transporta as consultas. É essa única propriedade que torna a correção portátil entre clientes. Numa configuração swanctl, os mesmos dois factos aparecem como definição de pool e definição de DNS na ligação, em vez da sintaxe de ipsec.conf.

O servidor não precisa de uma nova interface física para isto. Adicionar 10.180.7.1 à interface de loopback é suficiente para um resolver se ligar e responder, uma vez que os clientes o alcançam pela rota do pool que já existe. Mantenha o endereço fora do intervalo de atribuição para que nenhum cliente o reivindique por engano. Se o pool for gerido por um serviço DHCP ou RADIUS externo, reserve o endereço também aí, caso contrário o primeiro cliente que perguntar fica com ele.

Ligue o resolver e feche a porta 53

Atribuir um endereço não é o mesmo que escutar nele. Um resolver que escuta apenas no endereço LAN recusará ou ignorará consultas enviadas para o endereço do pool, e o cliente vê um tempo limite que parece uma falha de encaminhamento.

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

Esse fragmento de unbound aceita consultas do pool do túnel e recusa tudo o resto, que é a política que a maioria dos resolvers empresariais quer. Se a mesma instância também responder a clientes da LAN, acrescente o prefixo LAN explicitamente em vez de alargar o ouvinte a todas as fontes.

Depois, as regras de firewall têm de concordar com o controlo de acesso do próprio resolver. Aceite a porta 53 a partir do pool e descarte-a em todo o resto, mas verifique primeiro a ordem da cadeia.

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

Uma regra de aceitação anterior e mais ampla torna as duas últimas linhas decorativas, e o resolver continua acessível a partir da internet. Leia o conjunto efetivo de regras com os contadores em vez de confiar na ordem que pretendia. A política alternativa, enviar o endereço público e permitir consultas de qualquer origem, funciona para muitos clientes, mas coloca o resolver na internet e exige a sua própria limitação de ritmo e monitorização.

Verifique o que o cliente recebeu realmente

Verifique primeiro a vista do servidor e depois a do cliente, porque as duas discordam de forma informativa. Uma listagem do pool mostra que endereço foi atribuído, e a listagem de associações de segurança mostra se a ligação está ativa com a identidade esperada.

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

A consulta direta prova que o resolver responde no endereço do pool a partir de um host que o consegue alcançar. Não prova que o Mac escolheu esse servidor. No macOS, scutil --dns lista os resolvers por serviço com âmbito e é mais informativo do que o painel de resumo; no Windows, Get-DnsClientServerAddress mostra se o adaptador do túnel aceitou o valor enviado.

Se o cliente mostra o endereço do pool e as consultas continuam a expirar, a culpa é da rota do túnel ou da cadeia de firewall. Um cliente que não reporta nenhum resolver significa que a carga de configuração nunca chegou, por isso olhe para a forma como essa plataforma aplica as definições enviadas e não para a rede. Anote qual dos dois casos observou antes de mudar mais alguma coisa. Essas duas falhas parecem idênticas num ticket de suporte e levam a reparações opostas.