OpenVPN پر SSH رک جاتا ہے؟ پہلے راستے کا MTU ناپیں

SSH جڑتا ہے، پرامپٹ ظاہر ہوتا ہے، اور کوئی کمانڈ کچھ بڑا واپس کرتے ہی سیشن مر جاتا ہے۔ ایکو تھوڑی دیر چلتا ہے، پھر رابطہ ختم ہو جاتا ہے جبکہ کلائنٹ اب بھی ٹنل کو چلتی دکھاتا ہے۔ جو سیشن ڈیٹا آنے تک صحت مند رہے وہ عام طور پر SSH کی خرابی سے نہیں، سائز کی حد سے ٹکراتا ہے۔ نیچے دی گئی جانچیں سب سے سستی وضاحت پہلے خارج کرنے کے ترتیب میں ہیں۔

پروفائل چھونے سے پہلے ناکامی کی شکل پڑھیں

چھوٹے پیکٹ گزرتے ہیں اور بھرے ہوئے نہیں۔ پرامپٹ، بینر یا ایک کلید دبانا آسانی سے سما جاتا ہے؛ فولڈر کی فہرست، ڈاؤن لوڈ یا چسپاں شدہ بلاک نہیں سماتا۔ جس سائز پر رویہ بدلتا ہے وہی سراغ ہے، یہ نہیں کہ SSH ہی متعلقہ پروگرام ہے۔

طریقہ یہ ہے: راستے کا MTU تلاش کرنا، جو ردعمل پر منحصر ہے. TCP ایک قطعہ سائز چنتا ہے، اور راستے کا کوئی راؤٹر بننے والا پیکٹ آگے نہ بھیج سکے تو اسے ICMP پیغام سے بتانا چاہیے۔ انکیپسولیشن بیرونی پیکٹ کو اندرونی سے بڑا کرتی ہے، اس لیے ٹنل کے اندر قابل استعمال سائز ہمیشہ طبعی رابطے سے نیچے رہتا ہے۔ ان ICMP پیغامات کو کہیں بھی فلٹر کر دیں تو بھیجنے والے کو کبھی تصحیح نہیں ملے گی، وہ بھرے قطعے بھیجتا رہے گا، اور بیرونی پیکٹ بغیر اطلاع کے پھینک دیا جائے گا۔

دونوں طرف سے حد ناپیں

دونوں میں سے کوئی ایک بدلنے سے پہلے ٹنل کے MTU کا طبعی رابطے سے موازنہ کریں۔ جس ٹنل نے طبعی قدر نقل کی ہے وہ پہلے ہی بتا چکی ہے کہ تضاد کہاں ہے۔

ٹنل کے اندر سے تقسیم ممنوع کرنے والی درخواست سے جانچیں، جواب آنے تک پے لوڈ کم کرتے جائیں۔ سائز کی دلیل صرف پے لوڈ گنتی ہے، اس لیے چلنے والا عدد ہمیشہ انٹرفیس MTU سے نیچے رہتا ہے۔ انٹرفیس کا عدد درکار ہو تو ہیڈر کے سائز دوبارہ شامل کریں۔

ip link show tun0
ping -M do -s 1380 10.9.0.1

ٹنل سے باہر سے سرور کے عوامی پتے کے خلاف جانچ دہرائیں۔ وہاں بھی بڑی جانچیں ناکام ہوں تو حد سرور تک کے راستے پر ہے اور ٹنل کا کوئی اختیار اسے نہیں ہلائے گا۔ یہ موازنہ آپ کو ایسے کلائنٹ کو ٹیون کرنے سے بچاتا ہے جو کبھی مسئلہ نہ تھا۔ کنفیگریشن فائل کھولنے سے پہلے دونوں نتائج لکھ لیں۔

mssfix اور fragment الگ کام کرتے ہیں

mssfix ٹنل کے اندرونی TCP رابطے اپنے مصافحے میں جو قطعہ سائز اعلان کرتے ہیں اسے محدود کرتا ہے۔ SSH، HTTPS اور فائل نقل کے لیے یہی درست لیور ہے، اسی لیے مقرر ہوتے ہی رکاوٹ اکثر غائب ہو جاتی ہے۔ یہ UDP پے لوڈ کو بالکل نہیں چھوتا۔

UDP سروس بھی اٹھانے والی ٹنل SSH ٹھیک ہونے کے بعد بھی ناکام رہ سکتی ہے، اور یہ نتیجہ ہر اُس شخص کو الجھاتا ہے جو سمجھتا ہے کہ ایک اختیار سب کچھ ڈھانپ لیتا ہے۔

fragment دوسرا طریقہ اور مختلف اوزار ہے۔ یہ انکیپسولیشن سے پہلے حد سے بڑے پیکٹ تقسیم کرتا ہے، صرف UDP ترسیل پر لاگو ہوتا ہے، ہر ڈیٹاگرام پر اضافی بوجھ ڈالتا ہے اور ٹوٹی ہوئی تلاش کے لیے آخری تدبیر کے طور پر درج ہے۔ دونوں ترتیبات ٹنل ختم کرنے والے ساتھیوں میں یکساں ہونی چاہئیں۔ جب ایک سرا محدود کرے اور دوسرا تقسیم کرے تو لاگ میں انتباہ اور ایسا رویہ پیدا ہوتا ہے جس کا فائلوں سے کوئی اندازہ نہیں لگا سکتا۔

انٹرفیس MTU گھٹانا موٹا اختیار ہے

دونوں سروں پر انٹرفیس MTU کم کرنا موٹا اوزار ہے۔ یہ ہر اندرونی بھیجنے والے کو چھوٹا عدد بتاتا ہے، جو چل جاتا ہے، اور یہ خرچ ضرورت مند TCP بہاؤں کے بجائے ساری ٹریفک پر ڈال دیتا ہے۔

اسے تب چنیں جب ٹنل ایسی ٹریفک لے کر چلے جسے آپ محدود نہیں کر سکتے، یا جب کلائنٹ ایسا آلہ ہو جس کا پروفائل آپ کے قابو میں نہ ہو۔ اسے ہم آہنگ طور پر لاگو کریں اور قدر پروفائل کے پاس لکھیں۔ آدھا لاگو کیا گیا بدلاؤ کچھ نہ کرنے سے بدتر ہے، کیونکہ یہ حل جیسا دکھتا ہے۔

جس منتقلی نے روکا اسی سے دوبارہ جانچیں

ترتیبات لوڈ ہونے کے لیے دوبارہ جڑیں، نئی رابطہ کھولیں اور جمی ہوئی کمانڈ دہرائیں۔ قطعہ سائز مصافحے کے وقت طے ہوتا ہے، اس لیے دوبارہ جڑنے سے گزرا سیشن اب بھی پرانی قدر اٹھائے ہوتا ہے۔ یہاں ping کمزور جانچ ہے، کیونکہ ساری ناکامی یہی ہے کہ چھوٹے پیکٹ گزر جاتے ہیں۔ وہی فہرست، ڈاؤن لوڈ یا چسپاں کرنا استعمال کریں جو ٹوٹا تھا۔

اگر چھوٹے سائز پر بھی رکاوٹ رہے تو کہیں اور دیکھیں: حالت رکھنے والا فائر وال جو بہاؤ ختم کر دے، دہرایا ہوا پتہ، یا ایسا راستہ جو دوبارہ جڑنے پر سرکتا ہو۔ ناکام جانچ کا سائز اور وہ ترتیب جو آپ نے بدلی لکھیں، کیونکہ یہی جوڑی اگلی رپورٹ کو کارآمد بناتی ہے۔