DNS қайта бағытталғаннан кейін dnsmasq сұраулары VPN-нен неге шығып кетеді

LAN клиенті өз VPN-іне дұрыс жетеді, бірақ оның DNS сұраулары әлі де қате жоғары арнада көрінеді. Бұл әдеттегі мағынадағы ағып кету емес; бұл маршрутизатор сұрауды жіберуді тоқтатып, өзі жауап берген кезде болатын нәрсе. Кедергі келтіру межелі мекенжайды жергілікті сокетке қайта жазады, содан кейін шешуші өзінің бастау мекенжайымен және өзінің маршруттау шешімімен екінші, байланыссыз әңгіме ашады. Клиент ағынына қойылған белгілер бірінші әңгімені сипаттайды және екіншісі туралы мүлдем ештеңе айтпайды.

Белгі сұраумен бірге жүрмейді

Пакет белгілері conntrack жазбасында және ұшу үстіндегі пакетте тұрады. REDIRECT ережесі сол ұшуды аяқтайды: пайдалы жүктеме жергілікті сокетке беріледі, ал бастапқы жазба өз ісін бітірді. Осыдан кейін маршрутизатордан шығатын нәрсе — шешуші процесі жасаған жаңа сокет, оның көзі маршрутизатордың өз мекенжайы.

Сондықтан LAN клиентінің мекенжайына байланған саясат маршруты жоғарғы ағын сұрауымен ешқашан сәйкес келмейді. Жаңа сокет клиентке емес, dnsmasq-қа тиесілі, ал ядро маршрутты маршрутизатордың өз трафигі үшін бағалайды. Бастау ережелері, интерфейс ережелері және белгі ережелерінің барлығы басқа tuple көреді. Белгі таралады деп болжау — бұл конфигурациядағы ең жиі қате, және ол клиент жағындағы жазбада көрінбейді.

Екі әңгіме шынымен бір ат пен бір уақытты бөліседі, және жазбаны жылдам шолып қарағанда оларды бір ағындай көрсететін де осы.

Жіберу қай жерде жергілікті шешуге айналады

53-порттың қайта бағытталып жатқанын, басқа хостқа түрлендіріліп жатқанын немесе сол күйінде қалғанын анықтаудан бастаңыз, өйткені үш жағдай әрқалай әрекет етеді. Жергілікті портқа қайта бағыттау жіберуді аяқтайды, ал басқа машинаға түрлендіру пакетті қозғалыста ұстайды және клиенттің tuple-ін мағыналы етіп сақтайды.

Екі протоколды да қараңыз. 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

Жоғарыдағы домен, мекенжай және интерфейс өз мәндеріңіз үшін орынбасарлар. Доменді таңдау және шығысты бақылау бөлек шешімдер болып қалады: маршрут болуы керек, бастау мекенжайына жоғарғы шешуші рұқсат беруі керек және firewall жауапқа рұқсат беруі керек. Тек интерфейспен бағыттау 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 немесе жай ғана сәтті екенін шешеді.