ip netns exec və DNS: adlar niyə ad sahəsinin içində uğursuz olur

Bir əmr VPN ad sahəsinin içində 10.8.0.5 ünvanına heç bir şikayət olmadan çatır, eyni əmr host adı işlətdiyi anda uğursuz olur. Ad sahəsinin öz interfeysləri, marşrutları və soketləri var; öz həlledici faylı yoxdur. Ora hər hansı bir şey fayl qoymasa, içəridəki proses host-un /etc/resolv.conf faylını oxuyur və o şəbəkə yığınından əlçatmaya biləcək bir serverdən soruşur.

Bu, marşrut problemi deyil, fayl seçimi problemidir — rəqəmsal ünvanın hələ də işləməsinin səbəbi də elə budur.

Prosesin həqiqətən gördüyü həlledici görünüşünü yoxlayın

İstifadə etdiyiniz shell-in sazladığınız proseslə eyni olduğunu güman etməyin. Qrafik tətbiq, systemd vahidi və konteyner hər biri fərqli bir mount və ya şəbəkə kontekstinə girə bilər. Axtarışı eyni işə salma yolu ilə aparın və həlledici faylını onun içindən çap edin.

ip netns add ilə yaradılmış ad sahəsi üçün yalnız oxuma yoxlaması qısadır:

ip netns exec vpn cat /etc/resolv.conf

Nəticənin əlçatan ünvan, loopback stub-u, yoxsa fərqli əlçatanlığı olan bir yerə işarə edən simvolik keçid göstərdiyinə diqqət yetirin.

exec köməkçisi əslində nə mount edir

ip-netns aləti hər ad sahəsinin konfiqurasiyasını /etc/netns/NAME/ altında sənədləşdirir. Bir proses işə saldıqda köməkçi mount ad sahəsi yaradır və həmin faylları adi yollarının üzərinə bind-mount edir, beləliklə proses ad sahəsinə xas surəti görür. Bu, məhz bu işəsalıcının rahatlığıdır. Şəbəkə ad sahəsinə başqa yolla, məsələn unshare və ya konteyner runtime-ı ilə girmək bunu avtomatik təkrarlamır.

Burada tələ loopback həlledicidir: 127.0.0.53 host-un stub-u deyil, ad sahəsinin öz loopback-ini bildirir. Yalnız host ad sahəsində dinləyən stub yeni ad sahəsində xidmətə çevrilmir.

Ad sahəsinin çata biləcəyi həlledici seçin

Fayl hansı serveri göstərirsə göstərsin, hələ də həmin ad sahəsindən marşrut tələb edir. İctimai həlledici ictimai adlara cavab verə və yenə də daxili zona üçün uğursuz ola bilər, çünki şəxsi xidmətə yalnız tunel vasitəsilə çatmaq olar. Marşrutu ünvanla eyni vaxtda yoxlayın, sorğu artıq uğursuz olduqdan sonra deyil.

Öz həlledicisi olan tətbiqlər, məsələn DNS over HTTPS istifadə edən biri, faylı tamamilə görməməzlikdən gələ bilər. Alətin öz DNS parametri varsa, resolv.conf faylını dəyişmək ona təsir etməyəcək və ad sahəsi heç vaxt problem olmayıb.

Faylı düzgün yerə yazın

/etc/netns/NAME/resolv.conf altında ad sahəsinə xas faylı yaradın və işəsalıcı onu təqdim etsin. Onu minimal saxlayın: bir və ya iki əlçatan server və tapşırığın ehtiyac duyduğu axtarış domenləri. Bir qrup proses üçün nəzərdə tutulmuş görünüşü düzəltmək üçün host-un yaratdığı həlledici faylını redaktə etməyin, çünki bu, maşındakı hər tətbiqi dəyişir. Host həlledici menecerindən istifadə edirsə, ad sahəsi yolunu onunla mübarizə aparmaq əvəzinə həmin menecer vasitəsilə konfiqurasiya edin.

Faylın məzmununu runbook-da qeyd edin. Əks halda növbəti şəxs host-un həlledicisini sınaqdan keçirir, işləyən cavab görür və ad sahəsinin qaydasında olduğu qənaətinə gəlir.

Bütün yolu yenidən sınaqdan keçirin

Ad sahəsinin içində rəqəmsal ünvanla, daxili adla və ictimai adla sınaq keçirin. Bu ardıcıllıq əlçatanlığı həll etmədən, daxili zonaları isə ictimai zonalardan ayırır. Sonra ad sahəsini yenidən yaradın və təkrarlayın, çünki yalnız işləyən nüsxədə mövcud olan fayl onunla birlikdə yox olur.

Faylı shell-in deyil, prosesin aldığını təsdiqləyin. İnteraktiv shell-dən işləyib xidmətdən uğursuz olan sorğu mount konteksti ilə bağlı tapıntıdır və növbəti insidentdən əvvəl onu sıfırdan yenidən kəşf etmək əvəzinə yazmağa dəyər.