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 वरील होस्टवर। पहिले डेटा-चॅनेल सिद्ध करते आणि दुसरे फॉर्वर्डिंग।