¿Deberías aplicar SNAT a una redirección de puerto hacia una subred VPN?

Reenviar un puerto a un host que está detrás del propio cliente VPN del router falla de una forma que parece un problema de cortafuegos, porque la petición llega claramente. El servicio registra una conexión, el cliente espera y no vuelve nada. La traducción de destino hizo su trabajo; el paquete de vuelta es la parte que desapareció. Una regla selectiva de NAT de origen en el router lo arregla, y lo interesante es decidir cuán estrecha puede ser esa regla.

Por qué la respuesta toma otro camino

Una redirección de puerto reescribe a dónde va un paquete, nunca de dónde vino. La dirección del cliente de internet permanece en el campo de origen durante todo el túnel, así que el servicio remoto ve a un extraño y responde de la única forma que conoce: por su propia puerta de enlace predeterminada. Esa puerta de enlace es el concentrador VPN del otro lado, que no tiene ruta de vuelta a una dirección pública arbitraria.

Mire una captura en la interfaz del túnel y la asimetría es obvia: paquetes de petición hacia fuera, nada hacia dentro. La cadena de reenvío permitió el flujo y el túnel lo transportó, así que el descarte ocurre después de que el host remoto ya haya elegido un camino de vuelta.

Una regla de origen lo bastante estrecha para confiar en ella

Haga que el router sea el origen al que responde el host remoto. En esta disposición la dirección WAN es 203.0.113.24, la LAN es 192.168.88.0/24, la dirección del túnel del router es 172.20.5.1, y el servicio responde en 172.20.5.40:8443. La regla de abajo coincide con el paquete después de la traducción de destino, por eso nombra la dirección traducida y no la pública. Nada en ella depende de la dirección del cliente, y ese es exactamente el punto.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Cada coincidencia de esa línea existe para mantener la reescritura local a un servicio en un túnel. Quite la interfaz o el puerto y reescribirá más tráfico del que el problema requiere, y así es como una corrección dirigida se convierte en un misterio para la siguiente persona.

Cuándo una máscara global es la opción honesta

Si el router reenvía muchos servicios a la misma subred VPN, una regla por servicio se convierte en una lista que nadie mantiene. Enmascarar todo lo que sale de la interfaz del túnel es más simple y predecible, a costa de ocultar al cliente original de cada host del otro lado. Elíjalo cuando los registros de allí no se usen para atribución; conserve la regla estrecha cuando sí se usen.

Las dos opciones también fallan de forma distinta. Una regla estrecha ausente rompe un servicio; una máscara amplia que coincide con demasiado puede reescribir en silencio tráfico que ya funcionaba, incluidas las propias conexiones salientes del router.

Compruebe los contadores antes de publicar

Las reglas que nunca coinciden se ven idénticas a las que funcionan hasta que cuenta paquetes. Vuelva a leer la tabla con contadores de bytes antes de que se conecte cualquier cliente, luego conéctese desde una red que no sea la LAN y vuelva a leerla. Dos lecturas son lo que convierte una suposición en un hecho. Publique la redirección solo después de que se mueva la segunda.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Un contador a cero en la regla de origen tras una conexión real significa que la coincidencia es incorrecta, normalmente porque el destino o el puerto no coinciden con el paquete después de la traducción. Si el contador sube pero el cliente aún agota el tiempo, el camino de vuelta está arreglado y otra cosa descarta la respuesta, así que mire después la política de reenvío del otro lado. El acceso en horquilla desde dentro de la LAN es un problema aparte y necesita su propia regla, no una versión más amplia de esta.