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