¿No hay tun0? Haga coincidir el IPsec descifrado en nftables con meta ipsec

Espera una interfaz de túnel, la busca y no hay nada con lo que coincidir en el cortafuegos. Eso es normal en una puerta de enlace basada en políticas: el intercambio cifrado llega por la interfaz física, y el paquete interno descifrado que después se reenvía también se observa llegando por esa misma interfaz. No hay tun0 porque nada lo creó.

La petición interna sigue siendo un paquete distinto con su propio origen, destino y servicio, y el núcleo sabe de qué asociación de seguridad salió. Ese conocimiento es lo que una regla de cortafuegos puede hacer coincidir.

Dos paquetes, una interfaz

Imagine la dirección de entrada. Llega un paquete encapsulado en ESP o UDP, el núcleo encuentra la política correspondiente, lo descifra y entrega el paquete claro a la ruta de reenvío. Una regla que solo mira el nombre de la interfaz no puede distinguir ese paquete de cualquier otro tráfico que llegue por el mismo cable.

Lo que lo distingue es el contexto de la ruta de seguridad de entrada adjunto al paquete. nftables lo expone como meta ipsec exists, que es cierto cuando el paquete llegó por una ruta de seguridad IPsec. Combínelo con el grupo de clientes, el destino y el servicio, y la regla se vuelve lo bastante específica como para ser segura.

Omitir el contexto es el error habitual, y es un error de seguridad, no estético. Una regla que acepta cualquier cosa originada en el grupo de clientes acepta con la misma facilidad un paquete falsificado de la red local, porque la dirección de origen no es prueba de nada por sí sola. El contexto de la ruta de seguridad es la manera más barata de hacer que el origen signifique algo. Escriba la regla con él desde el principio en lugar de añadirlo tras una auditoría.

Escriba la regla de reenvío

Suponga un servicio de acceso remoto IPv4 autenticado con clientes en 10.90.0.0/24 y un destino aprobado en 203.0.113.40. Un fragmento de regla para ese flujo tiene este aspecto.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Las direcciones y la interfaz son ejemplos que hay que sustituir. Coloque el equivalente revisado en la política de reenvío antes de la regla que de otro modo rechazaría el flujo, y no vacíe un conjunto de reglas existente para instalarlo; una puerta de enlace no es un experimento de sala limpia.

Merece la pena conservar el término oifname. Documenta la decisión de salida e impide que la regla coincida en una dirección que no pretendía, lo que importa en una puerta de enlace con varias rutas a internet. En una máquina de pruebas con un solo enlace ascendente el término parece redundante, y es exactamente por eso que se elimina antes de que la máquina tenga un segundo enlace.

Los permisos para el intercambio exterior son aparte. La ruta de entrada de la puerta de enlace necesita los puertos IKE y ESP o de encapsulación UDP que realmente utiliza, y esos permisos no autorizan nada sobre el paquete descifrado de dentro. Mezclar ambos es como un túnel que funciona acaba con un cortafuegos que reenvía todo.

El contexto de entrada no es el de salida

La misma familia de expresiones cubre la otra dirección con rt ipsec, que describe la asociación de seguridad de salida que utilizará un paquete. Responde a otra pregunta: no de dónde vino este paquete, sino si estará protegido en su siguiente tramo.

Esa distinción importa en una puerta de enlace que termina un túnel y a la vez reenvía hacia otro. Un paquete puede llegar descifrado y aun así tener que salir cifrado, y una aceptación escrita solo para el contexto de entrada no dice nada sobre el requisito de salida. Si la política exige esa protección, el conjunto de reglas debería expresarla en lugar de suponer que el enrutamiento se encargará.

Mantenga las dos preguntas en reglas separadas para que el lector vea cuál se aplica. Una sola regla ingeniosa que comprueba ambas es más difícil de revisar y mucho más difícil de depurar cuando una de sus mitades deja de coincidir. Dos reglas con contadores también le dicen qué requisito está fallando, algo que una regla combinada nunca hará.

NAT no es una decisión del cortafuegos

El tráfico hacia internet desde un grupo de clientes privado suele necesitar traducción de origen para que la respuesta encuentre el camino de vuelta. Pero el tráfico seleccionado para otra política IPsec de salida debe conservar su exención requerida, y enmascarar cada origen privado sin pensar en la siguiente decisión de protección rompe eso.

Una aceptación dentro de una cadena NAT tampoco es un permiso general. NAT y filtrado tienen tareas distintas, y una cadena NAT no examina cada paquete posterior de un flujo establecido, y es justo por eso que confiar en ella para la seguridad produce reglas que parecen funcionar en las pruebas y fallan bajo carga.

Lo contrario también es cierto y sorprende a la gente: una aceptación en algún punto de una cadena base de filtrado no tiene ningún peso frente a un rechazo posterior en otra cadena aplicable. El orden y el alcance de la cadena deciden el resultado, no la presencia de una aceptación en el archivo.

Verifique el servicio interno exacto

Pruebe el destino y el puerto concretos que autorizó, desde un cliente real, y confirme que la respuesta vuelve. Luego pruebe algo que no autorizó y compruebe que no pasa, porque una regla demasiado amplia supera la primera prueba igual de bien que una correcta. Una petición que nunca sale del cliente tampoco es un resultado del cortafuegos, así que lea los contadores para ver si el paquete se evaluó siquiera. Dos pruebas y una lectura de contador le dirán más que una tarde entera leyendo el conjunto de reglas.

La referencia de nftables documenta meta ipsec, rt ipsec y las expresiones específicas de dirección, y es el lugar donde comprobar la sintaxis con su versión instalada. Y mantenga el alcance explícito: esto es un ejemplo IPv4, no dice nada sobre IPv6 y no convierte el reenvío arbitrario de puertos públicos en parte del servicio VPN.