VPN پر SSH ہر منٹ ٹوٹتا ہے؟ وجہ keepalive نہیں

SSH جڑتا ہے، تقریباً ایک منٹ کام کرتا ہے، پھر ہر بار تقریباً اسی وقفے پر جم جاتا ہے۔ عام وضاحت idle timeout ہے، اس لیے لوگ MTU کم کرتے ہیں اور کلائنٹ keepalives سیٹ کرتے ہیں۔ جس WireGuard لنک پر میں نے کام کیا وہ پہلے ہی یہ سب دیکھ چکا تھا: چھوٹا ٹنل MTU، client-alive سیٹنگز، کنفیگر شدہ ٹنل keepalive۔ ٹوٹنا بغیر تبدیلی کے جاری رہا۔ وجہ ایک غیر متوازی LAN راستہ نکلی، اور یہ نمونہ پہچاننے کے قابل ہے کیونکہ یہ ٹائمر پر مبنی ہر حل کو ہرا دیتا ہے۔

keepalive ثابت کرتا ہے کہ آپ کا ہوسٹ اب بھی بھیجنے کو تیار ہے۔ یہ حالت رکھنے والے آلے کو ایسا جواب نہیں دکھا سکتا جو کبھی اس سے نہیں گزرتا۔

افسانہ: keepalives خاموش ٹوٹنا ٹھیک کرتے ہیں

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

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

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

اضافی گیٹ وے اصل میں کیا کرتا ہے

لیپ ٹاپ اور VPN گیٹ وے کو ایک ہی LAN پر رکھیں، الگ LAN فائر وال کو ڈیفالٹ گیٹ وے بنائیں۔ لیپ ٹاپ VPN کی طرف جانے والا ٹریفک فائر وال کو بھیجتا ہے، فائر وال اسے گیٹ وے تک پہنچاتا ہے، اور گیٹ وے کے جوابات سیدھے LAN سے گزر کر لیپ ٹاپ کو واپس آتے ہیں۔ وہ دوسری ٹانگ کبھی فائر وال سے نہیں گزرتی، اس لیے اس کی حالت کی جدول آدھا کنکشن رکھتی ہے۔

نیچے دیے گئے پتے اسی ترتیب کو ظاہر کرتے ہیں:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

ری ڈائریکٹ اور حالت کی دیکھ بھال پھر کام کرنے والے handshake کو فوراً نہیں، بعد میں مرنے والے کنکشن میں بدل دیتی ہے۔ تاخیر حالت کے اندراج کے پرانے ہونے یا سخت جانچ ناکام ہونے سے ہے، اسی لیے وقفہ اتنا مشینی لگتا ہے۔

ان میں سے کچھ بھی کلائنٹ کنفیگریشن میں ظاہر نہیں ہوتا، اسی لیے اس کی تلاش عام طور پر غلط فائل میں شروع ہوتی ہے۔

ایک سوچا سمجھا راستہ چنیں

اوپر کی ترتیب کے لیے، دور دراز سب نیٹ کو سیدھا VPN گیٹ وے پر روٹ کرنا آدھا کنکشن ختم کر دیتا ہے:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

Netgate کے غیر متوازی روٹنگ پر نوٹس اسی انٹرفیس سطح کی غیر متوازی اور اس سے پیدا ہونے والے حالت کے مسائل بیان کرتے ہیں، اس لیے حالت کی دیکھ بھال کو عالمی طور پر ڈھیلا کرنے سے پہلے انہیں پڑھیں۔ اس معاملے جیسے وقت بندھے ڈس کنیکٹ اپنے آپ میں ثبوت نہیں ہیں۔ مضمون کو ناکامی کے ایک طریقے کی وضاحت سمجھیں، پھر عالمی حالت کی پالیسی بدلنے سے پہلے ثابت کریں کہ آپ کا اپنا نیٹ ورک اس سے میل کھاتا ہے۔

دونوں سروں سے جانچیں

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

حل کے بعد SSH دوبارہ کھولیں اور سیشن کو اس وقفے سے بہت آگے تک کھلا رکھیں جو پہلے ناکام ہوتا تھا۔ پھر منظور شدہ نیٹ ورک کنفیگریشن میں راستے کو مستقل بنائیں، کیونکہ ایک بار کا حکم ری بوٹ کا منصوبہ نہیں ہے اور اگلی ری بوٹ پر مسئلہ نئی معمہ کے ساتھ واپس آئے گا۔

غیر متوازی کب ٹھیک ہے

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

پائیدار جواب دونوں راستوں کے نام لیتا ہے، اس آلے کا نام لیتا ہے جسے دونوں دیکھنے ہیں، اور اس راستے کا نام لیتا ہے جو یہ ممکن بناتا ہے۔ اگر آپ آلے کا نام نہیں لے سکتے تو آپ نے ابھی وجہ نہیں پائی۔