Inoltro di porta verso un peer WireGuard dietro NAT: DNAT più SNAT

Un browser richiede https://203.0.113.10:8443, il proxy accetta la connessione e il servizio sul peer WireGuard non risponde mai. La regola DNAT fa il suo lavoro; è la risposta la parte che fallisce. Seguite il pacchetto attraverso entrambe le traduzioni e la regola mancante diventa evidente. La correzione è un’istruzione NAT in più nell’hook giusto, non un nuovo tunnel.

Seguite una richiesta dall’inizio alla fine

La richiesta arriva sull’interfaccia pubblica del proxy con l’indirizzo pubblico del client come sorgente e l’indirizzo del proxy come destinazione. In nat PREROUTING la regola DNAT riscrive la destinazione verso l’indirizzo del tunnel del peer, 10.90.0.2. La decisione di routing invia poi il pacchetto attraverso wg0 e il percorso di inoltro è completo.

Sul peer il pacchetto porta ora l’indirizzo pubblico di origine originale, perché nulla lo ha riscritto. Il servizio accetta la connessione e invia la sua risposta al proprio gateway predefinito, che è il router domestico davanti al peer. Quel router non ha alcuno stato per un flusso che non ha mai visto e o scarta il pacchetto o lo traduce verso il proprio indirizzo pubblico, che il client non accetterà.

L’asimmetria è l’intero problema: la richiesta passa attraverso il proxy e la risposta cerca di andare direttamente. Il tracciamento delle connessioni del proxy aiuta solo se la risposta torna attraverso il proxy, e non può tornarci finché l’indirizzo di origine punta ancora al client originale.

Aggiungete la traduzione di ritorno

Riscrivete l’origine del flusso inoltrato verso l’indirizzo del tunnel del proxy prima che parta per il peer. Il servizio risponde allora a 10.90.0.1, il proxy lo riceve e il tracciamento delle connessioni inverte entrambe le traduzioni prima che il pacchetto 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 regola POSTROUTING è volutamente stretta: corrisponde alla destinazione tradotta e all’interfaccia del tunnel, quindi non riscrive traffico non correlato che esce per caso da wg0. Una regola masquerade ampia nasconderebbe anch’essa l’indirizzo del client, ma lo farebbe per ogni flusso e renderebbe la tabella NAT più difficile da verificare.

Collocate le regole dove esiste il tunnel

Le regole che fanno riferimento all’indirizzo o all’interfaccia del tunnel devono essere eseguite dopo che wg-quick lo ha configurato. L’interfaccia viene creata prima di PreUp, ma indirizzi, MTU, DNS e rotte vengono applicati dopo, e PostUp viene eseguito quando tutto questo è a posto. Mettete le aggiunte in PostUp e le rimozioni in 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

Le rimozioni devono corrispondere alle aggiunte token per token, comprese le corrispondenze multiport e di interfaccia. Una rimozione che differisce per una corrispondenza non rimuove nulla, e la riconnessione successiva aggiunge una seconda copia della regola. Dopo alcune riconnessioni la tabella contiene duplicati difficili da attribuire a una riga di configurazione.

Verificate il risultato con iptables -t nat -S dopo una riconnessione. Se la stessa regola appare due volte, la riga PreDown non corrisponde e la pulizia fallisce silenziosamente.

Inoltro, filtraggio e l’altro NAT

Attivate l’inoltro IPv4 in modo permanente, poi consentite il flusso inoltrato nella tabella del filtro. DNAT avviene prima della catena FORWARD, quindi la regola del filtro corrisponde alla destinazione tradotta anziché all’indirizzo pubblico. Se UFW gestisce il firewall, esprimete il permesso come regola di rotta; una semplice regola host non copre il traffico inoltrato.

Altri due livelli NAT possono ancora rompere il percorso anche quando le regole del proxy sono corrette. Su una connessione domestica l’indirizzo pubblico appartiene al router, e aprire la porta nel suo firewall non è la stessa cosa che creare una voce di inoltro porta che invii quella porta al proxy. Una porta che sembra aperta dall’esterno mentre nulla risponde spesso manca proprio di quella mappatura.

Su un VPS NAT il provider mappa una porta pubblica su un indirizzo privato. La mappatura deve concordare con la porta che annunciate, e una discrepanza appare identica a un tunnel rotto. Confermate la mappatura del provider prima di modificare la configurazione di WireGuard.

Verificate il percorso di ritorno e accettate il costo

Collegatevi da una rete che non è la LAN del proxy, poi ispezionate la coppia di traduzioni mentre la connessione è aperta:

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

La voce conntrack dovrebbe mostrare la tupla originale, la tupla tradotta e la direzione della risposta. Se manca la risposta, il peer non invia attraverso il tunnel, il che di solito significa che la regola SNAT non è stata applicata o che il firewall del peer ha scartato il flusso.

Riavviate una volta per dimostrare che PostUp riapplica le regole, poi fermate il tunnel e confermate che PreDown le ha rimosse. Le regole morte che sopravvivono a una disconnessione sono il motivo per cui una modifica successiva si comporta in modo imprevedibile.

Infine, accettate quanto costa SNAT. Il servizio vede ogni richiesta come proveniente dal proxy, quindi i log di accesso, i limiti di velocità per client e gli elenchi di indirizzi consentiti non distinguono più gli utenti. Il caso hairpin necessita della propria traduzione di origine per i client sulla LAN del proxy. Se il peer necessita degli indirizzi reali dei client, l’alternativa è una rotta di ritorno verso la rete del client, che richiede più lavoro ma conserva l’informazione.