VPN üzərində BIND: şərti yönləndirmə, yoxsa stub zonası?
Bir şəxsi zonanı VPN vasitəsilə həll etməyin üç yolu və hər birinin nə vaxt uyğun olduğu: forward, stub və ya secondary, üstəgəl seçimi həll edən mənbə ünvanı yoxlaması.
Ofis resolveriniz bir korporativ ad məkanı istisna olmaqla hər şeyə cavab verir və onu bilən korporativ DNS serveri VPN-in arxasında yerləşir. BIND həmin tək zonanı upstream-ə üç fərqli şəkildə verə bilər və onlar fərqli şəkildə sıradan çıxır. Şərti yönləndirmə ən kiçik öhdəlikdir, stub zonası delegasiya məlumatlarını saxlayır, secondary isə tam surəti saxlayır. Seçimi upstream-in nəyə icazə verdiyinə və resolverinizin nəyi saxlamasını istədiyinizə görə edin, ilk rastlaşdığınız kod parçasına görə deyil.
Bir ad məkanı üçün üç quruluş
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
Şərti yönləndirmə: ən kiçik öhdəlik
Tutaq ki, ofis resolveri 192.168.10.53 ünvanındadır və korporativ server 10.40.0.53 ünvanında, təsdiqlənmiş tunel ilə əlçatandır. Bəyannamə üç sətirdir və maraqlı olanı forward only-dir, çünki o, yolu deyil, uğursuzluq davranışını dəyişir.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};
forward only ilə əlçatmaz upstream bu zona üçün iterativ həllə qayıtmaq əvəzinə SERVFAIL verir. Şəxsi ad məkanı üçün adətən istədiyiniz budur, çünki qayıtma şəxsi adları ictimai resolverə göndərib internetdən faydasız cavab qaytarardı. BIND istinadı hər iki siyasəti sənədləşdirir və fərq kod parçasının işarə etdiyindən daha önəmlidir. Zonanı mövcud konfiqurasiyaya birləşdirin, eyni ad üçün artıq mövcud olan zonanı əvəz etməyin.
Stub və ya secondary: delegasiya nə vaxt vacibdir
Stub zonası korporativ serverdən zonanın NS qeydlərini soruşur və sonra səlahiyyətli serverlərə birbaşa sorğu göndərir. Onu upstream bölgəsi böyük və ya bölünmüş olduqda və resolverinizin hər şeyi bir ünvana bağlamaq əvəzinə delegasiyanı izləməsini istədikdə seçin. Qiyməti NS məlumatlarının aktual olmasından və siyahıdakı hər ad serverinin resolverinizin mənbə ünvanından əlçatan olmasından asılılıqdır.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};
Secondary yerli məlumatdan cavab verir və upstream kəsintisini keçirir; transfer asılılığını qəbul etməyin səbəbi budur. Bu həm də o deməkdir ki, resolveriniz indi sahibi olmadığı zonanın surətini saxlayır, buna görə fayl yolu, əsas serverdəki transfer ACL-i və yeniləmə taymerləri əməliyyat səthinizin bir hissəsinə çevrilir.
Aralarında qərar verən yoxlama
BIND öz giden sorğusunu yaradır, buna görə sual noutbukun 10.40.0.53-ə çata bilməsi deyil, resolver hostunun korporativ serverin görəcəyi mənbə ünvanından çata bilməsidir. Əvvəl kernelə, sonra serverə soruşun, bu sıra ilə.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example
Yolda UDP və TCP-yə icazə verin: kəsilmiş cavab TCP-ni məcbur edir və yalnız UDP-yə icazə verən siyasət paket itkisinə bənzəyən fasiləli nasazlıqlar yaradır. Korporativ tərəf həm resolverinizin mənbəyi üçün qəbul qaydasına, həm də ona qayıdış marşrutuna ehtiyac duyur; bu mənbə resolverin marşrutlaşdırılmış ünvanı və ya açıq şəkildə çevrilmiş ünvan ola bilər və nadir hallarda müştəri hovuzu ünvanıdır. NS sorğusu uğursuz olarsa, forward zonası necə davranırsa da stub zonası işləyə bilməz.
Tuneli deyil, cavabı yoxlayın
Heç vaxt soruşmadığınız bir ad üçün ofis resolveri vasitəsilə sorğu göndərin və cavabın authority bölməsinə baxaraq onun korporativ zonadan gəlib-gəlmədiyini yoxlayın. Keşlənmiş cavab cari yol haqqında heç nə sübut etmir və upstream-ə birbaşa uğurlu sorğu resolverinizin həmin zonanı seçdiyini sübut etmir. Eyni sorğunu TCP üzərindən təkrarlayın ki, yolun kəsilməyə davam etdiyini təsdiqləyəsiniz.
Müştəriləri ofis resolverinə yönəldin, DNSSEC yoxlamasını da açıq saxlayın. Müstəqil şifrəli resolver ilə konfiqurasiya edilmiş brauzer bu quruluşu tamamilə yan keçir və gözlənilməz cavabın düzgün görünməsi üçün yoxlamanı söndürmək görünən uğursuzluğu görünməyən biri ilə dəyişir.
Üç tipdən hansını seçdiyinizi və niyə seçdiyinizi yazın. Zonanın sıradan çıxdığını görəcək növbəti şəxsə o cümlə konfiqurasiya faylından daha çox lazım olacaq.