Disparo de puertos frente a reenvío de puertos para un servidor VPN doméstico
El disparo abre una asignación tras el tráfico saliente; el reenvío asigna el puerto de forma permanente. Un servidor VPN doméstico necesita lo segundo, limitado al oyente real.
El reenvío de puertos y el disparo de puertos están en el mismo menú en la mayoría de los routers domésticos, y por eso se tratan como dos formas de hacer un mismo trabajo. El reenvío es una regla estática: una conexión entrante a un puerto WAN se traduce a una dirección y un puerto internos fijos, ocurra o no otra cosa. El disparo es condicional: el router vigila el tráfico saliente y solo abre una asignación entrante después de que sale una conexión coincidente. Un servidor VPN espera que otro se conecte primero, así que esa condición es justo lo único que nunca puede cumplir.
Dos reglas con ciclos de vida distintos
La NAT de IPv4 tiene estado. Cuando un equipo interno envía un paquete hacia fuera, el router crea una asignación para que las respuestas encuentren el camino de vuelta; un paquete entrante que no coincide con ninguna asignación se descarta, y ese es el comportamiento que mantiene un escritorio sin actualizar fuera de internet. El reenvío es una entrada de traducción permanente añadida a mano. El disparo es un agujero temporal vigilado por un patrón de tráfico.
La diferencia práctica es el tiempo. Un reenvío existe desde que se guarda hasta que alguien lo borra. Una asignación disparada existe después de que el disparador se activa y se cierra con un temporizador de inactividad, medido en minutos en hardware de consumo, o de inmediato al reiniciar.
Ninguno es más seguro en abstracto. Un reenvío expone un puerto de forma continua; un disparador lo expone solo tras cierto tráfico saliente. Para un servicio que debe aceptar el primer paquete de un desconocido, solo uno de los dos encaja con la tarea.
Por qué el disparo no publicará un servidor
Un servidor VPN es pasivo por diseño. El par, sea un portátil en una cafetería o un móvil con datos móviles, envía el primer paquete, y el router no tiene ninguna asignación para él. Nada dentro inició tráfico hacia el puerto del disparador, así que la regla nunca se activa y la conexión muere antes de que empiece el handshake.
Donde el disparo parece funcionar, algo más genera tráfico en el puerto del disparador: un cliente en la LAN, una sonda de monitorización o las propias comprobaciones salientes del servidor. Entonces la asignación se abre para ese único equipo y se cierra cuando el tráfico se detiene, así que el siguiente par externo vuelve a fallar mientras el primer éxito queda en el registro como si fuera una prueba.
El disparo también suele ser de un solo equipo. Muchas implementaciones permiten que solo un dispositivo interno tenga la asignación a la vez, lo cual es exactamente lo incorrecto para un servidor que debe responder a varios pares. La función se creó para aplicaciones que abren una conexión de control hacia fuera y esperan datos entrantes en un segundo puerto, y sigue encajando en esa forma.
Qué asigna realmente un reenvío
Un reenvío es una entrada de traducción: puerto WAN y protocolo hacia dirección y puerto internos. Necesita un oyente que ya se ejecute al otro lado, y necesita que la dirección interna se quede donde está. Una concesión DHCP que se muda a otra máquina envía cada túnel al equipo equivocado, en silencio, así que cree la reserva antes de la regla.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
El protocolo importa más de lo que sugiere el formulario. OpenVPN sobre UDP necesita un reenvío UDP, WireGuard necesita UDP, y los datos de IPsec llegan como ESP, protocolo IP 50, que no tiene ningún puerto. Un formulario de reenvío que solo acepta TCP o UDP no puede expresar eso, así que IPsec necesita passthrough o una asignación estática uno a uno en lugar de una regla de puerto.
La capa por encima de su router
Un reenvío solo controla la traducción que es suya. Si la dirección WAN no es suya, que es el caso detrás de una NAT de operador donde los abonados comparten 100.64.0.0/10 como se describe en RFC 6598, la conexión entrante nunca llega a su router porque el proveedor tradujo primero. Ninguna regla en su dispositivo puede arreglar ese orden.
La NAT doble es el mismo problema en miniatura. Su router reenvía al router del ISP, que no tiene ninguna regla coincidente y descarta el paquete. O añade la regla en el dispositivo exterior, o pone el dispositivo exterior en modo puente y deja que el suyo tenga la dirección pública.
Por eso la prueba tiene que venir de fuera. Una prueba desde la misma LAN a través de la dirección pública depende del soporte de hairpin NAT y puede pasar o fallar por motivos ajenos a la regla; un móvil con datos móviles, o un amigo en otra red, es la comprobación más limpia.
Delimite la regla y luego verifique las dos mitades
Reenvíe un puerto a una dirección. Un rango añadido porque los primeros intentos fallaron es como las interfaces de gestión acaban en internet, y el oyente de VPN no necesita la página de administración del router publicada al lado.
Conserve todo lo que ya protegía a ese oyente: identidad por certificado o clave, cortafuegos del equipo, versiones actuales de los paquetes. Un reenvío deja entrar un paquete; la autenticación decide si el paquete se convierte en túnel, y son dos fallos separados cuando algo va mal.
La verificación tiene dos mitades. El handshake debe completarse desde una red externa, y luego un recurso privado detrás del servidor debe responder por el túnel. El reenvío admite la conexión del túnel y nada más; el enrutamiento y la autorización para 10.8.0.0/24 son otro ajuste en otra pantalla.
Decida con tres preguntas
Tres preguntas resuelven la elección más rápido que cualquier tabla comparativa:
- ¿Se conecta algo desde fuera como primer paquete? Entonces use reenvío, o un relé. El disparo no puede abrirse sin un tráfico saliente que nunca existirá.
- ¿Debe el agujero sobrevivir al tiempo de inactividad? Entonces use reenvío, porque una asignación disparada se cierra según su propio calendario.
- ¿La dirección WAN es suya para publicarla? Si no lo es, arregle la capa de arriba antes de editar cualquier regla.
Si la respuesta a las tres es no, que es el caso de un portátil que marca por sí mismo a un proveedor comercial, no hace falta ninguna de las dos reglas. Un cliente detrás de NAT funciona porque crea él mismo la asignación con estado, y eso cubre a la mayoría de quienes leen una página de reenvío de puertos a medianoche.