Miks dnsmasq päringud pärast DNS ümbersuunamist VPN-ist välja lähevad

LAN-i klient jõuab oma VPN-i korrektselt, kuid tema DNS-päringud ilmuvad ikkagi valele ülesvoolu liinile. See ei ole tavapärases mõttes leke; see on see, mis juhtub, kui ruuter lõpetab päringu edastamise ja vastab ise. Vaheltulastamine kirjutab sihtkoha ümber kohalikuks soketiks ja seejärel avab resolver teise, mitteseotud vestluse oma allikaaadressi ja oma marsruudiotusega. Kliendi voolule rakendatud märgised kirjeldavad esimest vestlust ja teise kohta mitte midagi.

Märgis ei reisi päringuga kaasas

Paketi märgised elavad conntrack-kirjel ja lennu peal oleval paketil. REDIRECT-reegel lõpetab selle lennu: kasulik koormus antakse üle kohalikule soketile ja algne kirje on oma töö teinud. See, mis pärast ruuterist lahkub, on värske soket, mille on loonud resolveri protsess, allikaks ruuteri enda aadress.

Seepärast ei ühti LAN-i kliendi aadressile seatud poliitikamarsruut kunagi ülesvoolu päringuga. Uus soket kuulub pigem dnsmasqile kui kliendile ja tuum hindab marsruuti ruuteri enda liikluse jaoks. Allika reeglid, liidese reeglid ja märgiste reeglid näevad kõik teistsugust ennikut. Eeldus, et märgis levib, on selles seadistuses kõige tavalisem viga ja see on kliendipoolses salvestuses nähtamatu.

Need kaks vestlust jagavad tõesti nime ja ajastust ning just see paneb need ühe vooluna paistma, kui salvestust kiiresti sirvida.

Kus edastamine muutub kohalikuks lahendamiseks

Alustage sellest, et teha kindlaks, kas port 53 suunatakse ümber, tõlgitakse teisele hostile või jäetakse puutumata, sest need kolm juhtumit käituvad erinevalt. Kohalikule pordile suunamine lõpetab edastamise, samas kui teisele masinale tõlkimine hoiab paketi liikumises ja hoiab kliendi enniku mõtestatuna.

Vaadake mõlemat protokolli. UDP ja TCP kaudu kättesaadav resolverit testitakse mõlema kaudu ning ainult UDP-d kattev reeglistik jätab suurte vastuste jaoks vaikse augu. Ruuteri enda konfiguratsioonihalduri loodud reeglid loevad samuti ja loodud faili muutmine kaotab tavaliselt järgmisele uuestilaadimisele.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Need väljundid vastavad kolmele küsimusele järjekorras: mis päringu ümber kirjutab, mis selle vastu võtab ja milline protsess omab kuulavat soketit. Kui omanik on teada, on ülesvoolu poliitikal koht, kus elada.

Andke resolverile oma väljumispoliitika

Domeenipõhine ülesvool on puhtaim tööriist, kui tunnelit vajavad ainult mõned nimed. dnsmasq võtab vastu domeeniga piiratud server-rea, valikulise liidese või allikaaadressiga, mis juhib päringu valitud seadmest välja. Just see juhtimine paneb teise vestluse VPN-i järgima.

server=/corp.example/10.30.0.53@tun_work
log-queries

Ülaltoodud domeen, aadress ja liides on teie enda väärtuste kohahoidjad. Domeeni valik ja väljundi kontroll jäävad eraldi otsusteks: marsruut peab olemas olema, allikaaadress peab olema ülesvoolu resolveri poolt lubatud ja tulemüür peab vastuse lubama. Ainult liidese juhtimine ei ole fail-closed, sest kadunud tunnel võib jätta resolveri teisele teele tagasi langema. Hoidke igasugune avalik varuvariant eemal nimeruumist, mis peab jääma privaatseks.

Pange rida selle konfiguratsiooniomaniku juurde, mida ruuter toetab, mitte loodud faili, muidu järgmine uuestilaadimine kustutab paranduse.

Mida jagatud vahemälu ei suuda säilitada

Üks edastaja ühe vahemäluga teenindab iga LAN-i klienti ja see lammutab eristuse, mida mõned võrgud vajavad. Kui kaks klienti peavad sama nime erinevalt lahendama, ei ole jagatud soketil võimalust taastada, milline klient küsis. Kliendipõhine poliitika peab elama eraldi resolveri eksemplarides või edastustunnuses, mis hoiab identiteedi.

Vahemällu salvestatud vastus ei ole samuti tõendus uue tee kohta. Vastus võib tulla mälust, samal ajal kui ülesvoolu marsruut jääb katki.

Pordi 53 reeglid ei ütle midagi rakenduste kohta, mis räägivad DNS-i HTTPS-i või TLS-i kaudu. Need päringud ei jõua kunagi ümbersuunamiseni, seega ainult pordile 53 ehitatud poliitika kirjeldab liikluse alamhulka ja seda tuleks dokumenteerida alamhulgana.

Kontrollige teist vestlust, mitte esimest

Testige ühe nimega, mida te kontrollite, ja jälgige mõlemat poolt. Kliendipoolne salvestus tõestab, et päring lahkus LAN-ist; ainult ruuteripool tõestab, kuhu see edasi läks.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Tühjendage vahemälu enne iga katset, sest soe vastus varjab katkist ülesvoolu. Korrake TCP kaudu, seejärel korrake tunneliga maas, et näha, mida resolver teeb, kui tema eelistatud tee on kadunud. See viimane käitumine otsustab, kas disain on fail-closed või lihtsalt õnnelik.