OpenVPN üzərində bölünmüş DNS: marşrutlaşdırma domeni hər əməliyyat sistemində nə etməlidir

Hər bölünmüş DNS sorğusu eyni cümlə ilə başlayır: şirkət adları şirkət DNS-inə gedir, qalan hər şey işləməyə davam edir. Bu cümləni konfiqurasiyaya çevirmək hər əməliyyat sistemi üçün üç suala cavab vermək deməkdir və cavablar hər birində fərqli mexanizmlərdən istifadə edir. Linux noutbukunda işləyən profillər tez-tez Windows-da tunellə heç bir əlaqəsi olmayan səbəblərdən uğursuz olur. Boşluq adətən marşrutla səhv salınan resolver ayarı.

Əvvəlcə siyasəti adlandırın, sonra onu ifadə edən platforma primitivini seçin.

Qarışdırmaq asan olan üç ayar

Axtarış şəkilçisi qısa adı genişləndirir: files yazdıqda, resolver şəkilçiləri sıra ilə sınadıqca o, files.corp.example olur. Marşrutlaşdırma domeni adlar fəzası daxilində sorğulara hansı resolverin cavab verəcəyini seçir. IP marşrutu isə yalnız seçilmiş resolveri əlçatan edir. Bu üçü fərqli təbəqələrdə yaşayır və birini digəri ilə əvəz etmək düzgün görünən, amma heç nə həll etməyən konfiqurasiya yaradır.

Qarışıqlığın qiyməti var: axtarış şəkilçisi əlavə etmək hər qısa adı iş resolverinə göndərir, o cümlədən başqa yerə aid adları. Marşrutlaşdırma domeni seçmək isə əlaqəsiz sorğuları yerli resolverdə saxlayır, eyni zamanda *.corp.example tuneldən keçirilir.

Linux: axtarış şəkilçisi deyil, yalnız marşrut domeni

systemd-resolved-də tilda ilə başlayan domen yalnız marşrut domenidir, yəni həmin adlar fəzası üçün sorğular bağlı resolverə gedir və eyni zamanda axtarış şəkilçisinə çevrilmir. resolvectl domain tun0 '~corp.example' bunu təyin edir, resolvectl dns tun0 10.8.0.1 isə serveri adlandırır. Hər iki ayar interfeysə aiddir, ona görə də onunla birlikdə yox olur. Tilda insanların buraxdığı hissədir və onsuz qısa adlar iş resolveri vasitəsilə həll olunmağa başlayır.

Eyni domeni qlobal axtarış şəkilçisi kimi də quraşdırmayın. İki ayar artıq deyil; biri marşrutlaşdırır, digəri yazdığınızı yenidən yazır.

Windows-a şəkilçi deyil, adlar fəzası siyasəti lazımdır

Windows bölünmüş DNS siyasətini adapterin DNS şəkilçisində deyil, Ad Həlli Siyasəti Cədvəlində saxlayır. Qayda adlar fəzasını konkret serverlərə bağlayır: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Yalnız şəkilçini təyin etmək qısa adların görünüşünü dəyişir; sorğunu başqa serverə yönəltmir.

Qoşulduqdan sonra faktiki siyasəti Get-DnsClientNrptPolicy ilə yoxlayın, çünki əvvəlki bağlantıdan qalan qayda tuneldən uzun yaşaya bilər. Tunel düşəndə qaydaları adla silin və göstərilən adı sabit saxlayın ki, təmizlik düzgün qeydə tuş gəlsin.

Hər platforma üçün bir resolver sahibi saxlayın

Masaüstü meneceri, OpenVPN up skripti və yerli resolver demonu hamısı eyni konfiqurasiyanı yazmağa cəhd edə bilər. Fikir ayrılığı yarandıqda son yazan qalib gəlir və nəticə sökmə sırasından asılı olur. Resolver vəziyyətinə sahib olmaq üçün bir komponent seçin, qalanları yazsın yox, hesabat versin və yenidən qoşulmanı sınayın: siyasət qaydaları təkrarlamadan onu keçməlidir. Ayırmanı da sınayın, çünki qalan vəziyyət növbəti bağlantını fərqli davranmağa məcbur edən şeydir.

Öz şifrələnmiş resolverini gətirən tətbiqlər əməliyyat sisteminin siyasətini tamamilə görməzdən gəlir. Bu, tətbiqin xüsusiyyətidir, tunelin qüsuru deyil.

Nəticəni yoxlayın, profil mətnini deyil

Hər platformada tuneldən keçməli olan bir adı və keçməməli olan bir adı həll edin və hansı serverin cavab verdiyini təsdiqləyin. resolvectl query host.corp.example və Resolve-DnsName host.corp.example hər ikisi cavab verən serveri göstərir. Yenidən qoşulmadan sonra təkrarlayın. Sonra tunelin resolverinin profilin təqdim etdiyi ünvanda əlçatan olduğunu təsdiqləyin, çünki əlçatmaz serverə işarə edən düzgün siyasət heç siyasət olmaması kimi uğursuz olur.

Nəzərdə tutulan davranışı profilin qeydlərində yazın: hansı şəkilçi marşrutlaşdırır, hansı server ona cavab verir və qalan hər şeyə nə olur. Dəstəkləyəcəyiniz növbəti platforma konfiqurasiya faylına deyil, o cümləyə daha çox ehtiyac duyacaq.