Şəxsi DNS adı, yoxsa sadəcə IP? Paylaşmadan əvvəl qərar verin

Şəxsi xidmət uzaq istifadəçilərə açılanda iki sual bir-birinə qarışır. Birincisi, müştərilərin hansı addan istifadə etməsidir; ikincisi, xidmətin hansı mənbələri qəbul etməsidir. Onlara bu sıra ilə cavab verin, çünki səhv giriş qaydası arxasındakı düzgün ad yenə də uğursuz olur, həll olunmayan ad arxasındakı düzgün qayda isə heç vaxt sınanmır.

Birinci şərt: müştərilərin hansı resolver yolu var?

Şəxsi ad yalnız müştərinin resolveri ona cavab verə bildikdə işləyir. Bu o deməkdir ki, icazəli uzaq müştəri zonanı saxlayan DNS serverinə çatmalıdır: ya tunel vasitəsilə, ya da təşkilatın uzaq istifadəçilər üçün artıq işlətdiyi resolver vasitəsilə. Tunel nəqliyyat vasitəsidir, kataloq deyil. Müştəriyə resolverə yol verir və hansı zonanı soruşacağını ona demir.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Açıq resolver şəxsi zonanı öyrənməyəcək, çünki noutbuk VPN-ə qoşulub.

Şəkilçi də eyni diqqətə layiqdir. Təşkilatın nəzarət etdiyi domenin alt domenindən istifadə edin ki, sahiblik və sertifikat planlaması aydın qalsın. .local işlətməyin: multicast DNS spesifikasiyası bu şəkilçini link-local həllə bağlayır və marşrutlaşdırılmış tunel bu davranışı sizin üçün təkrarlamır.

İkinci şərt: xidmət hansı mənbəni alır?

Giriş qaydaları ünvanlara görə yazılır, ona görə faydalı sual budur: marşrutlaşdırma və tərcümədən sonra xidmət hansı ünvanı görür. Məsələn, 10.20.30.40 ünvanındakı xidmət üçün ofis müştəriləri 10.20.30.0/24 aralığından, uzaq müştərilər isə ayrı bir hovuzdan, məsələn 10.99.0.0/24 aralığından gəlir.

Əgər şlüz uzaq hovuzu tərcümə edirsə, xidmət tərcüməçini görür və 10.99.0.0/24 üçün yazılmış qayda uyğun gəlməyəcək.

Bunu müştəri tərəfindən deyil, xidmət tərəfindən oxuyun. Xidmət hostundakı dinləyici jurnalı və ya paket tutumu həqiqətən gələn mənbəyi göstərir; müştərinin öz ünvanı isə yoldan nəyin keçdiyinə dair yalnız bir təxmindir.

Üçüncü şərt: ad xidmətə, yoxsa hosta bağlıdır?

Bir maşının ünvanına işarə edən ad hər müştərini həmin maşına bağlayır. Yük balanslaşdırıcısına və ya sabit xidmət ünvanına işarə edən ad isə arxasındakı hostun dəyişdirilməsindən sonra da qalır. Qərarı qəsdən verin, çünki bunu sonradan dəyişmək hər müştərinin əlfəcinlərini və hər sertifikatın subyektini dəyişmək deməkdir.

Tək daxili xidmət üçün birbaşa qeyd adətən yaxşıdır və üzərində düşünmək daha sadədir.

Dəyişdiriləcək, yenidən qurulacaq və ya miqyaslanacaq hər şey üçün sabit ön hissə əlavə konfiqurasiyaya dəyər. Sınaq sadədir: əgər istifadəçilərə demədən arxa hissəni dəyişə bilirsinizsə, ad xidmətə bağlıdır; bilmirsinizsə, hosta bağlıdır.

İki qərarı ayrıca sınayın

Əvvəlcə həll edin, sonra qoşulun. Gözlənilən ünvanı qaytaran həll sınağı ad yolunu sübut edir və giriş barədə heç nə demir. Qoşulma sınağı yolu və qaydanı birlikdə sübut edir, ona görə onu yalnız həll uğurlu olduqdan sonra keçirin.

curl -sv --max-time 5 https://files.corp.example/health

Sonra qadağan olunmuş mənbəni bir dəfə sınayın və nəticəni qeyd edin.

İki qeydi sənədləşdirmənizdə ayrı saxlayın: ad və onun zonası, qəbul edilən mənbələr və qaydanın sahibi. Biri dəyişəndə digəri dəyişməməlidir.

Qərar adətən harada səhv gedir

Ümumi nasazlıq, yalnız ofis şəbəkəsində həll olunan ad altında yayımlanmış və yalnız ofis aralığını qəbul edən giriş qaydası olan xidmətdir. Uzaq istifadəçilər sonra əslində iki ayrı buraxılmadan ibarət olan pozulmuş xidmət barədə məlumat verir. İkinci ümumi nasazlıq tərsidir: ad problemini aradan qaldırmaq üçün əlavə edilən geniş giriş qaydası xidməti heç kimin nəzərdə tutmadığı mənbələrdən əlçatan qoyur. Hər ikisi konfiqurasiya buraxılmadır və istifadəçinin yerindən eyni görünür.

Heç bir səhv tək uğurlu sınaqdan görünmür. Buna görə iki qərar ayrı qeydlərə və ayrı sınaqlara layiqdir, hətta hər ikisini eyni adam versə belə.

Xidmət işə düşməzdən əvvəl hər ikisini yazın, çünki növbəti dəyişikliyi düşünmək asan olacaq. Qeyd qısadır: ad və zonası üçün bir sətir, qəbul edilən mənbələr və qaydanın sahibi üçün bir sətir.