strongSwan ESP-in-UDP: cando non hai ningún NAT que detectar

A detección de NAT descobre a tradución de enderezos, non a política do cortalumes. Unha conexión de sitio sen NAT pode seguir precisando unha elección explícita de ESP-in-UDP.

A detección de NAT responde a unha pregunta: cambiaron os enderezos ou os portos en tránsito? Non responde se un cortalumes permite o protocolo IP 50. As pasarelas de sitio sen ningunha tradución poden seguir detrás dunha política que descarta o ESP nativo, e ese requisito debe configurarse en lugar de descubrirse. O mecanismo é ESP-in-UDP, e é unha decisión, non un recurso alternativo que apareza só.

A detección é aritmética sobre enderezos, non unha sonda do cortalumes

IKEv2 transporta cargas útiles de detección de NAT con hashes dos enderezos e dos portos de orixe e destino. Cada lado compara o que recibiu co que ve localmente, e unha discrepanza dille que algo traduciu o paquete. Nada nese intercambio comproba se un encamiñador intermedio reenvía o protocolo 50.

Paga a pena dicir a consecuencia práctica sen rodeos. Un túnel que funcionaba con ESP nativo non descubrirá por si só un cortalumes novo máis restritivo, e o seu seguinte intento falla na etapa de datos mentres IKE segue tendo éxito. Verá asociacións de seguridade IKE establecidas e ningún tráfico protexido, o que parece un fallo de encamiñamento ata que capture no cable.

A encapsulación é, polo tanto, unha propiedade da conexión que configura, non un resultado que os pares negociasen a partir do comportamento da rede.

Como cambia encap o intercambio

Nun despregamento moderno de strongSwan xestionado mediante swanctl.conf, a opción encap = yes na conexión inflúe no intercambio de detección de NAT para que ambos os pares usen encapsulación UDP para ESP. Os paquetes protexidos viaxan entón dentro de UDP, convencionalmente no porto 4500, e ambos os extremos deben poñerse de acordo sobre esa disposición.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Ese fragmento pertence dentro dunha definición de conexión real e non é un perfil de sitio completo. Manteña os enderezos dos pares, a autenticación e os selectores de tráfico child que xa executa; a única clave engadida cambia como se envolven os datos protexidos, non que protexe.

A guía de strongSwan sobre NAT-traversal describe este comportamento, incluída a interacción co porto flotante cando se usa MOBIKE.

Use a opción que corresponde ao seu backend

strongSwan ten dous backends de configuración, e a clave difire entre eles. Unha swanctl.conf conexión toma encap, mentres que unha ipsec.conf conexión herdada toma forceencaps. Meter a palabra clave dun backend no outro produce unha configuración que se carga sen queixa e non cambia nada, o cal é peor que un erro.

Comprobe que demonio se executa realmente antes de editar nada. En moitas distribucións existen ambos os ficheiros porque un é un resto dunha migración anterior, e o activo é o que arranca a unidade de servizo. Lea esa unidade en lugar de adiviñar polas marcas de tempo dos ficheiros. Unha comprobación de cinco segundos aquí evita horas probando unha opción que nada cargou.

Aplique o cambio a través do propietario da conexión e restableza a asociación durante unha ventá controlada. Un child xa instalado conserva a súa encapsulación actual ata que se substitúe, así que editar o ficheiro por si só non demostra que a nova disposición estea en uso.

Verifique os datos envoltos, non só o porto

Capture na pasarela mentres flúe tráfico protexido e logo compare iso coa propia visión de strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

O ESP nativo aparece como protocolo IP 50 e non se parece en nada a UDP. O ESP envolto aparece como datagramas UDP en 4500 cuxa carga útil non é IKE. O tráfico IKE nese mesmo porto non é proba de encapsulación, porque MOBIKE pode mover IKE alí mentres a ruta de datos segue sendo nativa, así que lea a carga útil, non o número de porto.

Teña en conta tamén a MTU da ruta. A envoltura engade sobrecarga, e unha ruta que transportaba ESP nativo pode necesitar axustes cando medren os paquetes. O manexo de ICMP necesario xa debería formar parte do deseño; a encapsulación non elimina esa dependencia.

Acepte o cambio cando o tráfico novo de aplicacións dentro do túnel sexa visible na captura como ESP envolto nos dous extremos, e cando o servizo interno e a súa ruta de retorno sigan funcionando. Calquera cousa menos é unha configuración que parece correcta nun ficheiro.

Artigos relacionados