Tor və VPN birləşdirildikdə DNS hara gedir

İki məxfilik aləti işləyir, bir səhifə açılmır və resolver testi brauzerdən kənarda nəyinsə ad aldığını bildirir. Bu, sızma hesabatına çevrilməzdən əvvəl adın hansı mübadilədən gəldiyini müəyyən edin. Tor və VPN quruluşunda ən azı üç fərqli sahibə aid üç fərqli ad sorğusu var və onları baş verdiyi ardıcıllıqla nəzərdən keçirmək hansının səhv davrandığını görməyin ən sürətli yoludur.

Sızma adlandırmazdan əvvəl hər mübadiləni adlandırın

Birinci mübadilə VPN son nöqtəsinin özünü həll edir və hər hansı qoruma mövcud olmadan baş verir. İkincisi Tor Browser üçün təyinatı həll edir; brauzer adı yerli olaraq həll etmək əvəzinə proksiyə ötürə bilər. Üçüncü, yeniləmə yoxlamaları, poçt müştəriləri və əməliyyat sisteminin öz xidmət sorğuları daxil olmaqla, maşındakı hər şeyi əhatə edir. Bunlardan yalnız birincisi digər ikisi iştirak etmədən baş verə bilər.

Bunların hər biri fərqli yol izləyə bilər və brauzerdəki tək bir test yalnız öz sorğusunu müşahidə edir. Bir nəticəni hər üçünün vəziyyəti kimi qəbul etmək qarışıqlığın çoxunun başladığı yerdir.

Nəyisə dəyişməzdən əvvəl hansı adların hansı qata aid olduğunu yazın. Şəxsi təşkilati adlar, ictimai təyinat və tunelin son nöqtəsi eyni tələbi daşımır və onları bir kateqoriya kimi qəbul edən siyasət nəyisə pozacaq.

Başlanğıc sorğusu tuneldən əvvəl baş verir

Host adı ilə konfiqurasiya edilmiş müştəri tuneli açmaq üçün həmin adı həll etməlidir və o anda sorğunu daşıyacaq tunel mövcud deyil. Cari şəbəkədə əməliyyat sisteminin təklif etdiyi hansı resolver varsa, cavab verir; bu, tutulmuş portal, otel resolveri və ya ictimai biri ola bilər. Bu, tuneldə sızma deyil, çünki hələ tunel yoxdur.

Brauzerin təhlükəsiz DNS parametrini dəyişmək də bu sorğuya toxunmur, çünki o, brauzerdən kənarda işləyən və hər hansı səhifə açılmazdan əvvəl başlayan xidmətə aiddir. Son nöqtə adı həll olunmazsa, tuneldaxili heç bir siyasət kömək etməyəcək, çünki nasazlıq konfiqurasiyanın təsvir etdiyi hər şeydən bir mərhələ əvvəl baş verir.

Bu, son nöqtə üçün hərfi ünvandan istifadə etməyin, provayder dəstəkləyirsə, asılılığı artırmaq əvəzinə aradan qaldırdığı yeganə yerdir. Bu həm də ünvanları dəyişən provayderi izləmə imkanını aradan qaldırır, ona görə də mübadilə realdır və kəşf edilməkdənsə qərar verilməlidir.

Brauzer və maşının qalan hissəsi fərqlənir

Tor-un SOCKS interfeysi təyinat host adının proksiyə ötürülməsini dəstəkləyir, yəni həlli uzaq tərəf edir və yerli maşın heç soruşmur. Proksini dəstəkləyən ümumi tətbiq adı əvvəlcə yerli həll edib sonra aldığı ünvana qoşula bilər, bu da istifadəçinin proksidən keçdiyini düşündüyü təyinat üçün yerli sorğu yaradır. Beləliklə, iki tətbiq bir proksi parametrini paylaşarkən fərqli yerlərdə sızma edə bilər. Ortaq proksi ünvanında heç nə hansı davranışın istifadə olunduğunu bildirmir.

Brauzerlər təhlükəsiz DNS aktiv olduqda başqa bir qat əlavə edir, çünki brauzer öz provayderini seçib sistem resolverini tamamilə yan keçə bilər. Tunel müştərisi isə bütün maşın üçün resolveri tuneldən keçirə bilər. Bu iki parametr hər ikisi düzgün ola bilər və yenə də fərqli proqramlar üçün fərqli davranış təsvir edə bilər.

Bir test səhifəsindən ümumiləşdirmək əvəzinə sorğunu yaradan proqramı yoxlayın. Tunel daxilində daşınan sorğu ilə Tor-a heç çatmayan sorğu arasındakı fərq məhz tək bir resolver ünvanının göstərə bilmədiyi fərqdir.

Hər proqramı yoxlayın, sonra niyyətlə müqayisə edin

Müşahidələri ayrı-ayrı aparın: sistemin nədən istifadə edəcəyi, brauzerin nə üçün konfiqurasiya edildiyi və SOCKS bağlantısının ad, yoxsa ünvan daşıdığı. Sonuncusu uzaq və yerli həll arasındakı fərqdir və SOCKS uzantı spesifikasiyası host adının əvvəlcə həll edilməkdənsə necə ötürüldüyünü təsvir edir.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Sonra müşahidə etdiyinizi nəzərdə tutduğunuzla müqayisə edin. Seçdiyiniz resolver tərəfindən tuneldən keçirilərək həll olunan ictimai ad, geri çəkilmə zamanı ictimai resolverə verilən şəxsi adla eyni tapıntı deyil və adətən yalnız ikincisi tədbir tələb edir. Birincisi, hesabatda qeyri-adi görünsə də, dizayn üzrə işləyən konfiqurasiyadır.

Qəbul etdiyiniz istisnaları, o cümlədən qoruna bilməyən başlanğıc sorğusunu qeyd edin. Yazılı istisna dizayn qərarıdır, halbuki sonradan aşkar edilən eyni istisna qüsur kimi görünür. Onu tapan şəxs belə qəbul edəcək və siz iclası bunun niyə belə olmadığını izah etməyə sərf edəcəksiniz.