TUN/TAP: अवैध आर्गुमेन्ट — OpenVPN फ्रेमिङ मिलेन

क्लाइन्ट प्रमाणीकरण गर्छ, लग जोडिएको भन्छ, र कुनै प्याकेट टनेल पार गर्दैन। सर्भर write to TUN/TAP: Invalid argument (code=22) सँग प्रयास अन्त्य गर्छ, जुन ड्राइभर खराबी जस्तो देखिन्छ र सामान्यतया त्यस्तो हुँदैन। राउटर र साना Linux सर्भरमा त्यो लाइनले प्रायः दुई छेउ डेटा-प्याकेट कसरी फ्रेम गर्ने भन्नेमा सहमत नभएको जनाउँछ, त्यसैले कर्नेलले आफूलाई दिइएको डिक्रिप्ट गरिएको बफर अस्वीकार गर्छ। त्यो बिन्दुमा राउटिङ अझै परीक्षण गरिएको छैन।

सही राउटिङ तालिका र भाँचिएको फ्रेमिङ सम्झौता क्लाइन्टको तर्फबाट उस्तै देखिन्छ: जोडिएको, र केही पनि काम गर्दैन।

टनेल माथि आउँछ र यसलाई केहीले पार गर्दैन

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

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

कम्प्रेसन फ्रेमिङ हो, ब्यान्डविथ होइन

कम्प्रेसन सक्रिय हुँदा प्रत्येक डेटा-प्याकेटले कसरी इन्कोड गरिएको थियो वर्णन गर्ने हेडर बोक्छ, र दुवै छेउ त्यो हेडरमा सहमत हुनुपर्छ। पुरानो नमुना कन्फिगरेसनबाट अझै comp-lzo बोक्ने सर्भर, कम्प्रेसन लाइन नभएको क्लाइन्टसँग जोडिँदा ठ्याक्कै यही त्रुटि उत्पन्न गर्छ: सर्भरले क्लाइन्टले कहिल्यै नलेखेको हेडर अपेक्षा गर्छ। comp-lzo लाई compress lz4-v2 सँग मिसाउनु पनि त्यही तरिकाले असफल हुन्छ, किनभने दुवैलाई कम्प्रेसन भनिए पनि एल्गोरिदम फरक छन्। आधुनिक लिंकमा यो विकल्प ब्यान्डविथ सुविधा होइन, फ्रेमिङ सम्झौता हो।

संस्करणको व्यवहारले एउटा जाल थप्छ। 2.5 शृंखलाले कम्प्रेसन विकल्पका लागि अप्रचलित चेतावनी दिन सुरु गर्‍यो, र 2.6 ले कम्प्रेस गरिएका प्याकेट अस्वीकार गर्ने र डेटा केवल नकम्प्रेस राख्नेबीच रेखा तान्छ। त्यसैले राउटर फर्मवेयर अपडेटले कसैले टनेल सम्पादन नगरी प्रभावकारी सम्झौता बदल्न सक्छ।

दुवै छेउ मिलाउनुहोस् वा दुवैबाट हटाउनुहोस्

प्रत्येक कम्प्रेसन निर्देश गन्नुहोस्: सर्भर फाइल, कुनै पनि पुश गरिएका विकल्प, क्लाइन्ट-विशिष्ट फाइलहरू र क्लाइन्ट प्रोफाइल। सर्भरमा comp-lzo लाई क्लाइन्टमा त्यही शब्द चाहिन्छ, र adaptive पुरानो बिल्डमा खाली विकल्पले सामान्यतया जनाउने पुरानो डिफल्ट हो। LZO वा कम्प्रेसन लेबल भएको राउटरको GUI स्विचले त्यही विकल्प लेख्छ, त्यसैले एल्गोरिदम मिसाउने सट्टा मिल्ने गरी सेट गर्नुहोस्। मिल्दो देखिने नाम अनुकूल छ भनेर नमान्नुहोस्।

कम्प्रेसन नचाहिएमा दुवै छेउबाट जानाजान हटाउनुहोस्। सर्भरमा allow-compression no कम्प्रेस गरिएका प्याकेट अस्वीकार गर्छ, तर क्लाइन्टहरूले ती दिन बन्द गरेपछि मात्र; क्लाइन्टले अझै कम्प्रेसन पठाइरहेको बेला लागू गर्नाले अर्को दिशामा असंगति फेरि सिर्जना हुन्छ।

पुश र उपकरणको प्रकार जाँच्नुहोस्

सर्भरले आफ्नो मुख्य फाइल वा क्लाइन्ट-विशिष्ट फाइलबाट कम्प्रेसन निर्देश पुश गर्न सक्छ, र क्लाइन्टले pull-filter सँग पुश गरिएका विकल्प छोड्न सक्छ। भर्बोसिटी 4 मा एक क्लाइन्ट जोड्नुहोस्, सर्भरले घोषणा गरेको र क्लाइन्टले स्वीकार गरेको तुलना गरेर पढ्नुहोस्, त्यसपछि कुनै फिल्टरले त्यो हटाएको छैन भनेर पुष्टि गर्नुहोस्। दुवै पक्ष अहिले सहमत भएर पनि त्रुटि रहेमा, उपकरणको प्रकार हेर्नुहोस्: एउटा छेउमा dev tap र अर्कोमा dev tun फ्रेम साटासाट गर्न सक्दैनन्, र कर्नेलले पनि त्यही तरिकाले लेखन अस्वीकार गर्छ।

ब्रिज गरिएको TAP तैनातीका लागि सर्भरमा वास्तविक ब्रिज चाहिन्छ, केवल फरक उपकरण नाम होइन। इन्टरफेसलाई ब्रिजमा नजोडी tap0 नाम दिँदा लेखन स्वीकार गर्ने तर कतै नजाने उपकरण बन्छ।

त्यसपछि एक क्लाइन्ट र एक गन्तव्यसँग प्रमाणित गर्नुहोस्: सर्भरको टनेल ठेगानामा पिङ गर्नुहोस्, त्यसपछि त्यसको LAN मा रहेको होस्टमा। पहिलोले डेटा-च्यानल र दोस्रोले फर्वार्डिङ प्रमाणित गर्छ।