Niyə marşrutlaşdırıcının öz DNS-i VPN tunelini yan keçir?

Müştəri sorğuları tuneldən keçir, marşrutlaşdırıcının öz sorğuları isə WAN ilə çıxır və onlardan birini idarə edən qoruyucu divar qaydası digərinə heç bir təsir göstərmir. Səbəb xəta deyil: yönləndirilmiş sorğu ilə marşrutlaşdırıcının özünün yaratdığı sorğu iki ayrı axındır və hər biri konfiqurasiyanın fərqli hissəsi ilə uyğunlaşdırılır. Yalnız müştəri yarısını tutmaq, ikinci yarının heç vaxt istifadə etmədiyi yol haqqında arxayın cavab verir. Düzəliş marşrutlaşdırıcının həlledicisini qəsdən yönəltmək, sonra iki yolu ayrı-ayrılıqda sınamaqdır.

Paket tutması əslində hansı axına aiddir

Bir sorğu iki mübadiləni əhatə edir. LAN müştərisi marşrutlaşdırıcının həlledicisinə sorğu göndərir və bu sorğu LAN interfeysinə yönləndirilmiş trafik kimi gəlir, ona görə yönləndirilmiş paketlər üçün yazılmış siyasət marşrutu və ya NAT qaydası ona uyğun gələ bilər. Sonra marşrutlaşdırıcı keşdən cavab verir və ya keşdə olmadıqda yuxarı axın serverinə öz sorğusunu açır.

Bu ikinci sorğunun mənbəyi marşrutlaşdırıcının özü, təyinatı da özüdür və platforma onun yolunu fərqli konfiqurasiya blokundan seçir. Hər iki mübadilə eyni adı daşıyır və heç biri digərinin surəti deyil. Buna görə LAN tərəfində götürülmüş tutma müştəri paketinin hara getdiyini sübut edir və çıxan paket haqqında heç nə demir.

Praktik yoxlama hər iki tərəfi eyni vaxtda izləməkdir. Marşrutlaşdırıcıda həlledici soketini siyahıya alın, ondan lokal sorğu verin və WAN interfeysini tutun:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Soket siyahısı loopback və ya LAN ünvanına bağlanmış dinləyici göstərirsə, marşrutlaşdırıcı başqa hosta yönləndirmək əvəzinə lokal cavab verir. Sonra tutma nəticədə yaranan yuxarı axın sorğusunun tunel interfeysindən, yoxsa WAN-dan çıxdığını göstərir və bu, siyasət marşrutu qaydasının heç vaxt verməyəcəyi cavabdır.

Niyə siyasət marşrutu ikinci sorğunu heç vaxt görmür

Qoruyucu divar qaydaları interfeys, mənbə, təyinat və port üzərində yazılır və qutudan keçən paketlər üçün qiymətləndirilir. Marşrutlaşdırıcının yaratdığı sorğu isə heç bir yerdən keçmir, çünki lokal proses onu birbaşa marşrutlaşdırma cədvəlinə verir. Siyasət marşrutlaşdırması və NAT buna görə yalnız yönləndirilmiş yola aiddir və qayda dəsti tam görünə bildiyi halda marşrutlaşdırıcının DNS-ini tuneldən kənarda qoyur.

Bu fərq hər proqram təminatı yenilənməsindən sonra da qalır, çünki o, funksiyadan deyil, paket yolundan irəli gəlir. Qutunun özü üçün yaratdığı hər şey, istər həlledici sorğuları, istər vaxt sinxronizasiyası, istər yeniləmə yoxlamaları, istərsə də paket güzgülərinə giriş olsun, lokal mənşəlidir və eyni kor nöqtəyə düşür. Elə buna görə də noutbukdan işləyən test marşrutlaşdırıcı haqqında heç nə sübut etmir.

pfSense həlledicisi öz yuxarı axın yolunu harada müəyyən edir

pfSense bu bölgünü görünən edir. Müştəri trafiki VPN şlüzündən siyasət marşrutu ilə keçə bilər, qoruyucu divarın öz trafiki isə LAN qaydaları əvəzinə həlledicinin çıxış parametrini izləyir. Veb interfeysdə həmin parametr Services > DNS Resolver > Outgoing Network Interfaces altında yerləşir və dəyəri həlledicinin yuxarı axın sorğuları üçün istifadə edə biləcəyi interfeyslərin siyahısıdır.

Tunel interfeysini orada, yalnız o interfeysi qeyd etmək marşrutlaşdırıcının öz sorğularını tuneldən keçirən şeydir. Standart vəziyyətdə saxlanılsa, həlledici çıxışı marşrutlaşdırma cədvəlindən seçir və iki WAN-lı və ya VPN hostunda bu çox vaxt WAN olur.

Digər proqram təminatı eyni qərarı fərqli ad altında təqdim edir: mənbə ünvanına bağlanmış yuxarı axın server siyahısı, yalnız yönləndirmə rejimi və ya sənədləşdirilmiş marşrut siyasəti. Axtarılmalı parametr həmişə lokal yaradılan sorğular üçün çıxış və ya mənbə seçən parametrdir. Həlledici konfiqurasiyası arayışı pfSense üçün həmin seçimi sənədləşdirir və dəyişiklikdən əvvəl oxumağa dəyər.

Parametrdən əvvəl nasazlıq davranışını seçin

Tunel düşəndə iki davranış müdafiə oluna bilər: heç nə sızmasın deyə yuxarı axın sorğularını dayandırmaq və ya tanınmış yolda təsdiqlənmiş həllediciyə keçmək. Hər ikisi siyasətdir və heç biri standart olaraq əldə etdiyiniz şey deyil. İnterfeys siyahısına toxunmadan əvvəl şəbəkənin hansına ehtiyacı olduğunu qərarlaşdırın.

Uğursuzluqda bağlanma müdafiə etmək üçün daha sadədir, lakin tunelin kəsilməsini marşrutlaşdırıcının arxasındakı hər cihaz üçün ad həlli kəsilməsinə çevirir. Ehtiyat keçid ofisi istifadə olunan saxlayır, amma tuneldən kənarda təsadüfən deyil, qəsdən məqbul olmalı olan yuxarı axın mübadiləsi hesabına. Seçimi yazın, çünki VPN-dən kənarda həlledici ünvanı görən növbəti şəxs, qeyd başqa cür deməzsə, bunu sızma kimi oxuyacaq. Elə həmin qeyd sənədləşdirilmiş ehtiyat keçidi növbəti rübün icmalında izahsız tapıntıdan ayıran şeydir.

Qərarı iki hal çətinləşdirir. Şəxsi adlar tunelin çata bildiyi daxili həlledici tələb edə bilər və öz şifrələnmiş DNS-i olan brauzer və ya tətbiq marşrutlaşdırıcını tamamilə yan keçə bilər, ona görə konfiqurasiya etdiyiniz həlledici həmişə verilmiş tətbiqin istifadə etdiyi həlledici deyil.

İki yolu sınayın və nəticələri ayrı saxlayın

Brauzer əsaslı DNS testi dar bir suala cavab verir: həmin brauzer hansı həlledicilərdən istifadə etdi, həmin testin şərtlərində. O, şəbəkədəki cihazları siyahıya almır və marşrutlaşdırıcının özü üçün yaratdığı sorğunu görə bilmir. Onun nəticəsinə audit kimi deyil, bir məlumat nöqtəsi kimi baxın.

LAN müştərisindən marşrutlaşdırıcıdan əvvəl açıq ad, sonra yalnız daxili zonanızın cavab verməli olduğu şəxsi ad istəyin. Yalnız ikinci sorğuda uğursuzluq tunelə deyil, ad yönləndirməsinə işarə edir:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Sonra tuneli endirin və hər iki sorğunu təkrarlayın. Rədd edilən cavablar həlledicinin uğursuzluqda bağlandığını bildirir; uğurlu cavab ehtiyat həllediciyə və onun istifadə etdiyi yola işarə edir. Bunu yazdığınız qeydlə və həmin dəqiqədə WAN interfeysində götürülmüş tutma ilə müqayisə edin.

Müşahidələri qeyddə ayrı saxlayın: müştəri ilə marşrutlaşdırıcı arasındakı mübadilə, marşrutlaşdırıcı ilə yuxarı axın arasındakı mübadilə və ikincisini həll edən konfiqurasiya. Sonrakı marşrut dəyişikliyi həmin ikinci mübadiləni xəbərdarlıq olmadan işə salacaq. VPN son nöqtəsindən başqa yerdən gələn cavab özlüyündə sızma deyil; o, yalnız konfiqurasiya həmin yolu təsadüfən seçdikdə sızmaya çevrilir.