VPN konteynerinin şəbəkəsini paylaşmaq: DNS ilə nə baş verir

VPN konteynerinin şəbəkə ad sahəsini paylaşmaq tətbiqinizə tunelin interfeyslərini və marşrutlarını verir. O, ona tunelin resolverini vermir, nə də hostdakı hər hansı başqa şeyin birləşdirilmiş surətini. Bu boşluq çox konkret bir nasazlıq yaradır: ictimai adlar həll olunur, daxili adlar olunmur, və uğursuz olan tətbiq sanki səhv DNS serverindən istifadə edirmiş kimi görünür, çünki elədir. Təmir adətən diaqnozun təklif etdiyindən kiçik olur.

Addım 1: Hostdan deyil, tətbiqin içindən sınaqdan keçirin

Axtarışı problem olan konteynerin içində işə salın, hostda və brauzerdə deyil. docker exec app-container getent hosts db.internal yalnız vacib olan suala cavab verir: bu prosesin resolveri nə qaytarır.

Host adı həll edirsə, konteyner etmirsə, nasazlığı tapmısınız. Bundan sonra hər şey onu düzəltməyin dəstəklənən yolunu seçməkdir.

Addım 2: Runtime-ın dəstəklədiyi modeli oxuyun

Docker-in şəbəkə sənədləşməsi başqa konteynerin şəbəkə rejimini paylaşan konteynerlər üçün DNS bayraqlarına dair məhdudiyyətlər qeyd edir. Compose-da network_mode: service:vpn tətbiqi VPN konteynerinin ad sahəsinə bağlayır və hər xidmət üzrə dns parametrlər adi xidmətdə olduğu kimi davranmır. Aldığınız həll paylaşılan ad sahəsinin malik olduğu həlldir.

İstifadəçi tərəfindən təyin edilmiş körpü şəbəkələri də Docker-in daxili DNS-indən standart körpüdən fərqli istifadə edir. Buna görə işləyən bir körpü nümunəsindən köçürülmüş dns bəndi paylaşılan yığımda heç bir şey edə bilməz. Bəndi köçürməzdən əvvəl quruluşu yoxlayın.

Loopback ünvanı həmişə müvafiq şəbəkə kontekstinə aiddir. Paylaşılan ad sahəsinin içində 127.0.0.1 hostun resolveri deyil.

Addım 3: Sorğunu alıcısına qədər izləyin

Tətbiqin resolver konfiqurasiyasını, sonra tətbiqlə gələn hər hansı tətbiqə xas şifrələnmiş DNS-i oxuyun, çünki öz resolverini işlədən tətbiq redaktə etdiyiniz faylı nəzərə almır. Sonra seçilmiş resolverin VPN marşrutları və firewall siyasəti altında əlçatan olub-olmadığını yoxlayın. Tunelin o biri tərəfindəki resolver ünvanı, ad sahəsinin ora marşrutu yoxdursa faydasızdır. Hər hansı faylı redaktə etməzdən əvvəl alıcını təsdiqləyin.

Brauzerdəki IP yoxlama səhifəsi ad sorğularının hara getdiyini deyə bilməz. O, bir HTTP bağlantısının hara getdiyini deyir.

Addım 4: İki nasazlıq sinfini fərqli düzəldin

Xidmət adları uğursuz olursa, ictimai adlar işləyirsə, problem konteyner şəbəkəsinin içindəki xidmət kəşfidir, ictimai resolver siyahısı deyil. Hər ictimai DNS ünvanını dəyişmək şəbəkənin kəşf mexanizmindən heç vaxt istənilməmiş qeydlər yaratmayacaq.

Hər iki sinif uğursuz olursa, resolverə əlçatanlıqdan başlayın. Yalnız biri uğursuz olursa, kəşf mexanizmindən başlayın. İkisinin fərqli sahibləri var, buna görə bir təmir heç vaxt ikisini əhatə etmir.

Addım 5: Yenidən yaratdıqdan sonra yenidən sınaqdan keçirin

Konfiqurasiyanı runtime-ın dəstəklədiyi mexanizmlə dəyişin, sonra işləyən konteynerin içində faylları redaktə etmək əvəzinə konteynerləri yenidən yaradın. Təzə bir özəl ad, təzə bir ictimai ad və axtarışdan sonra gələn tətbiq sorğusunu sınayın. /etc/resolv.conf daxilində konteynerə edilən düzəliş yenidən yaradılma zamanı yox olur və sizi düzəlişin işlədiyinə inandırar, halbuki işləməmişdi.

Resolver sahibini və gözlənilən ad sahəsini paylaşılan şəbəkə tərifinin yanında qeyd edin. Növbəti şəxs hər ikisinə ehtiyac duyacaq.