Nebula feneri DNS: kim hangi kayıtları sorgulayabilir?

Nebula'daki fener rolü, insanların otomatik sandığı pek çok işi yapar ve DNS yanıtlamak bunlardan biri değildir. Ad hizmeti, devre dışı başlayan isteğe bağlı bir dinleyicidir; bu yüzden overlay içinde adları iyi çözen bir ana makine, iş arkadaşının dizüstü bilgisayarını çözecek hiçbir şeye sahip olmayabilir. Açmadan önce kimin ona ulaşması gerektiğine ve hangi kayıt türlerini yanıtlamaya razı olduğunuza karar verin, çünkü bu iki yanıt farklıdır.

Dinleyici isteğe bağlıdır ve varsayılan olarak kapalıdır

Keşif ve DNS ayrı hizmetlerdir. Fener eşlerin birbirini bulmasına yardımcı olur ve ayrıca bildiği ana makineler hakkındaki ad sorgularını yanıtlayabilir, ancak bu ikinci bölümün yapılandırmada açıkça açılması gerekir.

Herhangi bir şeyi etkinleştirmeden önce hangi arayüzlerin ve ağların dinleyiciye ulaşması gerektiğine karar verin. Amaçlamadığınız bir arayüzde yanıt veren bir DNS hizmeti, kimsenin okumadığı tek bir günlük kaydı olmadan küçük bir bilgi sızıntısına dönüşür. Karar şimdi vermek, bir şey yanlış yanıta bağlı hale geldikten sonra daraltmaktan çok daha ucuzdur. İki satır yapılandırmayı savunmak, altı ay sonraki bir olay notundan daha kolaydır.

A kayıtları ve TXT aynı kitleyi paylaşmaz

Bu iki kayıt türüne farklı koşullarda yanıt verilir ve onları tek bir hizmet olarak ele almak bu makalenin önlemek için var olduğu hatadır.

Bu asimetri kasıtlıdır, bir gözden kaçırma değildir. Adın adrese eşlenmesi bir yabancı için az değerlidir, oysa sertifika üst verileri overlay'inizdeki kimlikleri tanımlar. Aynı süreç her ikisini de yanıtlıyor diye bir satırdaki varsayımı diğerine taşımayın.

Yalnızca fenerin kendi ana makineleri hakkında yanıt verir

Bu, ofisiniz, bulut VPC'niz veya genel internet için genel bir çözümleyici değildir. Fener kendisine verilen ana makine bilgilerinden yanıt verir, bu yüzden bu özellik her eşte değil fener düğümlerinde yaşar.

Overlay ile hiçbir ilgisi olmayan bir ad başarısız olduğunda, onu gerçekten elinde tutan bölgeyi ve çözümleyiciyi bulun. Bir ana makinenin genel DNS yapılandırmasına overlay çözümleyici karıştırmak, bazı adlar çözüldüğü ve diğerlerine hiçbir şey yanıt vermediği için rastgele görünen arızalar üretir.

Şuna da dikkat edin: bootstrap giriş noktası. İlk fenere ulaşmak için kullanılan ana makine adı, keşif ona dayanmadan önce olağan bir yoldan çözülmelidir; bu yüzden buradaki tavuk-yumurta sorunu tam olarak bozuk bir overlay gibi görünür. Hatta aynı şekilde bildirir: hiçbir zaman ayağa kalkmayan bir eş ve belirgin bir neden yok. Sertifikalara dokunmadan önce ad çözümlemesini kontrol edin, çünkü bu sıra daha zor yarıyla başlayanları yakalar.

Bağlama adresini kontrol edin, sonra dışarıdan test edin

lighthouse.dns.host ve lighthouse.dns.port isteğe bağlı hizmetin nerede dinlediğini belirler. Bu değerleri ana makinenin güvenlik duvarı ve ağ ilkesiyle birlikte gözden geçirin, çünkü bağlama adresi bir niyet beyanıdır ve tek başına güvenlik denetimi değildir.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

İzin vermeyi düşündüğünüz ağlardan sorgulayın, fenerin kendisinden değil. Fenerde başarılı bir arama sürecin çalıştığını kanıtlar ve dışarıdaki bir ana makinenin ne sorabileceği hakkında hiçbir şey söylemez; asıl önemli olan soru da budur.

Onu bilerek açığa çıkarın

Adlar ve sertifika üst verileri yararlı operasyonel bilgilerdir ve yararlılık iki yöne de keser. Dinleyicinin yalnızca overlay için mi olması gerektiğine, hangi kayıt türlerine izin verileceğine ve yapılandırma değiştiğinde kimin gözden geçireceğine karar verin.

Sonra bunu fener ayarlarının yanına yazın. Çözümleme arızasını ayıklayacak bir sonraki kişi aksi halde hizmetin hep orada olduğunu varsayacaktır. Ayrıca test ettiği her yerden her zaman erişilebilir olduğunu varsayacaktır. Bağlama adresini, izin verilen ağları ve kayıt türlerini kaydeden bir paragraf o kişiye bir öğleden sonrayı ve size bir şeyin neden değiştiğini soran bir mesajı kazandırır.