Cando IKEv2 devolve TS_UNACCEPTABLE, compare as subredes reais

Lea TS_UNACCEPTABLE como un desacordo de cobertura, non como un perfil corrupto. A pasarela di que os dous pares non puideron poñerse de acordo sobre que enderezos pode transportar este túnel. A IKE SA xa pode estar activa nese momento, e por iso un cliente pode parecer conectado sen ningunha SA filla detrás. Unha vez que o expón así, o traballo vólvese mecánico. Anote os prefixos previstos de ambos os lados, compáreos nunha soa dirección e estreite ata que se crucen.

Primeiro anote os pares previstos

Antes de tocar a configuración, enumere catro valores: o rango de orixe do iniciador, o seu rango de destino e o mesmo par visto desde o respondente. Anote tamén a familia de enderezos de cada un. Un rango IPv4 e un rango IPv6 son tipos de selector distintos, e ningún se pode pregar na carga útil do outro.

Engada calquera restrición de protocolo ou porto que leve a política. Unha regra que só permite TCP 445 cara a un servidor de ficheiros describe un conxunto máis estreito que a subrede na que se atopa. Se o deixa fóra das súas notas, o resultado da negociación parecerá incoherente por razóns que non ve.

Inverta as etiquetas antes de comparalas

Local e remoto son etiquetas relativas. O prefixo local do cliente é o rango remoto da pasarela, e o rango local da pasarela é o remoto do cliente. Por iso as capturas de pantalla dos dous extremos nunca coinciden, e comparalas literalmente é a forma habitual de perder unha tarde.

Un respondente pode estreitar unha oferta ata un subconxunto aceptable en lugar de rexeitala. Ese resultado é peor que un fallo limpo, porque funciona a medias. Pida 10.0.0.0/16 cando a política permite 10.0.5.0/24 e pode acabar cunha SA filla que só cobre ese /24. Un host responde, todo o demais queda fóra, e nada no cliente o di. Lea os selectores aceptados e non os solicitados antes de concluír que a negociación tivo éxito.

Os perfís road warrior que piden unha ruta predeterminada caen aquí constantemente. Unha pasarela construída para acceso dividido estreita unha oferta de rango completo ás súas propias subredes, e o cliente debe aceptar o resultado estreitado ou fallar ruidosamente.

Lea o rexeitamento a partir dun só intento

Recolla ambos os rexistros do mesmo intento de conexión. Un perfil gardado mostra o que vostede configurou, non o que se propuxo, e en strongSwan swanctl --log imprime a notificación recibida xunto cos selectores que levaba.

Despois inspeccione que se instalou realmente. swanctl --list-sas mostra os selectores da SA filla, e ip xfrm policy mostra os mesmos rangos como entradas de política do núcleo. Unha SA filla nesa lista con selectores que non pretendía é un evento de estreitamento; ningunha SA filla máis TS_UNACCEPTABLE no rexistro é un rexeitamento.

Mentres está aí, separe os veciños próximos. INVALID_SELECTORS quéixase dun selector dentro dunha SA filla establecida, mentres que INTERNAL_ADDRESS_FAILURE significa que o respondente non puido asignar un enderezo virtual, o cal é un problema de pozo e non de cobertura.

Comprobe que encolle o conxunto en silencio

Tres cousas encollen un conxunto de selectores sen dicir nada. A política do respondente é a primeira, mediante listas de subredes, regras de grupo ou autorización por usuario que reducen a oferta a un subconxunto. A familia de enderezos é a segunda: un cliente de dobre pila adoita propor IPv6 xunto a IPv4 e recibe un rexeitamento por rangos que a pasarela nunca configurou.

As restricións de protocolo e porto son a terceira. Onde a política só permite TCP 445, unha SA filla pode levantarse mentres ICMP e UDP quedan fóra, e o usuario informa dun túnel roto cando un só protocolo era todo o que se permitira.

Por tanto, ampliar só os enderezos non pode arranxar unha política restrinxida por porto, que é o caso con máis probabilidades de sobrevivir intacto a tres roldas de diagnóstico.

Demostre a cobertura con tráfico que encaixe

Unha vez instalada a SA filla, envíe unha petición que caia con seguridade dentro dos rangos aceptados. Mire os contadores en lugar da icona de estado: ip -s xfrm state e os contadores detrás de ip xfrm policy aumentan cando un paquete coincide e se protexe. Un reconto de bytes que queda en cero tras tráfico real significa que o núcleo nunca seleccionou esa política.

Ese cero é un problema de encamiñamento ou de orde de políticas, non de criptografía. Tamén parece idéntico a un rexeitamento de selector desde o asento do usuario, por iso paga a pena recoller os contadores antes de reabrir o perfil. Os contadores que só soben nunha dirección apuntan máis ben ao camiño de volta.

Remate escribindo o par aceptado no ticket, xunto ao rango que se solicitou orixinalmente. Manteña a selección tan estreita como o requisito, porque borrar o erro substituíndo un rango privado por todos os enderezos concede moito máis acceso do que se aprobou para a conta.