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-এর একটি হোস্টে। প্রথমটি ডেটা-চ্যানেল প্রমাণ করে আর দ্বিতীয়টি ফরওয়ার্ডিং।