Чаму запыты dnsmasq выходзяць за межы VPN пасля перанакіравання DNS

LAN-кліент правільна дасягае свайго VPN, а яго запыты DNS усё адно з’яўляюцца на няправільным узыходзячым канале. Гэта не ўцечка ў звычайным сэнсе; гэта тое, што адбываецца, калі роўтар перастае перасылаць запыт і адказвае на яго сам. Перахоп перапісвае прызначэнне на лакальны сокет, і затым рэзалвер адкрывае другую, незвязаную размову са сваім уласным адрасам крыніцы і сваім уласным рашэннем аб маршруце. Меткі, ужытыя да патоку кліента, апісваюць першую размову і зусім нічога пра другую.

Метка не падарожнічае разам з запытам

Меткі пакетаў жывуць у запісе conntrack і ў пакеце ў палёце. Правіла REDIRECT спыняе гэты палёт: карысная нагрузка перадаецца лакальнаму сокету, і арыгінальны запіс зрабіў сваю справу. Тое, што пасля пакідае роўтар, — гэта новы сокет, створаны працэсам рэзалвера, з адрасам самога роўтара ў якасці крыніцы.

Вось чаму маршрут палітыкі, прывязаны да адраса LAN-кліента, ніколі не супадае з узыходзячым запытам. Новы сокет належыць dnsmasq, а не кліенту, і ядро ацэньвае маршрут для ўласнага трафіку роўтара. Правілы крыніцы, правілы інтэрфейса і правілы метак бачаць розны набор. Здагадка, што метка распаўсюджваецца, — самая распаўсюджаная памылка ў гэтай канфігурацыі, і яна нябачная ў захопе на баку кліента.

Дзве размовы сапраўды маюць агульнае імя і агульны час, і менавіта гэта робіць іх падобнымі на адзін паток, калі хутка праглядаеш захоп.

Дзе перасылка ператвараецца ў лакальнае развязанне

Пачніце з высвятлення, ці порт 53 перанакіраваны, ці пераўтвораны на іншы хост, ці пакінуты без змен, бо тры выпадкі паводзяць сябе па-рознаму. Перанакіраванне на лакальны порт спыняе перасылку, а пераўтварэнне на іншую машыну трымае пакет у руху і захоўвае набор кліента асэнсаваным.

Глядзіце на абодва пратаколы. Рэзалвер, даступны праз UDP і TCP, будзе правераны праз абодва, і набор правілаў, які ахоплівае толькі UDP, пакідае ціхую дзірку для вялікіх адказаў. Правілы, згенераваныя ўласным менеджэрам канфігурацыі роўтара, таксама лічацца, а рэдагаванне згенераванага файла звычайна прайграе наступнай перазагрузцы.

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'

Гэтыя вынікі адказваюць на тры пытанні па чарзе: што перапісвае запыт, што яго атрымлівае і які працэс валодае слухаючым сокетам. Як толькі ўладальнік вядомы, палітыка верхняга ўзроўню мае дзе жыць.

Дайце рэзалверу ўласную палітыку выхаду

Верхні ўзровень для канкрэтнага дамена — найчысцейшы інструмент, калі тунэль патрэбны толькі некаторым імёнам. dnsmasq прымае радок server, абмежаваны даменам, з неабавязковым інтэрфейсам або адрасам крыніцы, які вядзе запыт з выбранай прылады. Менавіта гэтае кіраванне прымушае другую размову ісці за VPN.

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

Дамен, адрас і інтэрфейс вышэй — гэта запаўняльнікі для вашых уласных значэнняў. Выбар дамена і кантроль выхаду застаюцца асобнымі рашэннямі: маршрут павінен існаваць, адрас крыніцы павінен быць дазволены верхнім рэзалверам, і файрвол павінен дазволіць адказ. Адно кіраванне інтэрфейсам не з’яўляецца fail-closed, бо зніклы тунэль можа пакінуць рэзалвер вяртацца на іншы шлях. Трымайце любы публічны запасны шлях далей ад прасторы імёнаў, якая павінна застацца прыватнай.

Змясціце радок ва ўладальніка канфігурацыі, якога падтрымлівае роўтар, а не ў згенераваны файл, інакш наступная перазагрузка сцірае выпраўленне.

Што агульны кэш не можа захаваць

Адзін перасылальнік з адным кэшам абслугоўвае кожнага LAN-кліента, і гэта знішчае адрозненне, якое патрэбна некаторым сеткам. Калі два кліенты павінны развязаць адно імя па-рознаму, агульны сокет не мае спосабу аднавіць, які кліент запытаў. Палітыка для кожнага кліента павінна жыць у асобных экзэмплярах рэзалвера або ў функцыі перасылкі, якая захоўвае ідэнтычнасць.

Кэшаваны адказ таксама не з’яўляецца доказам пра новы шлях. Адказ можа прыйсці з памяці, пакуль узыходзячы маршрут застаецца зламаным.

Правілы порта 53 нічога не кажуць пра праграмы, якія гавораць DNS праз HTTPS ці праз TLS. Гэтыя запыты ніколі не дасягаюць перанакіравання, таму палітыка, пабудаваная толькі на порце 53, апісвае падмноства трафіку і павінна быць задокументаваная як падмноства.

Правярайце другую размову, а не першую

Праверце на адным імені, якое вы кантралюеце, і назірайце за абодвума бакамі. Захоп на баку кліента даказвае, што запыт пакінуў LAN; толькі бок роўтара даказвае, куды ён пайшоў далей.

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

Ачысціце кэш перад кожнай спробай, бо цёплы адказ хавае зламаны верхні ўзровень. Паўтарыце праз TCP, затым паўтарыце з выключаным тунэлем, каб убачыць, што робіць рэзалвер, калі яго пераважны шлях знік. Менавіта апошнія паводзіны вырашаюць, ці дызайн fail-closed, ці проста шанцуе.