IPsec dentro de IPsec: que enderezos debe transportar o túnel exterior

O IPsec aniñado é máis doado de razoar cando as dúas capas rematan en máquinas distintas. Catro pasarelas, dous túneles e unha soa pregunta que decide se o deseño funciona: que ve realmente o túnel exterior cando o interior rematou co paquete? Responde a iso e os selectores, as rutas e a orde de resolución de problemas seguen. Equivócate e pasarás un día depurando un túnel que tecnicamente está activo.

O modelo de catro pasarelas

As pasarelas exteriores A e B constrúen o primeiro túnel entre os dous sitios. Detrás de A está a pasarela interna C con enderezo de tránsito 10.60.0.2; detrás de B está a pasarela interna D con enderezo de tránsito 10.70.0.2. As redes de aplicacións viven detrás de C e D, e cada enderezo do exemplo é deliberadamente non solapado.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Dividir as capas entre catro hosts significa que cada máquina impón unha fronteira. Un só host que executa ambas as capas debe conciliar dous conxuntos de políticas, dúas táboas de rutas e dous modos de fallo nunha máquina, o cal é posible e moito máis difícil de observar.

Cada capa elimina só a súa propia protección

C cifra un paquete de aplicación para D. O resultado diríxese de C a D, e iso é o que chega a A. Todo o que está augas abaixo depende desa reescritura.

A volve cifralo para B. B descifra a capa exterior, ve un paquete de C a D e reenvíao aínda cifrado. D elimina a protección interior e entrega o paquete de aplicación.

Así que A e B ven os extremos internos e os seus metadatos, pero non son as partes que descifran a carga útil da aplicación. Iso é unha propiedade real do deseño e non unha afirmación de que C, D ou os hosts de aplicacións sexan de confianza.

Os selectores exteriores nomean as pasarelas internas

Aquí é onde fallan a maioría destas construcións. Para un túnel exterior baseado en políticas, os selectores que negocies deben conter os enderezos que A e B manexan realmente: 10.60.0.2/32 e 10.70.0.2/32, na orde local e remota correcta.

Pór as subredes finais das aplicacións nos selectores exteriores non funciona, porque cando un paquete chega a A, a encapsulación interior xa reescribiu o que A debe protexer. A política exterior entón non coincidiría con nada, e o túnel subiría sen transportar datos.

Tampouco restrinxas o permiso exterior a UDP 500. A conexión interior ten a súa propia ruta de datos, que usa ESP ou encapsulación UDP segundo o que negociase, e a política exterior debe permitir ese protocolo.

Comproba o resultado con swanctl --list-sas en cada pasarela e confirma que as asociacións de seguridade fillas informan os enderezos que pretendías, non os que supuxeras. Se a lista mostra as subredes de aplicacións, a política exterior escribiuse para a capa incorrecta. Corrixe os selectores antes de depurar o encamiñamento, porque o encamiñamento parecerá correcto e os contadores non se moverán.

O reenvío e a trampa da recursión

Os selectores non substitúen o encamiñamento. A e B deben reenviar tráfico entre C e D en ambos os sentidos, o que significa reenvío IP habilitado, rutas que apunten ao túnel e unha ruta de retorno que exista no outro lado.

Se o túnel exterior usa interfaces XFRM, as rutas seleccionan a interface mentres as políticas negociadas aínda limitan o que transporta. Unha interface non amplía o protexido; só cambia como o núcleo recolle o paquete.

A trampa é a recursión. A ruta de A cara ao extremo exterior de B debe seguir a rede subxacente, non o túnel que A está establecendo, ou a encapsulación tenta viaxar dentro de si mesma e a conexión nunca se completa.

Inspecciona a tradución antes de engadir capas

Mira calquera NAT de orixe en A e B antes de axustar calquera outra cousa. Unha regra que reescriba o enderezo de C antes de que se aplique a política IPsec pode romper os selectores acordados, e tamén pode cambiar o que D recibe no outro lado.

O masquerading amplo non se volve máis seguro por ter dúas capas. Oculta que enderezo ve o extremo remoto, que é exactamente a información que necesitas cando o túnel está activo e a aplicación non.

Se unha regra NAT é realmente necesaria, anota con que enderezo cre cada lado que fala. Esa única liña resolve a maioría das discusións sobre se a culpa é do túnel ou da tradución. Tamén lle di ao seguinte enxeñeiro onde mirar cando a regra se elimine un ano despois. Un ping non fará nada diso.

Demostra fail-closed e comproba a MTU

Que unha ruta desapareza non é por si só unha política fail-closed. Outra táboa, unha ruta por defecto ou unha regra de política poden proporcionar silenciosamente unha alternativa, e a única forma de sabelo é baixar o túnel exterior e observar que fai o tráfico de aplicacións. Faino a propósito, nunha xanela, en lugar de descubrilo por accidente.

Proba tres estados: túnel exterior abaixo, túnel interior abaixo e recuperación despois de que ambos volvan. Usa contadores de políticas en cada pasarela, porque dúas sesións IKE establecidas só demostran que a negociación do plano de control tivo éxito.

Orzamenta as dúas encapsulacións. Un IKE que funciona é un resultado de paquetes pequenos, e os paquetes de aplicación de tamaño completo aínda poden fallar cando se engaden dúas cabeceiras; proba cun tamaño de carga útil coñecido na ruta real en lugar de supoñer que os números cadran. A aritmética é doada; a ruta non.