dnsmasq 53 numaralı bağlantı noktasını bağlayamıyor: onu tutan soketi bulun

dnsmasq adresin zaten kullanımda olduğu hatasıyla çıkar ve günlük suçluyu değil bağlantı noktasını adlandırır. Aynı makinede VPN de çalışıyorsa ilk tepki itilen rotaları suçlamaktır, ancak bind hatası herhangi bir istemci sorgu göndermeden önce oluşur. Bir şey soketi zaten tutuyordur ve görev onu tanımlamaktır. Rota değişiklikleri bir bağlantı noktasını serbest bırakamaz.

Bu sırayla beş adım: hatayı yeniden üretin, dinleyicileri listeleyin, wildcardı anlayın, görevi atayın ve sonra doğrulayın.

Adım 1: hatayı yeniden üretin ve okuyun

dnsmasqı hizmetin kullandığı yapılandırmayla ön planda başlatın, böylece hata tahmin etmeniz gereken bir günlük yerine terminalinizde görünür. İletideki adres ailesine ve yerel adrese dikkat edin. Belirli bir adrese bind ile wildcarda bind, farklı sahipleri olan farklı hatalardır.

Tam metni saklayın. Adres kullanımda, izin hatası ve eksik arayüz hepsi başlatma hatası olarak gelir ve üç farklı onarıma işaret eder.

Adım 2: sahipleri listeleyin

Önce soketleri listeleyin. Kaynak bağlantı noktası 53 üzerindeki filtre, görmeye yetkiniz varsa hem taşıma katmanlarını hem de sahip süreci gösterir:

ss -lntup 'sport = :53'

Çıktıyı sütunlar hâlinde okuyun: taşıma, yerel adres, bağlantı noktası, süreç. TCP dinleyicisi ile UDP dinleyicisi ayrı soketlerdir, bu yüzden birini durdurmak diğerini serbest bırakmaz. Wildcard adresi her arayüzü kapsar, yani hiçbir satır adıyla anmasa da VPN adresi zaten alınmıştır. Süreç adı da bunun dağıtımın yönettiği bir çözümleyici mi, bir kapsayıcı mı yoksa önceki bir deneyin çalışır bıraktığı bir şey mi olduğunu söyler.

Adım 3: wildcard tuzağı

bind-interfaces seçeneği, dnsmasqın wildcard soketi mi yoksa yapılandırılmış her arayüz için bir soket mi bağlayacağını değiştirir; dnsmasq başvurusu bunu açıklar. O olmadan dnsmasq wildcardı bağlayıp istekleri arayüze göre süzebilir; bu, wildcardı başka bir daemon tuttuğunda hemen başarısız olur. Linux bind-dynamic seçeneğini ekler; bu, başlatmadan sonra oluşturulan arayüzleri ele alır ve VPN arayüzü yalnızca bağlanırken göründüğünde gerçek bir sorundur.

Bu yüzden ikisi de farklı arayüzler için yapılandırılmış görünen iki daemon yine de çakışır. Çatışma niyette değil sokettedir. Bağlama kipini bilerek seçin ve değiştirmeden önce sürümünüz için belgelenmiş davranışı okuyun.

Adım 4: görevi atayın

Hangi daemonun VPN istemcilerine, hangisinin ana makineye yanıt vereceğine karar verin. Tünel adresinde dinleyip yukarıya ileten tek bir çözümleyici yaygın bir düzenlemedir; her biri 53 numaralı bağlantı noktasına sahip olduğunu varsayan iki çözümleyici hiçbir düzenleme değildir.

Ardından bu kararı her hizmetin kendi yapılandırmasında ifade edin: dinleme adresleri, arayüz filtreleri ve iletme. Bunları hizmetin sahibi üzerinden değiştirin; ister dağıtım birimi, ister ağ yöneticisi isterse kapsayıcı çalışma ortamı olsun, değişiklik yeniden başlatmadan sonra da kalsın.

Adım 5: soketi, sonra yolu doğrulayın

Yeniden başlatmadan sonra, bir istemciyi test etmeden önce amaçlanan soketlerin var olduğunu doğrulayın. Hiç bağlanmamış bir daemon bir rota ile kurtarılamaz ve doğru bağlanmış bir sokete karşı istemci hatası başka bir düzeltmesi olan başka bir sorundur. Ardından tüneldeki bir istemciden erişilebilirliği denetleyin. Gerekli adların çözülüp çözülmediğini sormak ancak ondan sonra anlamlıdır.

Ayrı tutulması gereken üç sonuç: soket var, istemci ona ulaşıyor, yanıt doğru.

Yapılmaması gerekenler

Bağlantı noktasını serbest bırakmak için neye bağlı olduğunu bilmeden tanımadığınız bir çözümleyiciyi durdurmayın, çünkü ana makinenin kendi sorguları genellikle ona bağlıdır. İkinci daemonu herkese açık bir dinleme adresine taşıyan eski bir tarifi kopyalamayın, çünkü bu yan etki olarak kimin size sorgu gönderebileceğini belirler. Ve hata yerelken iletme eklemeyin.

Makine yönetiliyorsa sahiplik kararını bir sonraki yöneticinin bulacağı yere kaydedin. Bağlantı noktası çakışmaları her imaj yeniden oluşturulduğunda geri döner.