Quando o IKEv2 devolve TS_UNACCEPTABLE, compare as sub-redes reais

Leia TS_UNACCEPTABLE como uma discordância de cobertura, não como um perfil corrompido. O gateway está dizendo que os dois pares não conseguiram concordar sobre quais endereços este túnel pode transportar. A IKE SA já pode estar ativa nesse momento, e é por isso que um cliente pode parecer conectado sem nenhuma SA filha atrás. Depois de enquadrar assim, o trabalho fica mecânico. Anote os prefixos pretendidos dos dois lados, compare-os numa única direção e estreite até se cruzarem.

Anote primeiro os pares pretendidos

Antes de tocar na configuração, liste quatro valores: o intervalo de origem do iniciador, o seu intervalo de destino e o mesmo par visto pelo respondedor. Registe também a família de endereços de cada um. Um intervalo IPv4 e um intervalo IPv6 são tipos de seletor diferentes, e nenhum pode ser dobrado na carga útil do outro.

Acrescente qualquer restrição de protocolo ou porta que a política traga. Uma regra que só permite TCP 445 para um servidor de ficheiros descreve um conjunto mais estreito do que a sub-rede onde se encontra. Se deixar isso de fora das suas notas, o resultado da negociação parecerá incoerente por razões que não vê.

Inverta os rótulos antes de os comparar

Local e remoto são rótulos relativos. O prefixo local do cliente é o intervalo remoto do gateway, e o intervalo local do gateway é o remoto do cliente. Por isso as capturas de ecrã dos dois extremos nunca coincidem, e compará-las literalmente é a forma habitual de perder uma tarde.

Um respondedor pode estreitar uma oferta até um subconjunto aceitável em vez de a rejeitar. Esse resultado é pior do que uma falha limpa, porque funciona a meio. Peça 10.0.0.0/16 quando a política permite 10.0.5.0/24 e pode acabar com uma SA filha que cobre apenas esse /24. Um anfitrião responde, todo o resto fica de fora, e nada no cliente o diz. Leia os seletores aceites e não os pedidos antes de concluir que a negociação teve êxito.

Os perfis road warrior que pedem uma rota predefinida aterram aqui constantemente. Um gateway construído para acesso dividido estreita uma oferta de intervalo completo para as suas próprias sub-redes, e o cliente tem de aceitar o resultado estreitado ou falhar ruidosamente.

Leia a rejeição a partir de uma única tentativa

Recolha os dois registos da mesma tentativa de ligação. Um perfil guardado mostra o que configurou, não o que foi proposto, e no strongSwan swanctl --log imprime a notificação recebida juntamente com os seletores que transportava.

Depois inspecione o que foi realmente instalado. swanctl --list-sas mostra os seletores da SA filha, e ip xfrm policy mostra os mesmos intervalos como entradas de política do núcleo. Uma SA filha nessa lista com seletores que não pretendia é um evento de estreitamento; nenhuma SA filha mais TS_UNACCEPTABLE no registo é uma recusa.

Enquanto estiver aí, separe os vizinhos próximos. O INVALID_SELECTORS queixa-se de um seletor dentro de uma SA filha estabelecida, enquanto o INTERNAL_ADDRESS_FAILURE significa que o respondedor não conseguiu atribuir um endereço virtual, o que é um problema de conjunto e não de cobertura.

Verifique o que encolhe o conjunto em silêncio

Três coisas encolhem um conjunto de seletores sem dizer nada. A política do respondedor é a primeira, através de listas de sub-redes, regras de grupo ou autorização por utilizador que reduzem a oferta a um subconjunto. A família de endereços é a segunda: um cliente de dupla pilha propõe frequentemente IPv6 ao lado de IPv4 e recebe uma rejeição para intervalos que o gateway nunca configurou.

As restrições de protocolo e porta são a terceira. Onde a política só permite TCP 445, uma SA filha pode subir enquanto ICMP e UDP ficam de fora, e o utilizador relata um túnel quebrado quando um único protocolo era tudo o que alguma vez foi permitido.

Por isso, alargar apenas os endereços não pode corrigir uma política restringida por porta, e é precisamente esse o caso com mais probabilidade de sobreviver intacto a três rondas de diagnóstico.

Prove a cobertura com tráfego que se ajuste

Depois de a SA filha estar instalada, envie um pedido que caia com certeza dentro dos intervalos aceites. Olhe para os contadores em vez do ícone de estado: ip -s xfrm state e os contadores por trás de ip xfrm policy aumentam quando um pacote é emparelhado e protegido. Uma contagem de bytes que fica em zero após tráfego real significa que o núcleo nunca selecionou essa política.

Esse zero é um problema de encaminhamento ou de ordem de políticas, não de criptografia. Também parece idêntico a uma rejeição de seletor do ponto de vista do utilizador, e é por isso que vale a pena recolher os contadores antes de reabrir o perfil. Contadores que sobem apenas numa direção apontam, em vez disso, para o caminho de regresso.

Termine escrevendo o par aceite no ticket, ao lado do intervalo que foi pedido originalmente. Mantenha a seleção tão estreita como o requisito, porque apagar o erro substituindo um intervalo privado por todos os endereços concede muito mais acesso do que foi aprovado para a conta.