DNS yönləndirməsindən sonra dnsmasq sorğuları niyə VPN-dən kənara çıxır

LAN müştərisi öz VPN-inə düzgün çatır, lakin DNS sorğuları hələ də yanlış yuxarı kanalda görünür. Bu, adi mənada sızma deyil; router sorğunu ötürməyi dayandırıb ona özü cavab verdikdə baş verən şeydir. Müdaxilə təyinatı yerli soketə yenidən yazır, sonra resolver öz mənbə ünvanı və öz marşrut qərarı ilə ikinci, əlaqəsiz söhbət açır. Müştəri axınına tətbiq edilən işarələr birinci söhbəti təsvir edir və ikinci barədə heç nə demir.

İşarə sorğu ilə birlikdə getmir

Paket işarələri conntrack qeydində və uçuşdakı paketdə yaşayır. REDIRECT qaydası həmin uçuşu bitirir: yük yerli soketə verilir və orijinal qeyd öz işini görmüş olur. Bundan sonra routerdən çıxan şey resolver prosesinin yaratdığı, mənbəyi routerin öz ünvanı olan təzə soketdir.

Buna görə LAN müştərisinin ünvanına bağlanmış siyasət marşrutu yuxarı axın sorğusuna heç vaxt uyğun gəlmir. Yeni soket müştəriyə deyil, dnsmasq-a aiddir və nüvə marşrutu routerin öz trafiki üçün qiymətləndirir. Mənbə qaydaları, interfeys qaydaları və işarə qaydaları hamısı fərqli bir dəst görür. İşarənin ötürüldüyünü fərz etmək bu qurmada ən çox yayılmış səhvdir və müştəri tərəfindəki tutmada görünmür.

İki söhbət həqiqətən bir ad və bir vaxt paylaşır və tutmaya qısaca baxanda onları bir axın kimi göstərən də elə budur.

Ötürmə harada yerli həllə çevrilir

Əvvəlcə 53-cü portun yönləndirildiyini, başqa hosta çevrildiyini yoxsa toxunulmadan qaldığını müəyyən edin, çünki üç hal fərqli davranır. Yerli porta yönləndirmə ötürməni bitirir, başqa maşına çevirmə isə paketi hərəkətdə saxlayır və müştərinin dəstini mənalı saxlayır.

Hər iki protokola baxın. UDP və TCP üzərindən əlçatan resolver hər ikisi üzərində sınanacaq və yalnız UDP-ni əhatə edən qayda dəsti böyük cavablar üçün səssiz bir deşik qoyur. Routerin öz konfiqurasiya menecerinin yaratdığı qaydalar da sayılır və yaradılmış faylı redaktə etmək adətən növbəti yenidən yükləməyə uduzur.

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'

Bu çıxışlar üç suala sıra ilə cavab verir: sorğunu nə yenidən yazır, onu nə qəbul edir və dinləyən soket hansı prosesə aiddir. Sahib bilindikdən sonra yuxarı axın siyasətinin yaşayacağı bir yer olur.

Resolverə öz çıxış siyasətini verin

Domenə xas yuxarı axın, yalnız bəzi adlar tunelə ehtiyac duyduqda ən təmiz vasitədir. dnsmasq domenlə məhdudlaşan server sətrini qəbul edir, istəyə bağlı interfeys və ya mənbə ünvanı ilə sorğunu seçilmiş cihazdan çıxarır. İkinci söhbəti VPN-ə tabe edən də elə bu yönləndirmədir.

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

Yuxarıdakı domen, ünvan və interfeys öz dəyərləriniz üçün yer tutucudur. Domen seçimi və çıxış nəzarəti ayrı qərarlar olaraq qalır: marşrut mövcud olmalı, mənbə ünvanına yuxarı axın resolveri icazə verməli və firewall cavaba icazə verməlidir. Təkcə interfeys yönləndirməsi fail-closed deyil, çünki yoxa çıxan tunel resolveri başqa yola qaytara bilər. Hər hansı açıq ehtiyat yolu gizli qalmalı olan adlar fəzasından uzaq saxlayın.

Sətri yaradılmış fayla deyil, routerin dəstəklədiyi konfiqurasiya sahibinə qoyun, əks halda növbəti yenidən yükləmə düzəlişi silir.

Paylaşılan keş nəyi qoruya bilməz

Bir keşi olan bir yönləndirici hər LAN müştərisinə xidmət edir və bu, bəzi şəbəkələrin ehtiyac duyduğu fərqi sıfırlayır. İki müştəri eyni adı fərqli həll etməlidirsə, paylaşılan soketin hansı müştərinin soruşduğunu bərpa etmək yolu yoxdur. Müştəri üzrə siyasət ayrı resolver nüsxələrində və ya kimliyi saxlayan ötürmə xüsusiyyətində yaşamalıdır.

Keşlənmiş cavab da yeni yol barədə sübut deyil. Cavab yaddaşdan gələ bilər, yuxarı axın marşrutu isə sınıq qalır.

53-cü port qaydaları DNS-i HTTPS və ya TLS üzərindən danışan tətbiqlər barədə heç nə demir. O sorğular yönləndirməyə heç vaxt çatmır, ona görə yalnız 53-cü porta əsaslanan siyasət trafikin bir alt çoxluğunu təsvir edir və alt çoxluq kimi sənədləşdirilməlidir.

İkinci söhbəti yoxlayın, birincini deyil

Nəzarət etdiyiniz bir adla sınayın və hər iki tərəfə baxın. Müştəri tərəfindəki tutma sorğunun LAN-dan çıxdığını sübut edir; yalnız router tərəfi sonra hara getdiyini sübut edir.

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

Hər cəhddən əvvəl keşi təmizləyin, çünki isti cavab sınıq yuxarı axını gizlədir. TCP üzərindən təkrarlayın, sonra tunel söndürülmüş halda təkrarlayın ki, resolverin üstünlük verdiyi yol yox olduqda nə etdiyini görəsiniz. O son davranış dizaynın fail-closed yoxsa sadəcə bəxti gətirən olduğunu həll edir.