Un puerto OpenVPN, tres servicios: por qué importan los puertos internos

Una sesión SSH, una aplicación web y una consulta de nombre pueden compartir una única conexión VPN sin pelearse por los puertos. El cliente construye un único flujo cifrado hacia la puerta de enlace, y cada conversación de aplicación viaja dentro de él. Fuera, solo se ven el transporte y el puerto propios del túnel. Dentro, cada servicio conserva su propio puerto y sigue necesitando su propio permiso.

Qué transporta el flujo exterior y qué oculta

El cliente envuelve cada paquete en el transporte del túnel antes de que salga de la máquina. Ese flujo exterior tiene un único puerto de destino, fijado cuando se configuró la VPN. Dentro del envoltorio, cada paquete original conserva la dirección y el puerto del servicio al que se dirige. La puerta de enlace quita el envoltorio y enruta según la cabecera interna, de modo que el destino ve un cliente corriente que llega desde la red.

Por tanto, una captura en la interfaz WAN muestra una conversación, no tres. Los puertos internos solo aparecen tras la desencapsulación. Por eso una sola apertura del cortafuegos puede transportar SSH, HTTPS y DNS a la vez.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

La documentación de TUN/TAP cubre la entrega en la que un dispositivo TUN enrutado pasa paquetes IP entre el núcleo y un proceso en espacio de usuario. Esa entrega es lo que hace visible la cabecera interna para el código de enrutamiento y cortafuegos de la puerta de enlace. También explica por qué el puerto exterior no dice nada sobre qué servicios están permitidos.

El reenvío NAT pertenece al oyente, no a las aplicaciones

Una puerta de enlace autoalojada detrás de NAT IPv4 necesita una única traducción de entrada: la dirección y el puerto públicos mapeados al oyente de la VPN. No se requiere ninguna regla para SSH, HTTPS o DNS solo porque los usuarios del túnel lleguen a ellos. Publicar esos puertos expondría servicios que el túnel ya protege. La regla de reenvío describe la accesibilidad del oyente, no un permiso para nada del interior.

Lo contrario también se cumple. Abrir el puerto del túnel no expone nada más, así que un servicio accesible solo a través del túnel mantiene cerrada su superficie pública. Esa separación suele ser justo la razón de mantener el servicio privado.

La política interna es donde realmente se decide el acceso

El cifrado protege el camino; no autoriza un destino. Las rutas del cliente eligen qué prefijos entran en el túnel, la política de reenvío de la puerta de enlace decide si los paquetes pueden salir de él, y el cortafuegos del destino más el inicio de sesión deciden si el servicio responde. DNS es el caso más claro: transportar consultas no hace que un resolutor las acepte de su grupo de clientes. Cada capa puede decir que no de forma independiente.

Pruebe cada servicio por separado a través del túnel. Una consulta correcta no dice nada sobre el puerto web, y una petición web correcta no dice nada sobre SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Cuando el túnel está activo y todo falla, lea primero la tabla de rutas del cliente. Cuando un servicio falla mientras los demás funcionan, el fallo está en ese destino. Esas dos observaciones apuntan a responsables distintos, y mezclarlas hace perder tiempo.

WireGuard traza la misma línea

WireGuard nombra su oyente exterior con ListenPort, y una aplicación interna sigue usando el puerto de servicio que necesite. AllowedIPs es un conjunto de prefijos enrutados, no una lista de puertos de servicio permitidos. Leerlo como una lista blanca de puertos produce reglas que no coinciden con lo que hace el túnel. La nomenclatura es distinta; la separación por capas no.

Permita el servicio en la política de entrada local cuando se ejecuta en el propio punto final, o en la política de reenvío cuando está detrás de ese punto final. La distinción decide qué conjunto de reglas ve el paquete.

La forma general es un transporte exterior con muchas conversaciones internas. Los productos que necesitan varios intercambios exteriores, o un protocolo IP distinto, son un recordatorio de que el patrón de un solo puerto público describe este diseño y no todas las VPN.