Brauzer tuneldən kənarlaşdırılıb, ümumi IP səhifəsi onun trafikinin ev bağlantısı ilə çıxdığını təsdiqləyir, amma daxili wiki hələ də açılmır. Ad həlli başqa yerə getdi və o başqa yer adətən VPN-in təyin etdiyi həlledicidir. Məlumat yolu və həlledici yolu əksər bölünmüş tunel dizaynlarında ayrı qərarlardır. Kənarlaşdırmanı pozulmuş adlandırmazdan əvvəl brauzerin hansını faktiki istifadə etdiyini yoxlayın.

Məlumat yolu və həlledici yolu ayrılır

Kənarlaşdırma tətbiqin paketlərini tuneldən çıxarır, bu da məlumat yolunda marşrutlaşdırma və güvənduvarı qərarıdır. Ad həlli fərqli bir axtarışdır: bir proses sistemin həlledicisindən soruşur, o həlledici də sualın hansı serverə çatacağını qərarlaşdırır.

İkisi də qəsdən və fərqli ola bilər. İş yerləşdirməsi daxili ad məkanlarını korporativ həlledicidə saxlayıb seçilmiş ümumi gəzintini tuneldən kənara göndərə bilər, məhz ona görə ki daxili adlar başqa yerdə həll olunmur. Qarışıq hal tərsidir: ümumi sayt uğursuz olur, çünki brauzer yerləşdirmənin gözlədiyi həlledicidən heç soruşmayıb. Marşrutu və həlledici ayrı-ayrı qeyd edin, mübahisənin yarısı yox olur.

Sualı hansı prosesin verdiyini tapın

Brauzer sistem həlledicisindən, öz şifrəli DNS xidmətindən və ya əməliyyat sisteminin hər şəbəkə üçün təyin etdiyi həlledicidən istifadə edə bilər. Birincisi platforma siyasətinə uyğundur, ikincisi həmin siyasəti tamamilə yan keçir, üçüncüsü isə sorğunun hansı keçidə yönləndirildiyindən asılıdır.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Testdən əvvəl effektiv konfiqurasiyanı oxuyun: hansı keçidlər DNS serverləri daşıyır, hansı ad məkanlarını iddia edir və hər ad üzrə siyasətin standartı üstələyib-üstələmədiyinə baxın. Linuxda bölünmüş DNS marşrut domenlərindən istifadə edir; Windowsda ad həlli siyasəti cədvəli ad məkanları üçün eyni işi görür. Heç biri sızma testi səhifəsindən görünmür.

Hansı həlledici hansı adı görməlidir

Nəyisə dəyişməzdən əvvəl nəzərdə tutulan uyğunluğu yazın: daxili adlar korporativ həllediciyə, ümumi adlar siyasətin icazə verdiyi xidmətə, istisnalar isə sahibi ilə birlikdə. Bu siyahı olmadan hər sızma testi etiketi heç kimin həll edə bilmədiyi siyasət mübahisəsinə çevrilir.

Sonra brauzerin öz ayarını yoxlayın, çünki brauzerdə şifrəli DNS əməliyyat sistemi sorğunu almadan əvvəl tətbiq olunur. Onu kaptiv portalı yan keçmək üçün aktivləşdirən istifadəçi yerləşdirmənin seçdiyi həlledicini səssizcə üstələyib. Bu, sızma deyil, konfiqurasiya qərarıdır və blok siyahısından çox qərar almağa layiqdir.

Bir test etiketini yaşıl etmək üçün hər DNS sahəsini yenidən yazmayın. Etiket bir prosesin bir anda etdiyi bir sorğunu təsvir edir.

Sorğunu və bağlantını ayrı-ayrı yoxlayın

İki yolu ayrı-ayrı yoxlayın. Bağlantı testi məlumat marşrutunu, həlledici testi isə adı kimin aldığını göstərir.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Həlledicidən də açıq şəkildə soruşun ki, uğursuzluq yolun deyil, serverin üstünə yazılsın. Sonra brauzeri yenidən başladın və təkrarlayın, çünki tətbiqlər mənfi cavabları keşləyir və köhnə uğursuzluq davamlı görünür.

Təsdiqlənmiş dəyişiklikdən sonra məlumat marşrutunu və həlledici alıcısını iki ayrı sətir kimi tarixlə birlikdə qeyd edin. Davranış növbəti yenidən qoşulmada qayıdırsa, onu təmin edən profil düzəldilməlidir, brauzer deyil.

Əlaqəli məqalələr