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 میں کسی ہوسٹ پر۔ پہلا ڈیٹا چینل ثابت کرتا ہے اور دوسرا فارورڈنگ۔