VPN üzerinden BIND: koşullu yönlendirme mi stub bölgesi mi?
Bir özel bölgeyi VPN üzerinden çözmenin üç yolu ve her birinin ne zaman uygun olduğu: forward, stub veya secondary, artı kararı veren kaynak adres denetimi.
Ofis çözümleyiciniz bir kurumsal ad alanı dışında her şeye yanıt verir ve onu bilen kurumsal DNS sunucusu bir VPN'in arkasındadır. BIND bu tek bölgeyi upstream'e üç farklı şekilde devredebilir ve bunlar farklı biçimde başarısız olur. Koşullu yönlendirme en küçük taahhüttür, stub bölgesi delegasyon verilerini tutar ve secondary tam bir kopya tutar. İlk bulduğunuz parçaya göre değil, upstream'in neye izin vereceğine ve çözümleyicinizin neyi tutmasını istediğinize göre seçin.
Tek bir ad alanı için üç düzen
| 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 |
Koşullu yönlendirme: en küçük taahhüt
Ofis çözümleyicisinin 192.168.10.53'te, kurumsal sunucunun ise onaylanmış bir tünelden erişilebilen 10.40.0.53'te olduğunu varsayın. Bildirim üç satırdır ve ilginç olanı forward only, çünkü yolu değil, hata davranışını değiştirir.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};
forward only ile erişilemeyen bir upstream bu bölge için yinelemeli çözüme geri dönmek yerine SERVFAIL üretir. Özel bir ad alanı için genellikle istediğiniz budur, çünkü geri dönüş özel adları genel bir çözümleyiciye gönderir ve internetten işe yaramaz bir yanıt getirirdi. BIND başvurusu her iki ilkeyi belgeler ve fark parçanın ima ettiğinden daha önemlidir. Bölgeyi aynı ad için zaten var olan bir bölgeyi değiştirmek yerine mevcut yapılandırmaya ekleyin.
Stub veya secondary: delegasyon ne zaman önemli
Stub bölgesi kurumsal sunucuya bölgenin NS kayıtlarını sorar, ardından yetkili sunuculara doğrudan sorar. Upstream bölgesi büyük veya alt bölümlere ayrılmışsa ve çözümleyicinizin her şeyi tek bir adrese sabitlemek yerine delegasyonu izlemesini istiyorsanız onu seçin. Bedeli, NS verilerinin güncel olmasına ve listelenen her ad sunucusuna çözümleyicinizin kaynak adresinden erişilebilmesine bağımlılıktı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 yerel verilerden yanıt verir ve upstream kesintisini atlatır; aktarım bağımlılığını kabul etmenin nedeni budur. Bu aynı zamanda çözümleyicinizin artık kendisine ait olmayan bir bölgenin kopyasını tuttuğu anlamına gelir, bu yüzden dosya yolu, birincildeki aktarım ACL'si ve yenileme zamanlayıcıları operasyonel yüzeyinizin parçası olur.
İkisi arasında karar veren denetim
BIND kendi giden sorgusunu kendisi üretir, bu yüzden soru bir dizüstü bilgisayarın 10.40.0.53'e ulaşıp ulaşamayacağı değil, çözümleyici ana bilgisayarının kurumsal sunucunun göreceği kaynak adresten ulaşıp ulaşamayacağıdır. Önce çekirdeğe, sonra sunucuya sorun, bu sırayla.
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 ve TCP'ye izin verin: kesilmiş bir yanıt TCP'yi zorlar ve yalnızca UDP'ye izin veren bir ilke, paket kaybı gibi görünen aralıklı hatalar üretir. Kurumsal tarafın hem çözümleyicinizin kaynağı için bir kabul kuralına hem de oraya bir dönüş yoluna ihtiyacı vardır; bu kaynak çözümleyicinin yönlendirilmiş adresi veya açıkça çevrilmiş bir adres olabilir ve nadiren bir istemci havuzu adresidir. NS sorgusu başarısız olursa, forward bölgesi nasıl davranırsa davransın stub bölgesi çalışamaz.
Yanıtı doğrulayın, tüneli değil
Ofis çözümleyicisi üzerinden hiç sormadığınız bir adı sorgulayın ve yanıtın authority bölümüne bakarak kurumsal bölgeden gelip gelmediğini anlayın. Önbellekteki bir yanıt geçerli yol hakkında hiçbir şey kanıtlamaz ve upstream'e doğrudan yapılan başarılı bir sorgu, çözümleyicinizin o bölgeyi seçtiğini kanıtlamaz. Aynı sorguyu TCP üzerinden yineleyerek yolun kesilmeye dayandığını doğrulayın.
İstemcileri ofis çözümleyicisine yönlendirilmiş tutun, ve DNSSEC doğrulamasını açık tutun. Bağımsız bir şifreli çözümleyiciyle yapılandırılmış bir tarayıcı bu düzeni tamamen atlar ve beklenmeyen bir yanıt doğru görünsün diye doğrulamayı kapatmak görünür bir hatayı görünmez bir hatayla değiştirir.
Üç türden hangisini seçtiğinizi ve nedenini yazın. Bölgenin başarısız olduğunu görecek bir sonraki kişiye yapılandırma dosyasından çok o cümle gerekecek.