OpenVPN AF_INET चेतावनी: हानिरहित फलब्याक वा असफल सकेट?

OpenVPN का दुई लग लाइनहरू एउटै शब्दबाट सुरु हुन्छन्, र तीमध्ये एउटाले मात्र समस्याको रिपोर्ट गर्छ। Could not determine IPv4/IPv6 protocol. Using AF_INET फलब्याक सूचना हो: प्रोफाइलले ठेगाना परिवार खुला छोड्यो, त्यसैले डेमनले एउटा छान्यो र अगाडि बढ्यो। असफलता शाखाले कुनै सकेट सिर्जना नभएको रिपोर्ट गर्छ र पुन: सुरु गर्न अनुरोध गर्छ। साझा उपसर्गपछिको सबै कुराले तिनीहरूलाई छुट्याउँछ, त्यसैले केही परिवर्तन गर्नु अघि त्यसभन्दा पर पढ्नुहोस्।

फलब्याक सूचनाले के रिपोर्ट गर्छ

OpenVPN ले proto udp4 वा proto udp6 मार्फत स्पष्ट परिवार स्वीकार गर्छ, र सुरुमा परिवार निकाल्नुपर्ने भए proto udp स्वीकार गर्छ। दोस्रो अवस्थामा डेमनले स्थानीय बाइन्ड जानकारी जाँचेर छान्छ।

त्यो निकासी काम गरेपछि, चेतावनीले कुन दिशामा गयो भन्छ र प्रक्रियाले सकेट सिर्जना गर्न जारी राख्छ। दोहोरो स्ट्याक होस्टमा proto udp भएको सर्भर प्राय: यसरी नै IPv4 मा पुग्छ। त्यो बाटोमा केही पनि त्रुटि होइन, र त्यसमा आक्रमण, हराएको वेब सर्भर वा अस्वीकृत खाताको कुनै संकेत छैन। लाइन उपयोगी हुनुको कारण पछिका जाँचहरू यसले नाम दिएको परिवारसँग तुलना गर्नुपर्ने हो।

यसलाई एउटा प्रश्नको उत्तरका रूपमा लिनुहोस्, निदानका रूपमा होइन। यसले यो प्रक्रियाले कुन परिवार छान्यो भन्छ, र क्लाइन्ट किन जोडिन सक्दैन भन्नेबारे केही पनि भन्दैन।

असफलता शाखा कस्तो देखिन्छ

पछि त्यही सकेट कोडमा सकेट नै नभएको शाखा छ। यसले छोटो ठेगाना-परिवार सन्देश लग गर्छ र पुन: सुरु गर्न अनुरोध गर्छ, किनकि अगाडि बढ्न केही बाँकी छैन। सुरुका शब्दहरू फलब्याकसँग मिल्छन्; नतिजा मिल्दैन।

तिनीहरूलाई त्यसपछि आउने कुराले छुट्याउनुहोस्। यदि डेमन चलिरहन्छ र आफ्नो स्रोताको रिपोर्ट गर्छ भने, त्यो लाइन जानकारी थियो। यदि यो बाहिर निस्कन्छ वा लुपमा पुन: सुरु हुन्छ भने, अब कुरा बाइन्डको हो।

grep मा भेटिएको कुरा पनि शाखाको पहिचान होइन। यो वाक्यांश घुमाइएका सारांशहरूमा, मोडिएका लाइनहरूमा र मानिसहरूले दोस्रो हातबाट टाँस्ने लग अंशहरूमा देखिन्छ, त्यसैले एकल मिलानको सट्टा छेउछाउका लाइनहरू र टाइमस्ट्याम्पको क्रम पढ्नुहोस्।

चेतावनीको सट्टा स्रोता जाँच्नुहोस्

चलिरहेको सर्भरले लग पाठबाट अनुमान नगरी परिवारको प्रश्नको सिधा उत्तर दिन्छ।

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

परिवार, ठेगाना र पोर्टलाई प्रोफाइलसँग मिलाउनुहोस्। 0.0.0.0:1194 लाइन मात्र IPv4 हो, जबकि दोहोरो स्ट्याक होस्टमा [::]:1194 लाइन bindv6only सेटिङअनुसार दुवै परिवार स्वीकार गर्न सक्छ। यदि प्रोफाइलले udp भन्छ र सकेट IPv4 छ भने, जसको रिजोल्भरले मात्र AAAA रेकर्ड फर्काउँछ ती क्लाइन्ट सुरुङमा कुराकानी हुनुअघि नै असफल हुनेछन्।

त्यसपछि तपाईंका प्रयोगकर्ताजस्तै क्लाइन्टबाट परीक्षण गर्नुहोस्: उही रिजोल्भर मार्ग, उही प्रकारको नेटवर्क। सर्भरबाट स्थानीय जडानले NAT यन्त्र वा अर्को परिवारका लागि लेखिएको फायरवाल नियम पार गर्ने ट्राफिकबारे धेरै थोरै मात्र प्रमाणित गर्छ।

परिवार बाध्य पार्नु कहिले ठीक हुन्छ

proto udp4 पिन गर्नु IPv4-मात्र तैनातीका लागि उपयुक्त हुन्छ: A मात्र DNS नाम, एउटा v4 ठेगानाका लागि फायरवाल नियम, v4 ठेगाना मात्र दिने अपरेटरहरूपछाडिका क्लाइन्ट। यसले अस्पष्टता हटाउँछ र अर्को लग लाइन समूहलाई अनुमानयोग्य बनाउँछ।

त्यही तर्क IPv6-पहिलो वातावरणका लागि उल्टो दिशामा काम गर्छ, र A मात्र क्लाइन्ट आधारअगाडि udp6 आफैं सिर्जना गरेको अवरोध हो। केवल हानिरहित चेतावनी शान्त पार्न परिवार बाध्य पार्नु यो गल्तीको पुरातन रूप हो, किनकि शान्त लगको बदलामा को जोडिन सक्छ भन्ने तपाईंले बदल्नुभयो।

अन्त्य बिन्दु र तिनीहरूसम्म पुग्नुपर्ने क्लाइन्टका आधारमा छान्नुहोस्। OpenVPN 2.6 पुस्तिका ले ढुवानी ढाँचाहरूको दस्तावेजीकरण गर्छ, र सन्देश त्यो छनोटको आउटपुट हो, त्यसको इनपुट होइन।

अभिलेख साँघुरो राख्नुहोस्

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

यो चेतावनीसँगै आउने प्याकेज सुझावहरू असम्बन्धित हुन्छन् जबसम्म कुनै त्रुटिले हराएको कार्यान्वयनयोग्य फाइलको नाम लिँदैन।

यदि ifconfig साँच्चै अनुपस्थित छ भने, स्क्रिप्टले त्यसलाई बोलाउँदा डेमनले नाम लिएर भन्छ, र त्यो आफ्नै अनुसन्धानको योग्य छ। AF_INET लाइन र अनुपस्थित उपयोगिता फरक असफलता हुन्, र चेतावनी बदलिन्छ कि भनेर हेर्न सामान स्थापना गर्नु सफा होस्ट फोहोर हुने बाटो हो।