Set nftables alimentat din DNS către WireGuard: cum funcționează predarea

Numele se rezolvă în adrese, iar acele adrese pot ajunge într-un set al paravanului care influențează ulterior rutarea, ceea ce face posibilă direcționarea bazată pe nume fără proxy. Capcana este că patru componente trebuie să predea corect: resolverul, setul, clasificatorul care marchează un flux nou și partenerul care îl transportă. Fiecare predare eșuează altfel și fiecare își ține propriul timp.

Tratați proiectul ca pe un lanț, nu ca pe o configurație. Întrebarea la fiecare pas este care componentă deține decizia și ce se întâmplă când îi lipsește intrarea.

Ce poate și ce nu poate răspunsul DNS

dnsmasq poate copia adrese din răspunsuri într-un set nftables, ceea ce este o alimentare, nu o decizie de rutare. Opțiunea respectivă, documentată în manualul dnsmasq, indică familia, tabelul și setul, iar 4#-ul ei inițial selectează doar înregistrări A, așa că destinațiile v6 au nevoie de propria rânduială. Setul trebuie să existe deja, pentru că resolverul adaugă elemente la ceva creat de proprietarul paravanului. Nimic din acel pas nu alege o interfață, un tabel sau un partener.

Clientul trebuie și el să folosească acel resolver pentru nume. O aplicație cu DNS criptat propriu, sau un răspuns din cache de dinainte de a exista politica, se conectează fără a crea vreo intrare în set.

Setul este o intrare, nu o rută

Un element dintr-un set este o condiție de potrivire. Ceva trebuie să se uite la el, să decidă că acest pachet începe un flux nou și să aplice politica ce trimite fluxul prin tunel. Pe Linux asta înseamnă de obicei o cale de ieșire capabilă de rutare care poate pune o marcă, o regulă care trimite pachetele marcate într-un tabel dedicat și o rută în acel tabel către dispozitivul WireGuard. Doar apartenența nu instalează nimic din toate acestea.

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

Partenerul aplică o a doua verificare a acoperirii, pe care oamenii o uită. WireGuard criptează un pachet doar pentru un partener ale cărui adrese permise includ destinația, așa că o rută de politică în interfață nu este suficientă când lista partenerului exclude acel prefix. Țineți lista sub controlul proprietarului rutării în loc să vă bazați pe ce creare de rute face din întâmplare managerul.

Mărci, tabele și acoperirea partenerului

Mărcile sunt un spațiu de nume partajat, așa că și valoarea, și masca trebuie convenite cu orice altceva le folosește. O regulă care trimite trafic marcat într-un tabel dedicat are nevoie de un rezultat definit când tabelul nu are nicio rută potrivită, pentru că o căutare fără răspuns poate continua la regula următoare și scoate pachetul pe interfața fizică. O rută implicită blackhole în tabelul dedicat transformă evadarea aceea tăcută într-o aruncare vizibilă. Ceea ce proiectul încă nu poate face este să se închidă la eșec pentru o destinație care nu a intrat niciodată în set.

Pachetele exterioare ale tunelului însuși trebuie să scape de clasificator. Instrumentele WireGuard oferă o marcă de socket exact în acest scop, iar folosirea ei împiedică encapsularea să fie rutată înapoi în interfața pe care o construiește.

Testați fiecare durată de viață separat

Trei depozite îmbătrânesc după trei calendare: cache-ul resolverului, elementele setului și conexiunea urmărită. Testați-le în această ordine și urmăriți dacă fiecare se mișcă atunci când trebuie. Comenzile de mai jos citesc resolverul, setul, tabelul conexiunilor și regulile de politică fără a schimba nimic.

dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show

O căutare proaspătă care adaugă un element dovedește că alimentarea funcționează, în timp ce un element vechi care supraviețuiește răspunsului său este o nepotrivire de durată de viață ce merită notată. O conexiune nouă în tabelul conexiunilor cu marca așteptată arată că clasificatorul a rulat, iar o conexiune veche care își păstrează marca originală este comportament corect, nu o eroare. Lista de reguli răspunde dacă căutarea politicii există, ceea ce este o întrebare diferită de dacă s-a potrivit. Citiți cele patru ieșiri în această ordine și predarea care eșuează se trădează singură.

Când cerința este ca un anumit nume să folosească mereu o singură cale, un set alimentat din DNS nu o poate demonstra, pentru că adresele partajate poartă și alte nume. Un proxy sau un mecanism la nivel de aplicație este instrumentul pentru acea garanție.