Redirección de puerto a un peer de WireGuard detrás de NAT: DNAT más SNAT

Un navegador solicita https://203.0.113.10:8443, el proxy acepta la conexión y el servicio en el peer de WireGuard nunca responde. La regla DNAT hace su trabajo; la respuesta es la parte que falla. Siga el paquete por las dos traducciones y la regla que falta se vuelve obvia. La corrección es una sentencia NAT más en el hook correcto, no un túnel nuevo.

Siga una solicitud de principio a fin

La solicitud llega a la interfaz pública del proxy con la dirección pública del cliente como origen y la dirección del proxy como destino. En nat PREROUTING, la regla DNAT reescribe el destino a la dirección del túnel del peer, 10.90.0.2. La decisión de enrutamiento envía entonces el paquete por wg0 y la ruta de reenvío queda completa.

En el peer, el paquete lleva ahora la dirección pública de origen original, porque nada la ha reescrito. El servicio acepta la conexión y envía su respuesta a su propia puerta de enlace predeterminada, que es el router doméstico delante del peer. Ese router no tiene estado para un flujo que nunca vio y o bien descarta el paquete o bien lo traduce a su propia dirección pública, que el cliente no aceptará.

La asimetría es todo el problema: la solicitud pasa por el proxy y la respuesta intenta ir directamente. El seguimiento de conexiones del proxy solo ayuda si la respuesta vuelve por el proxy, y no puede volver ahí mientras la dirección de origen siga apuntando al cliente original.

Añada la traducción de vuelta

Reescriba el origen del flujo reenviado a la dirección del túnel del proxy antes de que salga hacia el peer. El servicio responde entonces a 10.90.0.1, el proxy lo recibe y el seguimiento de conexiones invierte ambas traducciones antes de que el paquete vuelva al cliente.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

La regla POSTROUTING es deliberadamente estrecha: coincide con el destino traducido y con la interfaz del túnel, así que no reescribe tráfico no relacionado que casualmente sale por wg0. Una regla masquerade amplia también ocultaría la dirección del cliente, pero lo haría para cada flujo y haría más difícil auditar la tabla NAT.

Coloque las reglas donde existe el túnel

Las reglas que hacen referencia a la dirección o a la interfaz del túnel deben ejecutarse después de que wg-quick lo haya configurado. La interfaz se crea antes de PreUp, pero las direcciones, la MTU, el DNS y las rutas se aplican después, y PostUp se ejecuta cuando todo eso está en su sitio. Ponga las adiciones en PostUp y las eliminaciones en PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Las eliminaciones deben coincidir con las adiciones token por token, incluidas las coincidencias de multiport y de interfaz. Una eliminación que difiere en una coincidencia no elimina nada, y la siguiente reconexión añade una segunda copia de la regla. Tras varias reconexiones la tabla contiene duplicados difíciles de atribuir a una línea de configuración.

Compruebe el resultado con iptables -t nat -S después de una reconexión. Si la misma regla aparece dos veces, la línea PreDown no coincide y la limpieza falla en silencio.

Reenvío, filtrado y el otro NAT

Active el reenvío IPv4 de forma permanente y luego permita el flujo reenviado en la tabla de filtrado. DNAT ocurre antes de la cadena FORWARD, así que la regla de filtrado coincide con el destino traducido en lugar de con la dirección pública. Si UFW gestiona el firewall, exprese el permiso como regla de enrutamiento; una regla de host simple no cubre el tráfico reenviado.

Otras dos capas de NAT aún pueden romper la ruta incluso cuando las reglas del proxy son correctas. En una conexión doméstica, la dirección pública pertenece al router, y abrir el puerto en su firewall no es lo mismo que crear una entrada de redirección de puerto que envíe ese puerto al proxy. Un puerto que parece abierto desde fuera mientras nada responde a menudo carece justo de esa asignación.

En un VPS con NAT, el proveedor asigna un puerto público a una dirección privada. La asignación debe coincidir con el puerto que anuncia, y una discrepancia parece idéntica a un túnel roto. Confirme la asignación del proveedor antes de cambiar la configuración de WireGuard.

Verifique la ruta de vuelta y acepte el coste

Conéctese desde una red que no sea la LAN del proxy y, después, inspeccione el par de traducciones mientras la conexión está abierta:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

La entrada de conntrack debería mostrar la tupla original, la tupla traducida y la dirección de la respuesta. Si falta la respuesta, el peer no envía por el túnel, lo que normalmente significa que la regla SNAT no se aplicó o que el propio firewall del peer descartó el flujo.

Reinicie una vez para demostrar que PostUp vuelve a aplicar las reglas y, después, detenga el túnel y confirme que PreDown las eliminó. Las reglas muertas que sobreviven a una desconexión son la razón por la que un cambio posterior se comporta de forma impredecible.

Por último, acepte lo que cuesta el SNAT. El servicio ve cada solicitud como procedente del proxy, así que los registros de acceso, los límites de tasa por cliente y las listas de direcciones permitidas ya no distinguen a los usuarios. El caso hairpin necesita su propia traducción de origen para los clientes en la LAN del proxy. Si el peer necesita direcciones reales de los clientes, la alternativa es una ruta de vuelta a la red del cliente, que es más trabajo pero conserva la información.