ESP es el protocolo IP 50, no el puerto TCP 50: qué hay que permitir
Los números de protocolo y los números de puerto son espacios de nombres distintos. Una regla para el puerto TCP 50 no permite nada, y el NAT traversal mueve ESP a UDP 4500.
Los formularios de cortafuegos piden un puerto TCP, y la entrada obvia es 50. Esa entrada no permite nada, porque ESP es el número de protocolo IP 50 y los números de protocolo no son puertos. Los dos espacios de nombres comparten enteros pequeños y nada más, y el error es invisible hasta que IKE termina y el tráfico protegido nunca llega.
Dos espacios de nombres que comparten números pequeños
Una cabecera IP lleva un campo de protocolo que nombra lo que viene después: 6 para TCP, 17 para UDP, 1 para ICMP, 50 para ESP, 51 para AH. Una cabecera TCP o UDP lleva números de puerto, que seleccionan un proceso en el host de destino. El protocolo 50 y el puerto TCP 50 son valores sin relación que un cuadro de diálogo puede hacer parecer intercambiables.
Por eso una regla de redirección de puertos no puede expresar ESP nativo. No hay un puerto de destino ESP que redirigir, y un dispositivo que solo entiende reglas de puertos no tiene ningún vocabulario para ese paquete. La regla correcta nombra el protocolo IP. Cualquier diálogo de puertos es el instrumento equivocado para ese paquete.
La confusión tiene una segunda mitad. Cuando el paquete está cifrado, todo lo que hay dentro es opaco, incluida la cabecera TCP de la conexión original. Un cortafuegos que inspecciona puertos en ese paquete está mirando la cabecera exterior, que en el caso nativo no tiene puertos que inspeccionar.
ESP nativo, luego la alternativa encapsulada
El ESP nativo se transporta directamente como protocolo IP, lo que es eficiente e incómodo a partes iguales. Es eficiente porque no hay cabecera adicional, e incómodo porque cualquier dispositivo que traduzca direcciones y puertos no puede seguirlo. El NAT traversal existe para resolverlo, envolviendo el paquete ESP dentro de UDP para que el traductor tenga puertos que reescribir.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
Las dos formas son despliegues alternativos del mismo canal de datos, no capas de uno. Permitir ESP nativo no permite la forma encapsulada, y permitir UDP 4500 no permite el tráfico nativo, así que un conjunto de reglas debe coincidir con el despliegue en lugar de cubrir ambos por accidente.
La detección también importa aquí. Los extremos deciden entre las formas durante la negociación, y el cambio suele ocurrir cuando se detecta un NAT entre ellos. Por eso una ruta que cambia después de establecer el túnel puede mover el tráfico a un espacio de nombres que sus reglas nunca cubrieron.
Lea qué forma usa realmente la conexión
Pregunte al extremo en lugar de adivinar por el cortafuegos. En Linux la entrada de estado informa si la asociación usa encapsulación UDP y qué puertos intervienen. Una captura responde la misma pregunta desde el cable, y ambas son más rápidas que leer un conjunto de reglas y confiar.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'El primer comando muestra un tipo de encapsulación cuando se usa NAT traversal y nada cuando no. El segundo muestra cuál de las dos formas cruza realmente la interfaz, lo que zanja discusiones sobre una configuración que sobre el papel parece correcta.
La contraevidencia pertenece al mismo paso. Una regla que informa de cero coincidencias le dice que el paquete nunca llegó a ella, y eso es una cuestión de enrutamiento o de selector, no de cortafuegos.
Luego confirme el canal de control por separado. IKE tiene sus propios puertos y sus propios registros, y una negociación completada sin datos es exactamente la separación de la que trata este artículo.
Escriba la regla en el espacio de nombres correcto
Una regla de protocolo y una regla de puerto son instrucciones distintas, así que la herramienta debe expresar la que usted quiere. En nftables la coincidencia de protocolo es explícita, y la alternativa encapsulada recibe su propia regla UDP. Mantenga las dos reglas juntas para que el par sea visible en la revisión.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptNo amplíe ninguna de las reglas para compensar un diagnóstico equivocado. Un permitir todo para el protocolo ESP en cada interfaz, o un permiso UDP de cualquiera a cualquiera, arregla un síntoma y elimina el control que intentaba configurar. El flujo estrecho admitido casi siempre basta una vez conocida la forma.
Por último, mantenga las capas claras cuando el túnel funciona y la aplicación no. Los paquetes que llegan a la puerta de enlace siguen necesitando reenvío, una ruta de vuelta y una política que los admita, y nada de eso lo expresa una regla ESP. El puerto que falta explica un fallo concreto, no todos los fallos de IPsec. Mantenga la corrección de la regla y la comprobación de enrutamiento como dos conclusiones separadas.
Anote la forma que observó, la regla de protocolo que añadió y el contador que vio después. Tres líneas, y la siguiente persona podrá distinguir un error de espacio de nombres de uno de enrutamiento en un minuto en lugar de una tarde.