Tunel işləyir, bəs niyə özəl ad hələ də uğursuz olur?

Bağlantı ilə bağlı hər şey düzgün görünür: tunel işləyir və konsol özəl son nöqtəni göstərir, lakin hər sorğu ad həllində uğursuz olur. Təbii hərəkət tuneli günahlandırmaqdır, halbuki o adətən günahsız çıxır. Sorğu özəl zona haqqında heç nə bilməyən serverə göndərilir. Heç bir marşrut dəyişikliyi bu cavabı dəyişməyəcək, çünki problem kimdən soruşulduğundadır.

Sorğu hansı həllediciyə çatdı?

Tunelə ümumiyyətlə baxmazdan əvvəl hər keçidə bağlı həlledici tapın. Linux hər keçidin serverlərini həlledici status əmri ilə göstərir, macOS isə DNS konfiqurasiya çıxarışında əhatəli həllediciləri göstərir. Cavab hələ də ev marşrutlaşdırıcısından gəlirsə, tunel keçidinə heç vaxt müraciət edilməmişdir.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Burada iki mərhələ qarışdırılır: həlledici ünvanını təkan server və onu aktiv keçidə quraşdıran müştəri. Profil seçimi ehtiva edə, jurnal onun gəldiyini göstərə bilər, halbuki əməliyyat sistemi köhnə serverdən istifadə etməyə davam edir. Jurnalı keçidin bildirdiyi ilə müqayisə edin və keçidə güvənin.

Bulud şəbəkəsinin həqiqətən cavab verdiyi ünvandan istifadə edin

Bulud şəbəkələri özəl adlara adətən diapazonun bazasından iki vahid kənarda yerləşən ehtiyat ünvan vasitəsilə cavab verir, yəni 10.0.0.0 ilə başlayan şəbəkə 10.0.0.2 ünvanında cavab verir. Bəzi provayderlər diapazonu bilmədən işləyən link-local həlledici də yayımlayır və bu, şəbəkə başqası tərəfindən qurulduqda kömək edir. Namizəd ünvanı hər kəsə təqdim etməzdən əvvəl birbaşa sorğulayın. Həlledici olmayan ünvan firewall drop ilə tam eyni görünür, çünki sorğu sadəcə heç vaxt cavab almır.

Birbaşa sorğu şəbəkənin içindən cavab verir, tuneldən keçəndə isə vermirsə, həlledici qaydasındadır və iki nöqtə arasındakı yol deyil. Bu nəticə araşdırmanı müştəri profilinə deyil, marşrutlara, yönləndirməyə və giriş qaydalarına keçirir.

Tunel adlar fəzasını daşımır

Paketlər keçir; adlar keçmir. Hər tərəfə hansı adlar fəzasının digərinə aid olduğu deyilməlidir və bu, zonaya sahib olan şəxsə məxsus ayrı bir obyektdir. Adi forma bir adlar fəzası üçün tunel üzərindən əlçatan həllediciyə yönəldilmiş yönləndirmədir.

Praktikada hər istiqamət öz qaydasına ehtiyac duyur, çünki zonaya sahib olan tərəf sorğunu göndərməli olan tərəfdir. Hər iki istiqamət sorğu mənbəyinin marşrutlaşdırılmasını və icazəsini tələb edir, cavab verən tərəf isə cavabları internetə deyil, tunel vasitəsilə qaytarmalıdır. Yönləndirməni dar saxlayın ki, yalnız özəl adlar fəzası keçiddən asılı olsun. Hər sorğunu onun üzərindən göndərmək kiçik bir asılılığı tunel düşdüyü anda tam kəsintiyə çevirir.

Sərhədləri sıra ilə gəzin

Aktiv keçidə quraşdırılmış həllediciyə, sonra həmin həllediciyə birbaşa sorğuya, sonra eyni sorğuya uzaq tərəfdən və nəhayət eyni adı istifadə edən tətbiqə baxın. Hər addım bir sərhədi təcrid edir, beləliklə uğursuzluq araşdırmanı yenidən başlatmaq əvəzinə hara baxacağınızı deyir. Tətbiq uğursuz olarkən işləyən cavab DNS-ə deyil, sertifikat etimadına və ya API siyasətinə işarə edir. Bu nasazlıqlar realdır və heç bir həlledici dəyişikliyi onları düzəltməyəcək.

Hansı addımın uğursuz olduğunu yazın. O tək sətir növbəti şəxsin ehtiyac duyduğu şeydir və qeyd etmək on saniyə çəkir.

Zənciri növbəti şəxsin tapa biləcəyi yerdə saxlayın

Təkan edilən həlledici, yönləndirmə qaydası, icazə verilən sorğu mənbəyi və cavab verən son nöqtə bir yerdə qeyd edin. Özəl ad yenidən uğursuz olduqda, qeyd tunelin yerini dəyişdiyini, həlledici ünvanının dəyişdiyini və ya qaydanın daraldıldığını göstərir. O olmadan hər hadisə sıfırdan başlayır və eyni üç təxminlə bitir.

Qeydi dəqiq qalacaq qədər qısa saxlayın: dörd sətir, tarix və hər hissənin sahibinin adı. Köhnə qeyd heç olmamasından pisdir, çünki səhv olduğu halda nüfuzlu görünür.