Redirecció de port a un peer de WireGuard darrere de NAT: DNAT més SNAT

Un navegador sol·licita https://203.0.113.10:8443, el proxy accepta la connexió i el servei del peer de WireGuard no respon mai. La regla DNAT fa la seva feina; la part que falla és la resposta. Seguiu el paquet per les dues traduccions i la regla que falta es fa evident. La solució és una instrucció NAT més al hook correcte, no un túnel nou.

Seguiu una sol·licitud de principi a fi

La sol·licitud arriba a la interfície pública del proxy amb l’adreça pública del client com a origen i l’adreça del proxy com a destinació. A nat PREROUTING, la regla DNAT reescriu la destinació a l’adreça del túnel del peer, 10.90.0.2. La decisió d’encaminament envia llavors el paquet per wg0 i el camí de reenviament queda complet.

Al peer, el paquet porta ara l’adreça pública d’origen original, perquè res l’ha reescrita. El servei accepta la connexió i envia la resposta a la seva pròpia passarel·la per defecte, que és el router domèstic davant del peer. Aquest router no té cap estat per a un flux que no ha vist mai i o bé descarta el paquet o bé el tradueix a la seva pròpia adreça pública, cosa que el client no acceptarà.

L’asimetria és tot el problema: la sol·licitud passa pel proxy i la resposta intenta anar-hi directament. El seguiment de connexions del proxy només ajuda si la resposta torna pel proxy, i no hi pot tornar mentre l’adreça d’origen encara apunta al client original.

Afegiu la traducció de tornada

Reescriviu l’origen del flux reenviat a l’adreça del túnel del proxy abans que surti cap al peer. Aleshores el servei respon a 10.90.0.1, el proxy ho rep i el seguiment de connexions inverteix les dues traduccions abans que el paquet torni al client.

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 és deliberadament estreta: coincideix amb la destinació traduïda i amb la interfície del túnel, així que no reescriu trànsit no relacionat que casualment surt per wg0. Una regla masquerade àmplia també amagaria l’adreça del client, però ho faria per a cada flux i faria més difícil auditar la taula NAT.

Col·loqueu les regles on existeix el túnel

Les regles que fan referència a l’adreça o a la interfície del túnel han d’executar-se després que wg-quick l’hagi configurat. La interfície es crea abans de PreUp, però les adreces, l’MTU, el DNS i les rutes s’apliquen després, i PostUp s’executa quan tot això ja és al seu lloc. Poseu les addicions a PostUp i les eliminacions a 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

Les eliminacions han de coincidir amb les addicions token per token, incloent-hi les coincidències de multiport i d’interfície. Una eliminació que difereix en una coincidència no elimina res, i la següent reconnexió afegeix una segona còpia de la regla. Després d’unes quantes reconnexions la taula conté duplicats difícils d’atribuir a una línia de configuració.

Comproveu el resultat amb iptables -t nat -S després d’una reconnexió. Si la mateixa regla apareix dues vegades, la línia PreDown no coincideix i la neteja falla en silenci.

Reenviament, filtratge i l’altre NAT

Activeu el reenviament IPv4 de manera permanent i després permeteu el flux reenviat a la taula de filtratge. DNAT passa abans de la cadena FORWARD, així que la regla de filtratge coincideix amb la destinació traduïda i no amb l’adreça pública. Si UFW gestiona el tallafoc, expresseu el permís com a regla d’encaminament; una regla d’amfitrió simple no cobreix el trànsit reenviat.

Dues altres capes de NAT encara poden trencar el camí fins i tot quan les regles del proxy són correctes. En una connexió domèstica, l’adreça pública pertany al router, i obrir el port al seu tallafoc no és el mateix que crear una entrada de redirecció de port que enviï aquest port al proxy. Un port que sembla obert des de fora mentre res respon sovint no té exactament aquesta assignació.

En un VPS amb NAT, el proveïdor assigna un port públic a una adreça privada. L’assignació ha de coincidir amb el port que anuncieu, i una discrepància sembla idèntica a un túnel trencat. Confirmeu l’assignació del proveïdor abans de canviar la configuració de WireGuard.

Verifiqueu el camí de tornada i accepteu el cost

Connecteu-vos des d’una xarxa que no sigui la LAN del proxy i, després, inspeccioneu el parell de traduccions mentre la connexió és oberta:

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

L’entrada de conntrack hauria de mostrar la tupla original, la tupla traduïda i la direcció de la resposta. Si falta la resposta, el peer no envia pel túnel, cosa que normalment significa que la regla SNAT no s’ha aplicat o que el tallafoc propi del peer ha descartat el flux.

Reinicieu un cop per demostrar que PostUp torna a aplicar les regles i, després, atureu el túnel i confirmeu que PreDown les ha eliminat. Les regles mortes que sobreviuen a una desconnexió són la raó per la qual un canvi posterior es comporta de manera impredictible.

Finalment, accepteu el que costa el SNAT. El servei veu cada sol·licitud com a provinent del proxy, de manera que els registres d’accés, els límits de taxa per client i les llistes d’adreces permeses ja no distingeixen els usuaris. El cas hairpin necessita la seva pròpia traducció d’origen per als clients de la LAN del proxy. Si el peer necessita adreces reals dels clients, l’alternativa és una ruta de tornada a la xarxa del client, que és més feina però conserva la informació.