Set nftables alimentato dal DNS verso WireGuard: come funziona il passaggio
Una risposta DNS può alimentare un set nftables, ma un set non instrada nulla. Segui i quattro passaggi e le tre durate che decidono se il direzionamento funziona.
I nomi si risolvono in indirizzi, e quegli indirizzi possono finire in un set del firewall che poi influenza l'instradamento, il che rende possibile il direzionamento basato sul nome senza proxy. Il tranello è che quattro componenti devono passare correttamente: il resolver, il set, il classificatore che marca un nuovo flusso e il peer che lo trasporta. Ogni passaggio fallisce in modo diverso e ciascuno tiene il proprio tempo.
Tratta il progetto come una catena e non come una configurazione. La domanda a ogni passo è quale componente possiede la decisione e cosa succede quando il suo input manca.
Cosa può e cosa non può fare la risposta DNS
dnsmasq può copiare indirizzi dalle risposte in un set nftables, che è un'alimentazione e non una decisione di instradamento. Quell'opzione, documentata nel manuale di dnsmasq, indica la famiglia, la tabella e il set, e il suo 4# iniziale seleziona solo record A, quindi le destinazioni v6 hanno bisogno di una propria disposizione. Il set deve già esistere, perché il resolver aggiunge elementi a qualcosa che ha creato il proprietario del firewall. Nulla in quel passo sceglie un'interfaccia, una tabella o un peer.
Anche il client deve usare quel resolver per il nome. Un'applicazione con un proprio DNS cifrato, o una risposta in cache di prima che esistesse la politica, si connette senza creare alcuna voce nel set.
Il set è un input, non una rotta
Un elemento in un set è una condizione di corrispondenza. Qualcosa deve guardarlo, decidere che questo pacchetto avvia un nuovo flusso e applicare la politica che manda il flusso nel tunnel. Su Linux di solito significa un percorso di uscita capace di instradare che può impostare un marchio, una regola che manda i pacchetti marcati a una tabella dedicata e una rotta in quella tabella verso il dispositivo WireGuard. L'appartenenza da sola non installa nulla di tutto ciò.
nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips
Il peer applica un secondo controllo di copertura che la gente dimentica. WireGuard cifra un pacchetto solo per un peer i cui indirizzi consentiti includono la destinazione, quindi una rotta di politica verso l'interfaccia non basta quando la lista del peer esclude quel prefisso. Tieni la lista sotto il controllo del proprietario dell'instradamento invece di affidarti alla creazione di rotte che il gestore fa per caso.
Marchi, tabelle e copertura del peer
I marchi sono uno spazio dei nomi condiviso, quindi sia il valore sia la maschera devono essere concordati con tutto il resto che li usa. Una regola che manda il traffico marcato a una tabella dedicata ha bisogno di un risultato definito quando quella tabella non ha alcuna rotta corrispondente, perché una ricerca senza risposta può proseguire alla regola successiva e far uscire il pacchetto dall'interfaccia fisica. Una rotta predefinita blackhole dentro la tabella dedicata trasforma quella fuga silenziosa in uno scarto visibile. Ciò che il progetto ancora non può fare è chiudersi in caso di guasto per una destinazione che non è mai entrata nel set.
I pacchetti esterni del tunnel stesso devono sfuggire al classificatore. Gli strumenti di WireGuard forniscono un marchio di socket proprio per questo, e usarlo impedisce che l'incapsulamento venga instradato di nuovo nell'interfaccia che sta costruendo.
Prova ogni durata separatamente
Tre memorie invecchiano secondo tre calendari: la cache del resolver, gli elementi del set e la connessione tracciata. Provali in quest'ordine e osserva se ciascuno si muove quando deve. I comandi qui sotto leggono il resolver, il set, la tabella delle connessioni e le regole di politica senza cambiare nulla.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
Una ricerca nuova che aggiunge un elemento dimostra che l'alimentazione funziona, mentre un elemento vecchio che sopravvive alla sua risposta è un disallineamento di durata che vale la pena annotare. Una nuova connessione nella tabella delle connessioni con il marchio atteso mostra che il classificatore è stato eseguito, e una connessione vecchia che conserva il marchio originale è comportamento corretto e non un difetto. L'elenco delle regole risponde se la ricerca di politica esiste, che è una domanda diversa dal se ha corrisposto. Leggi i quattro output in quest'ordine e il passaggio che fallisce si tradirà da solo.
Quando il requisito è che un nome preciso usi sempre un solo percorso, un set alimentato dal DNS non può dimostrarlo, perché gli indirizzi condivisi portano anche altri nomi. Un proxy o un meccanismo a livello applicativo è lo strumento per quella garanzia.