Miért lépnek ki a dnsmasq lekérdezések a VPN-ből DNS-átirányítás után

A LAN-ügyfél helyesen éri el a VPN-jét, a DNS-lekérdezései mégis a rossz felső linken jelennek meg. Ez nem szivárgás a szokásos értelemben; ez akkor történik, amikor a router abbahagyja a lekérdezés továbbítását, és maga válaszol rá. Az elfogás átírja a célt egy helyi socketre, majd az oldó egy második, kapcsolódás nélküli beszélgetést nyit a saját forráscímével és a saját útválasztási döntésével. Az ügyfélfolyamra tett jelölések az első beszélgetést írják le, és semmit a másodikról.

A jelölés nem utazik a lekérdezéssel

A csomagjelölések egy conntrack bejegyzésen és a repülő csomagon élnek. A REDIRECT szabály véget vet ennek a repülésnek: a hasznos teher átadódik egy helyi socketnek, és az eredeti bejegyzés elvégezte a dolgát. Ami ezután elhagyja a routert, az az oldó folyamata által létrehozott friss socket, forrása pedig maga a router címe.

Ezért a LAN-ügyfél címére kulcsolt házirend-útvonal soha nem egyezik az upstream lekérdezéssel. Az új socket a dnsmasq-hoz tartozik, nem az ügyfélhez, és a kernel a router saját forgalmára értékeli az útvonalat. A forrásszabályok, az interfészszabályok és a jelölésszabályok mind más tuple-t látnak. A jelölés továbbterjedésének feltételezése a leggyakoribb hiba ebben a beállításban, és az ügyféloldali rögzítésben láthatatlan.

A két beszélgetés mégis osztozik egy néven és egy időzítésen, és ez az, amitől egy folyamnak látszanak, amikor átfutja a rögzítést.

Ahol a továbbítás helyi feloldássá válik

Kezdje azzal, hogy megállapítja, az 53-as port átirányításra kerül-e, másik gazdagépre fordul-e, vagy érintetlen marad, mert a három eset eltérően viselkedik. A helyi portra irányítás véget vet a továbbításnak, míg a másik gépre fordítás mozgásban tartja a csomagot, és értelmessé teszi az ügyfél tuple-jét.

Nézze meg mindkét protokollt. Az UDP-n és TCP-n elérhető oldó mindkettőn tesztelve lesz, és a csak UDP-t lefedő szabálykészlet csendes lyukat hagy a nagy válaszoknak. A router saját konfigurációkezelője által előállított szabályok is számítanak, és az előállított fájl szerkesztése általában veszít a következő újratöltéssel szemben.

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'

Ezek a kimenetek sorrendben három kérdésre válaszolnak: mi írja át a lekérdezést, mi fogadja be, és melyik folyamat birtokolja a figyelő socketet. Amint a tulajdonos ismert, az upstream házirendnek van hol élnie.

Adjon az oldónak saját kimeneti házirendet

A tartományhoz kötött upstream a legtisztább eszköz, amikor csak néhány névnek kell az alagút. A dnsmasq elfogad egy tartományhoz korlátozott server sort, opcionális interfésszel vagy forráscímmel, amely a választott eszközből kivezeti a lekérdezést. Ez az irányítás az, amitől a második beszélgetés követi a VPN-t.

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

A fenti tartomány, cím és interfész helyőrzők a saját értékeinek. A tartományválasztás és a kimenet vezérlése külön döntés marad: az útvonalnak léteznie kell, a forráscímet engedélyeznie kell az upstream oldónak, és a tűzfalnak engedélyeznie kell a választ. Az önmagában vett interfészirányítás nem fail-closed, mert egy eltűnt alagút hagyjathatja az oldót egy másik útra zuhanni. Tartsa a nyilvános tartalékot távol minden olyan névtértől, amelynek magánnak kell maradnia.

Tegye a sort abba a konfigurációtulajdonosba, amelyet a router támogat, ne előállított fájlba, különben a következő újratöltés törli a javítást.

Amit a megosztott gyorsítótár nem tud megőrizni

Egy továbbító egy gyorsítótárral szolgál ki minden LAN-ügyfelet, és ez összeomlaszt egy különbségtételt, amelyre egyes hálózatoknak szüksége van. Ha két ügyfélnek ugyanazt a nevet másképp kell feloldania, a megosztott socketnek nincs módja visszanyerni, melyik ügyfél kérdezett. Az ügyfélenkénti házirendnek külön oldópéldányokban vagy az identitást megőrző továbbítási funkcióban kell élnie.

A gyorsítótárazott válasz sem bizonyíték az új útvonalról. A válasz érkezhet a memóriából, miközben az upstream útvonal törött marad.

Az 53-as port szabályai semmit sem mondanak azokról az alkalmazásokról, amelyek DNS-t beszélnek HTTPS-en vagy TLS-en. Ezek a lekérdezések soha nem érik el az átirányítást, ezért a csak az 53-as portra épített házirend a forgalom egy részhalmazát írja le és részhalmazként kell dokumentálni.

A második beszélgetést ellenőrizze, ne az elsőt

Teszteljen egy Ön által irányított névvel, és figyelje mindkét oldalt. Az ügyféloldali rögzítés bizonyítja, hogy a lekérdezés elhagyta a LAN-t; csak a router oldala bizonyítja, hova ment tovább.

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

Minden kísérlet előtt ürítse a gyorsítótárat, mert a meleg válasz elrejti a törött upstreamet. Ismételje TCP-n, majd ismételje lekapcsolt alagúttal, hogy lássa, mit tesz az oldó, amikor az előnyben részesített útja eltűnt. Ez a legutóbbi viselkedés dönti el, hogy a tervezés fail-closed-e vagy csupán szerencsés.