Llegar a una /24 remota por un túnel: ¿NETMAP, DNAT o ruta?

Se puede llegar a una subred detrás de un extremo de túnel de tres maneras, y un minuto de recopilar datos normalmente descarta dos. Los datos son si los servidores de allí deben distinguir a los usuarios, si alguien de allí marcará alguna vez hacia su rango, y quién puede editar el router del extremo remoto. Responda a esos tres y el diseño se elige solo. El resto supone que usted opera el extremo y puede editar su cortafuegos.

Tres opciones, y qué cambia realmente cada una

La asignación de prefijos, el DNAT por host y un prefijo enrutado mueven todos los paquetes entre los mismos dos rangos, pero cambian cosas distintas. La asignación inventa un rango alias y reescribe direcciones aritméticamente en vuelo. Las reglas por host también reescriben, salvo que cada destino se nombra a mano. Un prefijo enrutado no reescribe nada: los paquetes conservan las direcciones reales y ambos extremos acuerdan dónde viven esas direcciones.

Empiece la eliminación por el lado remoto, donde las restricciones son más difíciles de cambiar. Si un servidor de allí escribe las direcciones de los clientes en registros, las comprueba contra una lista de permitidos o las entrega a otro sistema, traducir el origen destruye su único identificador. Si el lado remoto también debe marcar, la traducción queda descartada por completo, porque allí nadie sabe que el alias existe. Solo cuando el lado remoto se limita a responder peticiones las opciones más baratas son seguras.

Pares de prefijos, y por qué los tamaños deben coincidir

NETMAP es un objetivo de la tabla nat que trabaja sobre un par de prefijos de idéntica longitud. No tiene una tabla por dirección dentro: quita el prefijo, conserva los bits de host y los vuelve a enganchar al prefijo nuevo, por eso una /24 se asigna a una /24 y nunca a una /25. La posición decide la dirección: una coincidencia de destino en PREROUTING reescribe hacia dónde va un paquete, y una de origen en POSTROUTING reescribe de dónde vino.

Un host en 192.168.2.17 aparece ante sus clientes como 10.50.1.17, y el último octeto no es decorativo: es el mismo número en ambos lados. Añada mañana un host en 192.168.2.40 y su alias será 10.50.1.40, sin ninguna regla que editar.

Los clientes siguen necesitando una ruta para el rango alias que apunte a su máquina, salvo que el alias caiga dentro de una subred que ya alcanzan. La pasarela no necesita ruta para el alias, porque la traducción de destino se ejecuta en PREROUTING, antes de la búsqueda de ruta. El reenvío también debe estar activo, o el núcleo descarta el paquete tras la reescritura. Los tres comandos de abajo son toda la configuración en una pasarela al estilo Debian con los clientes en br0, el alias en 10.50.1.0/24 y el túnel en tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

La respuesta tiene que encontrar su propio camino de vuelta

Reescribir el destino solo decide dónde se entrega un paquete. El servidor del lado remoto todavía debe responder a una dirección que pueda alcanzar, y hay dos formas de organizarlo. Traduzca el origen para que las respuestas vuelvan a su máquina, o deje el origen intacto y dé al lado remoto una ruta para el rango de clientes.

El enmascaramiento a la salida es el camino más corto: una regla en POSTROUTING y el lado remoto ve la dirección de su túnel, así que no necesita ruta propia. El coste es que todos los usuarios se funden en una sola dirección, y los registros por usuario dejan de significar nada. Dejar el origen intacto conserva esa información, pero entonces el sitio remoto debe enviar las respuestas del rango de clientes de vuelta por el túnel. En un OpenVPN servidor eso es un push "route 10.50.9.0 255.255.255.0" enviado, más una línea route 192.168.2.0 255.255.255.0.

El fallo caro es hacer la mitad de cada cosa. Si enmascara parte del tráfico mientras el lado remoto también lleva una ruta de vuelta para otro tráfico, las respuestas llegan por una interfaz donde la entrada de seguimiento de conexiones nunca se vio. El cliente informa de un tiempo de espera para una petición que el servidor registró como atendida. Ambas direcciones de un flujo deben cruzar la misma instancia de netfilter: una pasarela que traduce, no dos cortafuegos en serie.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Lea la entrada en ambos sentidos: la tupla original conserva su alias en el destino, mientras que la tupla de respuesta lleva la dirección real. Si falta la tupla de respuesta, el problema es el camino de vuelta y no la regla. Si los contadores de PREROUTING nunca se movieron, el paquete nunca llegó a ese hook.

Colisiones y la búsqueda que se ejecuta primero

Dos rangos distintos pueden colisionar y ambos fallos parecen un túnel roto y no una regla mala. El alias que invente debe estar sin usar en todo el camino, y el rango real del lado remoto no debe existir ya en su red. Un duplicado produce tráfico intermitente hacia el host equivocado, que es más difícil de diagnosticar que una conexión rechazada. Pregunte a la tabla de rutas antes de añadir una regla.

En la pasarela, ip route get 192.168.2.17 debería nombrar el dispositivo del túnel; un puente local significa que el rango remoto está oculto y ninguna regla nat lo reparará. Si su propia red ya usa 192.168.2.0/24, renumere el sitio remoto en lugar de apilar una asignación sobre la colisión.

Probarlo desde un cliente real y luego conservarlo

Pruebe desde una máquina que realmente vaya a usar el alias, no desde la pasarela, porque el tráfico generado localmente nunca atraviesa PREROUTING de la misma forma. Abra una conexión a un host con alias y observe aparecer juntos los contadores y la entrada de conntrack, luego ciérrela y confirme que la entrada desaparece. Una entrada obsoleta apunta a una conexión medio abierta, lo que suele significar que la respuesta nunca volvió.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Dos o tres conexiones correctas demuestran la aritmética, pero no dicen nada sobre la persistencia ni sobre el siguiente ingeniero. Guarde las reglas donde las lee el proceso de arranque, que en Debian y Ubuntu significa iptables-save > /etc/iptables/rules.v4 con netfilter-persistent activado. Una asignación que desaparece al reiniciar es peor que ninguna, porque la caída llega sin ningún cambio reciente al que culpar.

Deje una nota junto a las reglas: el rango alias, el rango real, la razón del par y qué lado puede iniciar. Esa nota separa un diseño de un montón de reglas que nadie se atreve a borrar. También resuelve la pregunta posterior, cuando el sitio remoto añade un host y una dirección que nadie configuró ya responde. Si la nota dice que el lado remoto necesita una ruta de vuelta, la siguiente persona sabe que quitar la regla de enmascaramiento rompe la conectividad. La documentación aquí es barata; redescubrir una dependencia de NAT a las tres de la madrugada no lo es.