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: सकेट प्रमाणित गर्नुहोस्, त्यसपछि मार्ग

पुन: सुरु गरेपछि, ग्राहक परीक्षण गर्नु अघि इच्छित सकेटहरू छन् भनी पुष्टि गर्नुहोस्। कहिल्यै बाइन्ड नगरेको डेमनलाई मार्गले बचाउन सक्दैन, र ठीकसँग बाइन्ड भएको सकेटसामु ग्राहकको असफलता अर्कै उपाय भएको अर्कै समस्या हो। त्यसपछि सुरुङमा रहेको ग्राहकबाट पुग्ने क्षमता जाँच्नुहोस्। त्यसपछि मात्र आवश्यक नामहरू समाधान हुन्छन् कि भनी सोध्नु उचित हुन्छ।

अलग राख्नुपर्ने तीन नतिजा: सकेट छ, ग्राहक त्यहाँ पुग्छ, जवाफ सही छ।

के गर्नु हुँदैन

पोर्ट खाली गर्न त्यसमा के निर्भर छ थाहा नपाई अपरिचित रिजोल्भर रोक्नु हुँदैन, किनकि होस्टका आफ्नै खोजहरू सामान्यतया निर्भर हुन्छन्। दोस्रो डेमनलाई सार्वजनिक सुन्ने ठेगानामा सार्ने पुरानो विधि नक्कल नगर्नुहोस्, किनकि त्यसले पार्श्वप्रभावका रूपमा कसले तपाईंलाई सोध्न सक्छ भन्ने निर्धारण गर्छ। र असफलता स्थानीय हुँदा अगाडि पठाउने थप्नु हुँदैन।

यदि मेसिन व्यवस्थापित छ भने, स्वामित्वको निर्णय अर्को प्रशासकले भेट्ने ठाउँमा अभिलेख गर्नुहोस्। इमेज फेरि बन्दा पोर्ट द्वन्द्व फर्केर आउँछ।