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

Un navegador solicita https://203.0.113.10:8443, o proxy acepta a conexión e o servizo no peer de WireGuard nunca responde. A regra DNAT fai o seu traballo; a resposta é a parte que falla. Siga o paquete polas dúas traducións e a regra que falta faise evidente. A corrección é unha sentenza NAT máis no hook correcto, non un túnel novo.

Siga unha solicitude de principio a fin

A solicitude chega á interface pública do proxy co enderezo público do cliente como orixe e o enderezo do proxy como destino. En nat PREROUTING a regra DNAT reescribe o destino ao enderezo do túnel do peer, 10.90.0.2. A decisión de encamiñamento envía entón o paquete por wg0 e a ruta de reenvío queda completa.

No peer, o paquete leva agora o enderezo público de orixe orixinal, porque nada o reescribiu. O servizo acepta a conexión e envía a súa resposta á súa propia pasarela predeterminada, que é o router doméstico diante do peer. Ese router non ten estado para un fluxo que nunca viu e ou descarta o paquete ou o traduce ao seu propio enderezo público, que o cliente non aceptará.

A asimetría é todo o problema: a solicitude pasa polo proxy e a resposta tenta ir directamente. O seguimento de conexións do proxy só axuda se a resposta volve polo proxy, e non pode volver alí mentres o enderezo de orixe siga apuntando ao cliente orixinal.

Engada a tradución de volta

Reescriba a orixe do fluxo reenviado ao enderezo do túnel do proxy antes de que saia cara ao peer. O servizo responde entón a 10.90.0.1, o proxy recíbeo e o seguimento de conexións invirte as dúas traducións antes de que o paquete volva ao 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

A regra POSTROUTING é deliberadamente estreita: coincide co destino traducido e coa interface do túnel, así que non reescribe tráfico non relacionado que casualmente sae por wg0. Unha regra masquerade ampla tamén ocultaría o enderezo do cliente, pero faríao para cada fluxo e faría máis difícil auditar a táboa NAT.

Coloque as regras onde existe o túnel

As regras que fan referencia ao enderezo ou á interface do túnel deben executarse despois de que wg-quick o configurase. A interface créase antes de PreUp, pero os enderezos, a MTU, o DNS e as rutas aplícanse despois, e PostUp execútase cando todo iso está no seu sitio. Poña as adicións en PostUp e as eliminacións 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

As eliminacións deben coincidir coas adicións token por token, incluídas as coincidencias de multiport e de interface. Unha eliminación que difire nunha coincidencia non elimina nada, e a seguinte reconexión engade unha segunda copia da regra. Despois duns cantos reconexións a táboa contén duplicados difíciles de atribuír a unha liña de configuración.

Comprobe o resultado con iptables -t nat -S despois dunha reconexión. Se a mesma regra aparece dúas veces, a liña PreDown non coincide e a limpeza falla en silencio.

Reenvío, filtrado e o outro NAT

Active o reenvío IPv4 de forma permanente e logo permita o fluxo reenviado na táboa de filtrado. DNAT ocorre antes da cadea FORWARD, así que a regra de filtrado coincide co destino traducido en lugar de co enderezo público. Se UFW xestiona a devasa, exprese o permiso como regra de encamiñamento; unha regra de host simple non cobre o tráfico reenviado.

Outras dúas capas de NAT aínda poden romper a ruta mesmo cando as regras do proxy son correctas. Nunha conexión doméstica, o enderezo público pertence ao router, e abrir o porto na súa devasa non é o mesmo que crear unha entrada de redirección de porto que envíe ese porto ao proxy. Un porto que parece aberto desde fóra mentres nada responde a miúdo carece xustamente desa asignación.

Nun VPS con NAT, o provedor asigna un porto público a un enderezo privado. A asignación debe coincidir co porto que anuncia, e unha discrepancia parece idéntica a un túnel roto. Confirme a asignación do provedor antes de cambiar a configuración de WireGuard.

Verifique a ruta de volta e acepte o custo

Conéctese desde unha rede que non sexa a LAN do proxy e, despois, inspeccione o par de traducións mentres a conexión está aberta:

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

A entrada de conntrack debería mostrar a tupla orixinal, a tupla traducida e a dirección da resposta. Se falta a resposta, o peer non envía polo túnel, o que normalmente significa que a regra SNAT non se aplicou ou que a propia devasa do peer descartou o fluxo.

Reinicie unha vez para demostrar que PostUp volve aplicar as regras e, despois, detenga o túnel e confirme que PreDown as eliminou. As regras mortas que sobreviven a unha desconexión son a razón pola que un cambio posterior se comporta de forma imprevisible.

Por último, acepte o que custa o SNAT. O servizo ve cada solicitude como procedente do proxy, así que os rexistros de acceso, os límites de taxa por cliente e as listas de enderezos permitidos xa non distinguen os usuarios. O caso hairpin necesita a súa propia tradución de orixe para os clientes na LAN do proxy. Se o peer necesita enderezos reais dos clientes, a alternativa é unha ruta de volta á rede do cliente, que é máis traballo pero conserva a información.