Le regole di inoltro che catturano tutte le porte possono inghiottire il listener WireGuard

Un gateway pubblico esegue già WireGuard su UDP 51820, SSH sulla 22 e un’applicazione che deve essere raggiungibile da internet. La regola tentatrice inoltra ogni porta al peer e dichiara il lavoro finito. Su un gateway WireGuard quella regola può catturare il trasporto del tunnel stesso e chiuderti fuori dalla macchina che lo termina. Pubblicare è una decisione di routing con un’eccezione per il piano di controllo, non una singola riga DNAT.

Ingresso pubblico o ingresso nel tunnel: scegline uno

Pubblicare un servizio crea un nuovo punto d’ingresso su internet. Non è la stessa cosa che concedere l’appartenenza alla VPN a un peer, perché il visitatore non entra mai nel tunnel e il gateway diventa il volto pubblico del backend. Questa distinzione decide il pubblico della regola e il suo certificato.

Le interfacce amministrative raramente appartengono a quella posizione. Una pagina di amministrazione raggiunta dai client VPN autorizzati mantiene la superficie d’attacco dentro il tunnel ed evita di esporre un modulo di accesso a scansioni arbitrarie. Gli endpoint applicativi pubblici necessitano comunque di un proprio certificato TLS, di autenticazione e di limitazione della frequenza; il salto WireGuard cifrato non protegge il tratto del visitatore fino al gateway.

Se il servizio deve davvero essere pubblico, annota il nome host, il certificato che lo copre e gli intervalli di visitatori che devono raggiungerlo. Quei tre fatti decidono in seguito la forma della regola e la politica di filtro. Tutto ciò che sta fuori è un allargamento dell’ambito su un listener pubblico.

Una porta in ingresso, un backend in uscita

Usa un’unica porta pubblica e un solo servizio backend. In questo esempio eth0 porta l’indirizzo pubblico 198.51.100.20, l’indirizzo del tunnel del gateway è 10.200.0.1 e il peer esegue l’applicazione su 10.200.0.7. La porta pubblica TCP 9443 viene mappata sulla 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 regola SNAT corrisponde al backend tradotto e alla destinazione pubblica originale, quindi un’altra connessione allo stesso servizio backend resta fuori da questa mappatura. Nasconde anche l’indirizzo del visitatore al peer, ed è il compromesso che rende un ritorno instradato con conservazione della sorgente un progetto separato. Il riferimento alle estensioni iptables documenta entrambi i target e le loro opzioni di corrispondenza.

L’inoltro deve comunque essere abilitato, e la catena di filtro ha bisogno di un permesso per la destinazione e la porta tradotte più le risposte stabilite. La catena FORWARD vede la destinazione tradotta dopo il DNAT, quindi una regola scritta sull’indirizzo pubblico non corrisponde al pacchetto inoltrato. Scrivi il permesso sulla tupla del backend, non su quella pubblica.

Il peer deve accettare la connessione del servizio dall’indirizzo del tunnel del gateway e inviare la risposta indietro attraverso il tunnel. Il suo AllowedIPs deve autorizzare la sorgente che riceve davvero, che con la traduzione della sorgente è l’indirizzo del tunnel del gateway, e una voce ampia 0.0.0.0/0 su ogni peer non è necessaria per questo progetto. A scartare il traffico di ritorno è un peer la cui lista omette quell’indirizzo, oppure un progetto con conservazione della sorgente che inoltra invece l’indirizzo del visitatore, quindi controlla la sorgente che il peer vede davvero, non quella nella tua regola.

Tieni i listener del gateway fuori dalla regola

Sostituisci la corrispondenza sulla porta con una regola che copre ogni destinazione TCP e UDP, e il socket WireGuard del gateway cade dentro. La traduzione della destinazione avviene prima che la macchina decida che un pacchetto è locale, quindi UDP 51820 può finire sul peer invece che sul processo che tiene ogni connessione dei peer. La regola si carica senza errori e il tunnel muore, un guasto difficile da leggere dal lato del peer.

SSH, gli agenti di monitoraggio e ogni altro servizio ospitato sul gateway hanno la stessa esposizione. Una regola che inoltra tutto non distingue il piano di controllo dall’applicazione pubblicata, e il primo riavvio dopo la modifica è il momento in cui il blocco diventa evidente. La regola che cattura tutto non avverte del servizio che si assume silenziosamente. Lo scopri quando fallisce la connessione successiva.

Se l’inoltro ampio è davvero necessario, riserva le porte di controllo prima della regola che cattura tutto oppure usa un indirizzo pubblico separato per la pubblicazione. La seconda opzione è più pulita perché l’indirizzo di controllo mantiene la propria politica, ma il provider deve fornire quell’indirizzo; aggiungere un record DNS non ne assegna uno.

L’inoltro ampio TCP e UDP non copre comunque tutti i protocolli. ICMP, IPv6, il feedback path-MTU e il trasporto esterno della VPN necessitano di una propria politica, e una regola che copre TCP e UDP lascia quei casi alla catena predefinita.

Scegli il modello prima di scrivere le regole

Quattro forme coprono la maggior parte delle pubblicazioni da un gateway, e la scelta dipende da quanti servizi esegui e da quanto rischio sul piano di controllo puoi tollerare. La tabella seguente le ordina dalla più stretta alla più ampia.

Inizia con il modello stretto anche se prevedi altri servizi in seguito. È il più facile da verificare, e convertire un insieme di regole strette in una regola che cattura tutto, già rivista, è più semplice che scoprire quale listener abbia catturato una regola ampia. Qualunque modello tu scelga, tieni le regole presso il responsabile del firewall. Applicare righe iptables accanto a una configurazione UFW o nftables che gestisce le stesse catene produce una politica che cambia in base all’ordine di avvio.

Dimostra sia la pubblicazione sia il percorso di controllo

Prova da un client esterno autorizzato usando il nome host approvato e un certificato valido per esso. Conferma quale backend ha risposto, poi verifica che le porte pubbliche non correlate restino negate. Un controllo del certificato disabilitato non è un test HTTPS superato, e una connessione che arriva al backend sbagliato è peggio di una fallita.

Dopo di che verifica il gateway stesso: collega un peer WireGuard, apri una sessione SSH e conferma che il monitoraggio riporti ancora. Il servizio pubblicato può funzionare mentre il piano di controllo è rotto, quindi entrambi i controlli appartengono alla stessa finestra di modifica. Riavvia una volta per dimostrare che le regole vengono riapplicate nell’ordine previsto, poi rimuovi la pubblicazione e conferma che la rimozione corrisponda davvero all’aggiunta. Un grande insieme di aggiunte all’avvio con una rimozione incompleta è il modo in cui un test temporaneo diventa un’apertura permanente.