Redirección de puertos frente a acceso por VPN: adónde va realmente el paquete

Dos diseños, una aplicación HTTPS, y el paquete toma una ruta distinta en cada uno. Una redirección de puertos cambia dónde se entrega el paquete y deja intacto el resto. Una VPN lleva primero ese paquete dentro de otro paquete, de modo que el oyente de la aplicación ve un origen distinto y una carga útil máxima menor. El cifrado que la gente discute está presente en ambos casos, porque la aplicación sigue siendo HTTPS; lo que cambia es quién puede abrir una conexión y qué puede observar la red intermedia. Esa distinción resuelve la mayoría de las preguntas prácticas.

La regla DNAT reescribe el destino y se detiene ahí

En una puerta de enlace Linux, publicar un servicio significa una regla en la cadena PREROUTING de la tabla nat, o el equivalente en nftables. La regla coincide con la dirección y el puerto públicos y luego reescribe el destino a la dirección privada de la aplicación. La dirección de origen, el puerto de origen y la carga útil quedan intactos, y conntrack registra la correspondencia para que las respuestas se reescriban a la salida. El comportamiento es el modelo tradicional de traducción de direcciones descrito en RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

El oyente de la aplicación nunca se entera de que la conexión llegó mediante una traducción. Ve la dirección de origen real del cliente, lo que resulta útil para los registros de acceso y los límites de velocidad, y responde a la dirección privada porque conntrack invierte la correspondencia. Nada en esa ruta descifra ni vuelve a cifrar: TLS sigue funcionando entre el cliente y el certificado propio de la aplicación.

La regla también fija los modos de fallo que encontrará más adelante. Si la puerta de enlace reenvía pero el host de la aplicación no tiene ninguna ruta de vuelta al cliente, las respuestas salen con el origen equivocado y el saludo se atasca. Si una segunda regla coincide primero, el orden decide el resultado, y iptables -t nat -L -n -v muestra los contadores que demuestran qué regla se llevó el paquete.

El túnel envuelve el paquete antes de que el oyente lo vea

Una VPN no publica la aplicación en absoluto. El cliente construye un paquete exterior dirigido a la dirección pública de la puerta de enlace, cifra el paquete interior dentro de él, y la puerta de enlace descifra y encamina el paquete interior al destino privado. Con WireGuard el transporte exterior es UDP, normalmente en un puerto alto; con OpenVPN sobre TCP 443 el paquete exterior parece TLS para cualquier cosa que vigile la ruta.

Dentro del túnel el paquete interior conserva direcciones privadas: la dirección de túnel del cliente, digamos 10.8.0.6, y la aplicación en 10.20.30.40. Por eso el oyente ve un origen del grupo del túnel, y cada cliente comparte esa puerta de enlace como siguiente salto. Los registros de acceso detrás de una VPN suelen mostrar la puerta de enlace en lugar del usuario exactamente por esta razón, salvo que la puerta de enlace conserve el origen original.

El envoltorio cuesta espacio de cabecera, y esa es la única diferencia a nivel de mecanismo con una consecuencia medible. Una cabecera IP exterior más UDP más la propia cabecera de WireGuard se comen el MTU de la ruta, así que los paquetes grandes deben fragmentarse o la pila TCP interior debe limitar su MSS. Una transferencia que funciona por la ruta redirigida puede atascarse en el túnel cuando un dispositivo intermedio descarta el ICMP que habría señalado el MTU menor.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

La exposición se decide en la entrada, no por el cifrado

Ambos diseños terminan en el mismo oyente TLS, así que ambos heredan el mismo certificado, las mismas versiones de protocolo y el mismo inicio de sesión de la aplicación. Lo que cambia es quién puede iniciar un saludo. Con una redirección pública, cualquier host que alcance 203.0.113.10:443 obtiene un saludo TCP y un ClientHello TLS antes de que se consulte siquiera la autorización de la aplicación. Con acceso solo por túnel, el oyente es accesible únicamente desde direcciones que la puerta de enlace encamina al túnel, y el SYN de un desconocido muere en la política de la puerta de enlace.

Esa diferencia tiene que ver con la accesibilidad, no con la confidencialidad. Un servicio HTTPS redirigido no es texto plano, y una VPN no elimina la necesidad de autenticación de la aplicación: la admisión al túnel responde si un dispositivo puede enviar paquetes a esta red, mientras que la aplicación de archivos responde si un usuario puede leer un documento. Confundir ambas cosas es como los equipos acaban con una VPN que concede toda la LAN y una aplicación con una sola contraseña compartida.

Inspeccione el oyente y la política por separado, porque cualquiera de los dos puede ser más amplio de lo que supone:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Si ss muestra que el oyente está ligado a 0.0.0.0, la aplicación es accesible desde donde el enrutamiento y la política de cortafuegos lo permitan, y la redirección es solo una de las formas de entrar. Ligarlo a la dirección privada, o restringir el rango de origen en el cortafuegos, es una decisión separada de elegir una VPN, y es la decisión que realmente reduce la exposición.

Mida la ruta, no la etiqueta

Cuando alguien afirma que la redirección es más rápida, la comparación honesta mantiene todo lo demás constante: mismo cliente, misma red de acceso, mismo archivo, misma configuración de TLS, mismo host de aplicación. Ejecute la transferencia dos veces por ruta y anote el tiempo total, el número de fallos y la capacidad de respuesta, no la salida de una prueba de velocidad no relacionada.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Esos números separan el establecimiento de la conexión del tiempo de transferencia, lo que importa porque las dos rutas suelen diferir en latencia de ida y vuelta y en MTU, no en coste de cifrado. El trabajo de TLS ocurre en los extremos en ambos diseños, y un túnel añade encapsulación, una ruta distinta y quizá una puerta de enlace más ocupada. Si la ruta del túnel es más larga o su puerta de enlace está cargada, la diferencia pertenece a la ruta y no a la palabra cifrado.

Elija la política de entrada que el servicio necesita de verdad y luego decida si una diferencia medida justifica cambiarla. Una redirección pública encaja con un servicio pensado para internet abierto, con restricciones de origen, TLS actualizado y monitorización delante. El acceso solo por túnel encaja con una herramienta interna cuyos usuarios ya están inscritos, siempre que el enrutamiento de la puerta de enlace y los permisos de la aplicación sean ambos más estrechos que toda la LAN.

Antes de dar el diseño por terminado, confirme cuatro cosas: a qué dirección está ligado el oyente, qué regla o ruta admite el paquete, si la ruta de vuelta funciona desde la dirección real del cliente y si las cargas grandes sobreviven al MTU. Cada una tiene un comando arriba, y ninguna se responde con la palabra seguro ni con un gráfico de ancho de banda.