NAT de la LAN a través de tun0 en una puerta de enlace VPN OpenBSD

Dos ingenieros con la misma puerta de enlace OpenBSD a menudo le entregarán dos conjuntos de reglas distintos para llegar a una red remota, y ambos son defendibles. La elección entre traducción de origen y una ruta de retorno no es en absoluto una cuestión de sintaxis. Se reduce a lo que el lado remoto ya sabe de 192.168.88.0/24 y a lo que usted necesita conservar en sus registros. Equivóquese y la línea nat-to parecerá perfectamente correcta mientras las respuestas desaparecen en la puerta de enlace predeterminada remota.

El enrutamiento y la reescritura responden preguntas distintas

La tabla de enrutamiento decide que 172.20.0.0/16 es alcanzable por tun0, y esa decisión ocurre antes de que se consulte cualquier traducción de pf. La traducción de origen cambia entonces la cabecera del paquete para que el extremo remoto vea la dirección de túnel de la puerta de enlace en lugar de un host LAN. Ningún mecanismo sustituye al otro: una regla nat no puede hacer aparecer una ruta, y una ruta no puede convencer a un enrutador remoto que nunca ha oído hablar de su subred privada. Cuando el lado remoto carece de camino de retorno, las respuestas se descartan o se reenvían a su puerta de enlace predeterminada, y ningún ajuste de reglas lo arregla.

Dicho claramente, el reenvío responde a dónde va el tráfico y la traducción responde de quién parece venir. Manténgalos en cajas mentales separadas mientras diseña el conjunto de reglas.

Tres condiciones que lo deciden

Haga tres preguntas en orden y el diseño suele elegirse solo. ¿Tiene la red remota una ruta estática que apunta a la dirección de túnel para 192.168.88.0/24, o su administrador controla los enrutadores de ese camino? Si la respuesta es sí, deje que las direcciones LAN viajen sin modificar y omita la traducción por completo. ¿Necesita visibilidad por cliente en el lado remoto, ya sea para la política de acceso o para una pista de auditoría? Si la respuesta es sí, preservar el origen merece el trabajo de enrutamiento. ¿Es la dirección del túnel lo bastante estable para escribirla en una ruta remota, o cambia entre reconexiones?

Si cualquier respuesta es no o desconocida, nat-to es la opción pragmática, y también es la reversible. Una regla de traducción se elimina en una sola línea en cuanto el lado remoto añade una ruta adecuada. Una ruta de retorno que nunca se instaló le cuesta un hilo de soporte cada vez que alguien pregunta por qué el túnel solo funciona en una dirección.

Coloque el fragmento donde pf realmente lo evalúe

El fragmento siguiente supone que la LAN es 192.168.88.0/24, la red remota es 172.20.0.0/16 y la interfaz de túnel es tun0. Nada en él elige un siguiente salto. Solo reescribe el origen en los paquetes que ya salen por el túnel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dos detalles de esa primera línea cargan con la mayor parte del peso. Los paréntesis alrededor de tun0 le dicen a pf que lea la dirección de la interfaz cada vez que construye una entrada de estado, lo que importa cuando el túnel se renumera tras una reconexión. La palabra match significa que la regla reescribe y luego cae, así que una regla pass separada todavía tiene que admitir el flujo. La interfaz nombrada en la línea match también tiene que ser la que selecciona la tabla de enrutamiento, o pf evaluará la regla en un camino de salida distinto del que toma realmente el paquete.

No olvide el lado del núcleo. El reenvío IPv4 debe estar habilitado, y las reglas pass con estado para túnel y LAN deben existir antes de que algo de esto tenga sentido. La sección PF NAT de las preguntas frecuentes de OpenBSD es la referencia correcta para el orden de palabras clave aquí.

Verifique el conjunto de reglas antes de confiar en el tráfico

Compruebe primero la sintaxis con pfctl -nf /etc/pf.conf, que analiza el archivo sin cargarlo. Después cargue la política y lea lo que el núcleo mantiene realmente, porque una regla que se analizó limpiamente aún puede quedar oculta o adherida a la interfaz equivocada. pfctl -sn imprime las reglas de traducción en su forma cargada, y pfctl -sr imprime las reglas de filtro en orden de evaluación.

Observe el cable a continuación. En la puerta de enlace, tcpdump -ni tun0 'host 172.20.0.10' muestra si la dirección de origen que sale del túnel es la dirección del túnel o el host LAN. Un rápido netstat -rn -f inet confirma a qué interfaz se resuelve el destino. Una vez que fluye el tráfico, pfctl -ss lista las entradas de estado; si un flujo no produjo ningún estado, el paquete nunca coincidió con una regla que lo cree.

Si el lado del túnel parece correcto y las respuestas siguen sin llegar nunca, deje de editar pf. El fallo restante está en el enrutador remoto, donde la respuesta se envía hacia una dirección privada que ese lado no puede alcanzar.

Cuando la traducción cuesta más de lo que ahorra

La traducción oculta clientes, y a veces ese es justo el intercambio equivocado. Las subredes solapadas son un caso: si el lado remoto también usa 192.168.88.0/24 internamente, presentar los hosts LAN como la puerta de enlace empeora la colisión en lugar de mejorarla. Las políticas IPsec que seleccionan tráfico por par de direcciones son otro, porque la base de datos de política de seguridad se compara antes de la traducción y nunca ve su paquete reescrito. Cualquier despliegue que facture, limite o audite por usuario también pierde la identidad que necesita en el momento en que el origen colapsa a una sola dirección.

Los derivados portables de pf son una trampa aparte. Los productos que generan sus propios archivos de reglas esperan que NAT se configure a través de su interfaz, y los fragmentos editados a mano se sobrescriben en la siguiente recarga. Los conjuntos de reglas copiados de guías escritas antes de que existiera la palabra clave match no se cargarán en un núcleo actual, así que porte la sintaxis y lea el error en lugar de adivinar.

La regla de decisión que sobrevive al contacto con redes reales es corta: instale una ruta de retorno cuando pueda, traduzca cuando no pueda, y anote cuál de las tres condiciones le hizo elegir. Esa nota ahorra una tarde a la siguiente persona.