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: सॉकेट पडताळा, नंतर मार्ग

पुन्हा सुरू केल्यानंतर, क्लायंट तपासण्यापूर्वी इच्छित सॉकेट आहेत याची खात्री करा. कधीही बाइंड न केलेल्या डेमॉनला मार्गाने वाचवता येत नाही, आणि योग्यरित्या बाइंड केलेल्या सॉकेटसमोर क्लायंटचे अपयश ही दुसऱ्या उपायाची दुसरी समस्या आहे. मग बोगद्यावरील क्लायंटकडून पोहोच तपासा. त्यानंतरच आवश्यक नावे सोडवली जातात का हे विचारणे योग्य आहे.

वेगळे ठेवावी अशी तीन उत्तरे: सॉकेट आहे, क्लायंट तिथवर पोहोचतो, उत्तर बरोबर आहे.

काय करू नये

पोर्ट मोकळा करण्यासाठी त्यावर काय अवलंबून आहे हे न जाणता अपरिचित रिझोल्व्हर थांबवू नका, कारण होस्टचे स्वतःचे शोध सहसा अवलंबून असतात. दुसऱ्या डेमॉनला सार्वजनिक ऐकण्याच्या पत्त्यावर हलवणारी जुनी कृती नकला करू नका, कारण ती दुष्परिणाम म्हणून कोण तुम्हाला विचारू शकतो हे ठरवते. आणि अपयश स्थानिक असताना पुढे पाठवणे जोडू नका.

मशीन व्यवस्थापित असल्यास, मालकीचा निर्णय पुढील प्रशासकाला सापडेल तिथे नोंदवा. इमेज पुन्हा तयार होताच पोर्ट संघर्ष परत येतात.