dnsmasq पोर्ट 53 को बाइंड नहीं कर पा रहा: वह सॉकेट खोजें जो उसे रखता है

dnsmasq इस त्रुटि के साथ बंद हो जाता है कि पता पहले से उपयोग में है, और लॉग दोषी के बजाय पोर्ट का नाम लेता है। जिस मशीन पर VPN भी चलता है, वहाँ पहली प्रतिक्रिया धकेले गए रूटों को दोष देना होती है, पर बाइंड विफलता किसी भी क्लाइंट के क्वेरी भेजने से पहले होती है। कुछ पहले से सॉकेट रखे हुए है, और काम उसे पहचानना है। रूट बदलाव किसी पोर्ट को मुक्त नहीं कर सकते।

इस क्रम में पाँच चरण: त्रुटि दोहराएँ, श्रोताओं की सूची बनाएँ, wildcard समझें, काम सौंपें, फिर सत्यापित करें।

चरण 1: त्रुटि दोहराएँ और पढ़ें

dnsmasq को उसी कॉन्फ़िगरेशन के साथ अग्रभूमि में शुरू करें जो सेवा उपयोग करती है, ताकि त्रुटि अनुमान लगाने वाले लॉग के बजाय आपके टर्मिनल में दिखे। संदेश में पता परिवार और स्थानीय पता देखें। किसी विशिष्ट पते पर बाइंड और wildcard पर बाइंड अलग-अलग स्वामियों वाली अलग-अलग विफलताएँ हैं।

सटीक पाठ रखें। पता उपयोग में है, अनुमति विफलता और अनुपस्थित इंटरफ़ेस—सभी शुरुआत की विफलता के रूप में आते हैं, और वे तीन अलग-अलग मरम्मतों की ओर संकेत करते हैं।

चरण 2: स्वामियों की सूची बनाएँ

पहले सॉकेट की सूची बनाएँ। स्रोत पोर्ट 53 पर फ़िल्टर देखने का अधिकार होने पर दोनों ट्रांसपोर्ट और स्वामी प्रक्रिया दिखाता है:

ss -lntup 'sport = :53'

आउटपुट को स्तंभों में पढ़ें: ट्रांसपोर्ट, स्थानीय पता, पोर्ट, प्रक्रिया। TCP श्रोता और UDP श्रोता अलग सॉकेट हैं, इसलिए एक को रोकने से दूसरा मुक्त नहीं होता। wildcard पता हर इंटरफ़ेस को ढकता है, यानी VPN पता पहले से लिया हुआ है, भले ही कोई पंक्ति उसका नाम न ले। और प्रक्रिया का नाम बताता है कि यह वितरण-प्रबंधित रिज़ॉल्वर है, कंटेनर है, या पिछले प्रयोग ने चलता छोड़ा हुआ कुछ है।

चरण 3: wildcard का जाल

bind-interfaces विकल्प तय करता है कि dnsmasq wildcard सॉकेट बाइंड करे या हर कॉन्फ़िगर किए गए इंटरफ़ेस के लिए एक सॉकेट, जैसा कि dnsmasq संदर्भ वर्णित करता है। इसके बिना dnsmasq wildcard बाइंड कर सकता है और इसके बजाय अनुरोधों को इंटरफ़ेस के अनुसार फ़िल्टर कर सकता है, जो तुरंत विफल होता है जब कोई दूसरा डेमॉन wildcard रखता है। Linux bind-dynamic जोड़ता है, जो शुरू होने के बाद बने इंटरफ़ेस संभालता है, जो वास्तविक चिंता है जब VPN इंटरफ़ेस केवल कनेक्ट पर प्रकट होता है।

इसीलिए अलग-अलग इंटरफ़ेस के लिए कॉन्फ़िगर दिखने वाले दो डेमॉन फिर भी टकराते हैं। टकराव सॉकेट पर है, इरादे पर नहीं। बाइंडिंग मोड जानबूझकर चुनें और बदलने से पहले अपने संस्करण के लिए प्रलेखित व्यवहार पढ़ें।

चरण 4: काम सौंपें

तय करें कौन सा डेमॉन VPN क्लाइंट को उत्तर देता है और कौन होस्ट को। एक रिज़ॉल्वर जो टनल पते पर सुनता है और ऊपर की ओर अग्रेषित करता है एक सामान्य व्यवस्था है; दो रिज़ॉल्वर जिनमें से हर एक मानता है कि वह पोर्ट 53 का स्वामी है, कोई व्यवस्था ही नहीं है।

फिर उस निर्णय को हर सेवा के अपने कॉन्फ़िगरेशन में व्यक्त करें: सुनने के पते, इंटरफ़ेस फ़िल्टर और अग्रेषण। उन्हें सेवा के स्वामी के माध्यम से बदलें, चाहे वह वितरण इकाई हो, नेटवर्क प्रबंधक हो या कंटेनर रनटाइम, ताकि बदलाव पुनःआरंभ के बाद भी टिके।

चरण 5: सॉकेट सत्यापित करें, फिर पथ

पुनःआरंभ के बाद, क्लाइंट परखने से पहले पुष्टि करें कि इच्छित सॉकेट मौजूद हैं। जो डेमॉन कभी बाइंड नहीं हुआ उसे रूट से नहीं बचाया जा सकता, और सही ढंग से बाइंड सॉकेट के सामने क्लाइंट की विफलता दूसरे समाधान वाली दूसरी समस्या है। फिर टनल पर क्लाइंट से पहुँच जाँचें। उसके बाद ही यह पूछना उचित है कि आवश्यक नाम हल होते हैं या नहीं।

अलग रखने योग्य तीन परिणाम: सॉकेट है, क्लाइंट उस तक पहुँचता है, उत्तर सही है।

क्या न करें

पोर्ट मुक्त करने के लिए किसी अपरिचित रिज़ॉल्वर को बंद न करें, यह जाने बिना कि उस पर क्या निर्भर है, क्योंकि होस्ट की अपनी खोजें सामान्यतः निर्भर होती हैं। कोई पुरानी विधि नकल न करें जो दूसरे डेमॉन को सार्वजनिक सुनने के पते पर ले जाती है, क्योंकि वह दुष्प्रभाव के रूप में तय करती है कि कौन आपसे पूछ सकता है। और जब विफलता स्थानीय थी तो अग्रेषण न जोड़ें।

यदि मशीन प्रबंधित है, तो स्वामित्व का निर्णय वहाँ दर्ज करें जहाँ अगला प्रशासक उसे पाए। हर बार इमेज फिर से बनने पर पोर्ट टकराव लौटते हैं।