Come dare a una LAN di test la propria uscita WireGuard

Tre progetti risolvono lo stesso problema di laboratorio: una piccola LAN deve uscire attraverso un peer WireGuard mentre il gateway stesso conserva il suo solito collegamento ascendente. La scorciatoia tentante è spostare la rotta predefinita del router dentro il tunnel, ma questo spezza il percorso di gestione della macchina e tutto il resto che inoltra. L'opzione interessante è il routing basato su policy limitato a un'interfaccia e a un prefisso. Scegliete tra loro rispondendo a tre domande sulla macchina che avete davvero.

Decidete dove vive l'uscita

Prima domanda: questo host inoltra per qualcos'altro? Un gateway di laboratorio dedicato può convivere con una policy di inoltro che scarta per impostazione predefinita. Un router con compiti di produzione non può, e sovrapporre un insieme di regole concorrente su un firewall gestito è esattamente il modo in cui si pianificano le interruzioni. Seconda: potete possedere due oggetti di policy e il loro ordine attraverso i riavvii? Terza: il peer che avete autorizza l'indirizzo sorgente del vostro tunnel e offre un'uscita internet? Un peer che espone solo una rete privata è un altro prodotto, e nessuna modifica locale del routing lo risolve. Se una risposta è no, mettete l'uscita in un namespace o in una macchina virtuale usa e getta.

Un namespace o una VM costano memoria e vi danno un raggio d'impatto pulito. Il routing basato su policy costa due regole e vi lascia una sola macchina da depurare.

Scegliete l'uscita che autorizza la vostra sorgente

La maggior parte dei guasti in questo laboratorio avviene prima che esista una sola regola di firewall. L'operatore dell'uscita deve accettare l'indirizzo sorgente che i vostri pacchetti portano dopo la traduzione, che in questo progetto è l'indirizzo del tunnel e non il prefisso della LAN. Per questo il mascheramento fa parte del progetto fin dall'inizio e non come aggiunta tardiva.

Confermate tre cose con l'operatore: il peer autorizza l'indirizzo del vostro tunnel, inoltra IPv4 invece di terminare su sé stesso, e applica NAT in uscita. Senza la prima, i vostri pacchetti arrivano e svaniscono. Senza la terza, escono con una sorgente privata e muoiono al salto successivo. Poi verificate che wg-quick non installi la propria rotta predefinita, cosa che Table = off impedisce; quell'impostazione sopprime la creazione di rotte, non i controlli AllowedIPs del peer né la sua gestione del DNS.

Due oggetti di policy fanno il pilotaggio

Il pilotaggio richiede una tabella e una regola. La tabella contiene due rotte: il prefisso della LAN in uscita dall'interfaccia LAN e una predefinita in uscita dal tunnel. La regola manda nella tabella il traffico che arriva sull'interfaccia LAN e porta quel prefisso. Usate il selettore iif insieme alla corrispondenza della sorgente, perché i pacchetti WireGuard del gateway nascono localmente e non corrispondono mai a un'interfaccia in ingresso.

La guardia viene prima della ricerca, non dopo. Quell'ordine è l'intera proprietà di sicurezza del progetto.

La guardia è una seconda regola sullo stesso selettore il cui verdetto è unreachable. Datele una priorità numerica più alta così la ricerca vince ancora mentre il tunnel è attivo. Quando la rotta del tunnel sparisce, la ricerca non restituisce nulla e la guardia ferma la ricerca invece di lasciarla cadere sulla rotta predefinita WAN della tabella principale.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Chiudete la falla di ripiego prima di aprirla

Installate prima la guardia e poi la ricerca. Farlo al contrario lascia una finestra di secondi in cui il traffico di un client di test può raggiungere il collegamento ascendente.

Il filtro completa il quadro. Nell'hook forward accettate la direzione dalla LAN al tunnel per il prefisso di test e la direzione di ritorno stabilita, poi scartate tutto il resto; il NAT di quel prefisso sull'interfaccia del tunnel va in postrouting. Lasciare policy drop sulla catena di inoltro è ciò che trasforma una rotta mancante in silenzio invece che in una fuga. Il filtraggio del percorso inverso richiede la modalità permissiva sull'interfaccia del tunnel, perché una sorgente pubblica che arriva decapsulata ha la sua migliore rotta inversa sul lato WAN. Linux prende il valore più alto tra all e quello per interfaccia, quindi impostare l'interfaccia del tunnel non è lo stesso che indebolire la validazione ovunque.

Dimostratelo con il caso di guasto

Ponete al kernel una domanda precisa nominando l'indirizzo sorgente del client e l'interfaccia su cui arriva. Una ricerca senza entrambi risponde a un'altra domanda e sembrerà corretta in entrambi i casi. Poi guardate i contatori del firewall, lo stato di trasferimento del peer e il servizio del client stesso.

Provate la rimozione come si deve. Fermate il tunnel lasciando la regola e il filtro al loro posto: il client dovrebbe bloccarsi e il traffico proprio del gateway dovrebbe continuare a funzionare. Poi fermate il peer senza toccare l'interfaccia locale, ed è il caso che coglie i progetti che si affidano solo alla presenza della rotta. Infine riavviate e ricontrollate l'ordine delle regole, perché un hook di smontaggio che rimuove la guardia restituisce l'intero progetto alla tabella principale. Annotate il numero di tabella, le priorità e i nomi delle interfacce sul ticket di modifica, perché la prossima persona che aggiungerà una regola sarà quella che romperà tutto questo.