Las reglas de reenvío de todos los puertos pueden tragarse tu listener de WireGuard

Una puerta de enlace pública ya ejecuta WireGuard en UDP 51820, SSH en 22 y una aplicación que debe ser accesible desde internet. La regla tentadora reenvía cada puerto al peer y da el trabajo por terminado. En una puerta de enlace WireGuard esa regla puede capturar el propio transporte del túnel y dejarte fuera de la máquina que lo termina. Publicar es una decisión de enrutamiento con una excepción de plano de control, no una sola línea DNAT.

Entrada pública, entrada por túnel: elige una

Publicar un servicio crea un nuevo punto de entrada a internet. No es lo mismo que conceder membresía VPN a un peer, porque el visitante nunca se une al túnel y la puerta de enlace se convierte en la cara pública del backend. Esa distinción decide el público de la regla y su certificado.

Las interfaces administrativas rara vez pertenecen a esa posición. Una página de administración a la que llegan clientes VPN autorizados mantiene su superficie de ataque dentro del túnel y evita exponer un formulario de inicio de sesión a un escaneo arbitrario. Los puntos finales de aplicación públicos siguen necesitando su propio certificado TLS, autenticación y limitación de tasa; el salto WireGuard cifrado no protege el tramo del visitante hasta la puerta de enlace.

Si el servicio realmente debe ser público, anota el nombre de host, el certificado que lo cubre y los rangos de visitantes que deben llegar a él. Esos tres hechos deciden más adelante la forma de la regla y la política de filtrado. Cualquier cosa fuera de ellos es una ampliación de alcance en un listener público.

Un puerto hacia dentro, un backend hacia fuera

Usa un solo puerto público y un solo servicio de backend. En este ejemplo eth0 lleva la dirección pública 198.51.100.20, la dirección de túnel de la puerta de enlace es 10.200.0.1 y el peer ejecuta la aplicación en 10.200.0.7. El TCP 9443 público se asigna al TCP 8443 del peer:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

La regla SNAT coincide con el backend traducido y el destino público original, así que otra conexión al mismo servicio de backend queda fuera de este mapeo. También oculta la dirección del visitante al peer, y ese es el compromiso que convierte un retorno enrutado que preserva el origen en un diseño aparte. La referencia de extensiones de iptables documenta ambos objetivos y sus opciones de coincidencia.

Todavía hay que habilitar el reenvío, y la cadena de filtrado necesita un permiso para el destino y el puerto traducidos, además de las respuestas establecidas. La cadena FORWARD ve el destino traducido después del DNAT, así que una regla escrita contra la dirección pública no coincide con el paquete reenviado. Escribe el permiso contra la tupla del backend, no contra la pública.

El peer debe aceptar la conexión del servicio desde la dirección de túnel de la puerta de enlace y enviar la respuesta de vuelta por el túnel. Su AllowedIPs debe autorizar el origen que realmente recibe, que con traducción de origen es la dirección de túnel de la puerta de enlace, y una entrada amplia 0.0.0.0/0 en cada peer no hace falta para este diseño. Lo que tira el tráfico de retorno es un peer cuya lista omite esa dirección, o un diseño que preserva el origen y reenvía la dirección propia del visitante, así que comprueba el origen que el peer ve de verdad, no el de tu regla.

Mantén los listeners propios de la puerta de enlace fuera de la regla

Cambia la coincidencia de puerto por una regla que cubra cada destino TCP y UDP, y el socket WireGuard propio de la puerta de enlace cae dentro de ella. La traducción de destino ocurre antes de que la máquina decida que un paquete es local, así que UDP 51820 puede acabar en el peer en lugar del proceso que mantiene cada conexión de peer. La regla se carga con éxito y el túnel muere, una falla difícil de leer desde el lado del peer.

SSH, los agentes de monitorización y cualquier otro servicio alojado en la puerta de enlace tienen la misma exposición. Una regla que reenvía todo no distingue el plano de control de la aplicación publicada, y el primer reinicio tras el cambio es cuando el bloqueo se hace evidente. La regla que lo abarca todo no avisa del servicio que asume en silencio. Lo descubres cuando falla la siguiente conexión.

Si el reenvío amplio es realmente necesario, reserva los puertos de control antes de la regla que lo abarca todo o usa una dirección pública separada para publicar. La segunda opción es más limpia porque la dirección de control conserva su propia política, pero el proveedor debe entregar esa dirección; añadir un registro DNS no asigna una.

El reenvío amplio de TCP y UDP tampoco es todos los protocolos. ICMP, IPv6, la realimentación de MTU de ruta y el transporte exterior de la VPN necesitan su propia política, y una regla que cubre TCP y UDP deja esos casos a la cadena predeterminada.

Elige el modelo antes de escribir reglas

Cuatro formas cubren la mayoría de las publicaciones de puerta de enlace, y la elección depende de cuántos servicios ejecutas y cuánto riesgo de plano de control puedes tolerar. La tabla de abajo las ordena de la más estrecha a la más amplia.

Empieza con el modelo estrecho aunque esperes más servicios más adelante. Es el más fácil de auditar, y convertir un conjunto de reglas estrechas en una regla que lo abarca todo y revisada es más sencillo que descubrir qué listener capturó una regla amplia. Elijas el modelo que elijas, mantén las reglas con el propietario del cortafuegos. Aplicar líneas de iptables junto a una configuración de UFW o nftables que también gestiona las mismas cadenas produce una política que cambia según el orden de arranque.

Demuestra tanto la publicación como la ruta de control

Prueba desde un cliente externo autorizado con el nombre de host aprobado y un certificado válido para él. Confirma qué backend respondió y luego comprueba que los puertos públicos no relacionados siguen denegados. Una comprobación de certificado desactivada no es una prueba HTTPS superada, y una conexión que llega al backend equivocado es peor que una fallida.

Después de eso, verifica la propia puerta de enlace: conecta un peer WireGuard, abre una sesión SSH y confirma que la monitorización sigue informando. El servicio publicado puede funcionar mientras el plano de control está roto, así que ambas comprobaciones pertenecen a la misma ventana de cambio. Reinicia una vez para demostrar que las reglas se vuelven a aplicar en el orden esperado, luego retira la publicación y confirma que la retirada coincide de verdad con la adición. Un conjunto grande de adiciones de arranque con una retirada incompleta es como una prueba temporal se convierte en una apertura permanente.