Kodėl dnsmasq užklausos išeina iš VPN po DNS peradresavimo

LAN klientas tinkamai pasiekia savo VPN, o jo DNS užklausos vis tiek rodomos netinkamoje aukštupio linijoje. Tai ne nutekėjimas įprasta prasme; tai vyksta, kai maršrutizatorius nustoja persiųsti užklausą ir pats į ją atsako. Perėmimas perrašo paskirties adresą į vietinį lizdą, o tada sprendėjas atidaro antrą, nesusijusį pokalbį su savo paties šaltinio adresu ir savo paties maršrutizavimo sprendimu. Kliento srautui priskirtos žymės apibūdina pirmąjį pokalbį ir visiškai nieko apie antrąjį.

Žymė nekeliauja kartu su užklausa

Paketų žymės gyvena conntrack įraše ir skriejančiame pakete. REDIRECT taisyklė užbaigia tą skrydį: naudingoji apkrova perduodama vietiniam lizdui, o pradinis įrašas jau atliko savo darbą. Tai, kas po to išeina iš maršrutizatoriaus, yra naujas lizdas, kurį sukūrė sprendėjo procesas, o šaltinis yra paties maršrutizatoriaus adresas.

Štai kodėl politikos maršrutas, susietas su LAN kliento adresu, niekada nesutampa su aukštupio užklausa. Naujasis lizdas priklauso dnsmasq, o ne klientui, ir branduolys maršrutą vertina paties maršrutizatoriaus srautui. Šaltinio taisyklės, sąsajos taisyklės ir žymių taisyklės visos mato kitokią eilutę. Prielaida, kad žymė persiduoda, yra dažniausia šios konfigūracijos klaida, ir ji nematoma kliento pusėje daromame įraše.

Du pokalbiai iš tiesų dalijasi vardu ir laiku, ir būtent tai leidžia jiems atrodyti kaip vienam srautui, kai greitai peržvelgi įrašą.

Kur persiuntimas virsta vietiniu sprendimu

Pradėkite nuo išsiaiškinimo, ar 53 prievadas peradresuojamas, verčiamas į kitą mazgą, ar paliekamas ramybėje, nes trys atvejai elgiasi skirtingai. Peradresavimas į vietinį prievadą užbaigia persiuntimą, o vertimas į kitą mašiną palaiko paketą judėjime ir išlaiko kliento eilutę prasmingą.

Pažiūrėkite į abu protokolus. Sprendėjas, pasiekiamas per UDP ir TCP, bus tikrinamas abiem, o taisyklių rinkinys, apimantis tik UDP, palieka tylią skylę dideliems atsakymams. Taisyklės, kurias generuoja paties maršrutizatoriaus konfigūracijos tvarkyklė, taip pat skaičiuojamos, o sugeneruoto failo redagavimas paprastai pralaimi prieš kitą perkrovimą.

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'

Tie išvedimai iš eilės atsako į tris klausimus: kas perrašo užklausą, kas ją priima ir kuris procesas valdo klausantį lizdą. Kai savininkas žinomas, aukštupio politika turi kur gyventi.

Duokite sprendėjui jo paties išėjimo politiką

Domenui būdinga aukštupio kryptis yra švariausias įrankis, kai tunelio reikia tik kai kuriems vardams. dnsmasq priima server eilutę, apribotą domenu, su pasirenkama sąsaja ar šaltinio adresu, kuris nukreipia užklausą iš pasirinkto įrenginio. Būtent tas nukreipimas ir priverčia antrąjį pokalbį sekti VPN.

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

Aukščiau nurodytas domenas, adresas ir sąsaja yra vietos žymekliai jūsų pačių reikšmėms. Domeno pasirinkimas ir išėjimo valdymas lieka atskiri sprendimai: maršrutas turi egzistuoti, šaltinio adresą turi leisti aukštupio sprendėjas, o ugniasienė turi leisti atsakymą. Vien sąsajos nukreipimas nėra fail-closed, nes dingęs tunelis gali palikti sprendėją krentantį į kitą kelią. Laikykite bet kokį viešą atsarginį kelią toli nuo vardų erdvės, kuri turi likti privati.

Įdėkite eilutę į tą konfigūracijos savininką, kurį palaiko maršrutizatorius, o ne į sugeneruotą failą, kitaip kitas perkrovimas ištrins pataisą.

Ko bendra talpykla negali išsaugoti

Vienas persiuntėjas su viena talpykla aptarnauja kiekvieną LAN klientą, ir tai sugriauna skirtumą, kurio kai kuriems tinklams reikia. Jei du klientai turi skirtingai išspręsti tą patį vardą, bendras lizdas neturi būdo atkurti, kuris klientas klausė. Politika kiekvienam klientui turi gyventi atskirose sprendėjo instancijose arba persiuntimo funkcijoje, kuri išlaiko tapatybę.

Talpykloje laikomas atsakymas taip pat nėra naujo kelio įrodymas. Atsakymas gali ateiti iš atminties, kol aukštupio maršrutas lieka sugedęs.

53 prievado taisyklės nieko nesako apie programas, kurios kalba DNS per HTTPS arba per TLS. Tos užklausos niekada nepasiekia peradresavimo, todėl politika, pastatyta vien tik ant 53 prievado, apibūdina eismo poaibį ir turėtų būti dokumentuojama kaip poaibis.

Patikrinkite antrąjį pokalbį, o ne pirmąjį

Išbandykite su vienu vardu, kurį kontroliuojate, ir stebėkite abi puses. Kliento pusėje daromas įrašas įrodo, kad užklausa paliko LAN; tik maršrutizatoriaus pusė įrodo, kur ji nuėjo toliau.

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

Išvalykite talpyklą prieš kiekvieną bandymą, nes šiltas atsakymas paslepia sugedusį aukštupį. Pakartokite per TCP, tada pakartokite su išjungtu tuneliu, kad pamatytumėte, ką sprendėjas daro, kai jo pageidaujamas kelias dingęs. Būtent tas paskutinis elgesys nulemia, ar sprendimas yra fail-closed, ar tiesiog sėkmingas.