ESP é o protocolo IP 50, non o porto TCP 50: que cómpre permitir
Os números de protocolo e os números de porto son espazos de nomes distintos. Unha regra para o porto TCP 50 non permite nada, e o NAT traversal move ESP a UDP 4500.
Os formularios da devasa piden un porto TCP, e a entrada obvia é 50. Esa entrada non permite nada, porque ESP é o número de protocolo IP 50 e os números de protocolo non son portos. Os dous espazos de nomes comparten enteiros pequenos e nada máis, e o erro é invisible ata que IKE remata e o tráfico protexido nunca chega.
Dous espazos de nomes que comparten números pequenos
Unha cabeceira IP leva un campo de protocolo que nomea o que vén despois: 6 para TCP, 17 para UDP, 1 para ICMP, 50 para ESP, 51 para AH. Unha cabeceira TCP ou UDP leva números de porto, que seleccionan un proceso no host de destino. O protocolo 50 e o porto TCP 50 son valores sen relación que un cadro de diálogo pode facer parecer intercambiables.
Por iso unha regra de redirección de portos non pode expresar ESP nativo. Non hai un porto de destino ESP que redirixir, e un dispositivo que só entende regras de portos non ten ningún vocabulario para ese paquete. A regra correcta nomea o protocolo IP. Calquera diálogo de portos é o instrumento equivocado para ese paquete.
A confusión ten unha segunda metade. Cando o paquete está cifrado, todo o que hai dentro é opaco, incluída a cabeceira TCP da conexión orixinal. Unha devasa que inspecciona portos nese paquete está mirando a cabeceira exterior, que no caso nativo non ten portos que inspeccionar.
ESP nativo, despois a alternativa encapsulada
O ESP nativo transpórtase directamente como protocolo IP, o que é eficiente e incómodo a partes iguais. É eficiente porque non hai cabeceira adicional, e incómodo porque calquera dispositivo que traduza enderezos e portos non pode seguilo. O NAT traversal existe para resolvelo, envolvendo o paquete ESP dentro de UDP para que o tradutor teña portos 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 |
As dúas formas son despregamentos alternativos da mesma canle de datos, non capas dunha. Permitir ESP nativo non permite a forma encapsulada, e permitir UDP 4500 non permite o tráfico nativo, así que un conxunto de regras debe coincidir co despregamento en lugar de cubrir ambos por accidente.
A detección tamén importa aquí. Os extremos deciden entre as formas durante a negociación, e o cambio adoita ocorrer cando se detecta un NAT entre eles. Por iso un camiño que cambia despois de establecer o túnel pode mover o tráfico a un espazo de nomes que as súas regras nunca cubriron.
Lea que forma usa realmente a conexión
Pregunte ao extremo en lugar de adiviñar pola devasa. En Linux a entrada de estado informa se a asociación usa encapsulación UDP e que portos interveñen. Unha captura responde a mesma pregunta desde o cable, e ambas son máis rápidas que ler un conxunto de regras e confiar.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'O primeiro comando mostra un tipo de encapsulación cando se usa NAT traversal e nada cando non. O segundo mostra cal das dúas formas cruza realmente a interface, o que zanxa discusións sobre unha configuración que sobre o papel parece correcta.
A contraevidencia pertence ao mesmo paso. Unha regra que informa de cero coincidencias dille que o paquete nunca chegou a ela, e iso é unha cuestión de encamiñamento ou de selector, non de devasa.
Despois confirme a canle de control por separado. IKE ten os seus propios portos e os seus propios rexistros, e unha negociación completada sen datos é exactamente a separación da que trata este artigo.
Escriba a regra no espazo de nomes correcto
Unha regra de protocolo e unha regra de porto son instrucións distintas, así que a ferramenta debe expresar a que vostede quere. En nftables a coincidencia de protocolo é explícita, e a alternativa encapsulada recibe a súa propia regra UDP. Manteña as dúas regras xuntas para que o par sexa visible na revisión.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptNon amplíe ningunha das regras para compensar un diagnóstico equivocado. Un permitir todo para o protocolo ESP en cada interface, ou un permiso UDP de calquera a calquera, arranxa un síntoma e elimina o control que intentaba configurar. O fluxo estreito admitido case sempre abonda unha vez coñecida a forma.
Por último, manteña as capas claras cando o túnel funciona e a aplicación non. Os paquetes que chegan á pasarela aínda necesitan reenvío, unha ruta de volta e unha política que os admita, e nada diso o expresa unha regra ESP. O porto que falta explica un fallo concreto, non todos os fallos de IPsec. Manteña a corrección da regra e a comprobación de encamiñamento como dúas conclusións separadas.
Anote a forma que observou, a regra de protocolo que engadiu e o contador que viu despois. Tres liñas, e a seguinte persoa poderá distinguir un erro de espazo de nomes dun de encamiñamento nun minuto en lugar dunha tarde.