برابر لاگت والے راستے VPN کی خرابیوں کو دیکھنا مشکل کیوں بناتے ہیں
جب کئی ٹنل ایک ہی لاگت بانٹتے ہیں تو ہر فلو مختلف منتخب کر سکتا ہے۔ کامیاب ping اس راستے کے بارے میں کچھ نہیں بتاتا جو آپ کی ایپلیکیشن واقعی استعمال کرتی ہے۔
ایک صارف بتاتا ہے کہ اندرونی ایپلیکیشن ایک مشین سے کام کرتی ہے اور دوسری سے ناکام ہوتی ہے، جبکہ گیٹ وے سے چلایا گیا ping دونوں صورتوں میں کامیاب ہوتا ہے۔ ایک ہی لاگت والے کئی ٹنلوں کے ساتھ یہ تضاد نہیں۔ ہر فلو اپنے اگلے ہاپ پر رکھا جاتا ہے، اس لیے آپ کی جانچ اور صارف کا سیشن محض مختلف راستے استعمال کر رہے ہوں گے۔ نیچے دی گئی وضاحت کچھ بھی بدلنے سے پہلے وہی انتخاب دوبارہ پیدا کرتی ہے۔
ایک ping، کئی ممکنہ راستے
جب کسی راستے میں ایک ہی لاگت پر ایک سے زیادہ اگلے ہاپ ہوں تو راؤٹر کو ہر پیکٹ کے لیے ایک منتخب کرنا پڑتا ہے۔ زیادہ تر عمل درآمد پیکٹ کے فیلڈز کا ہیش بناتے ہیں، عام طور پر ماخذ اور منزل کے پتے پروٹوکول اور پورٹس کے ساتھ، تاکہ جوابات اسی راستے پر رہیں۔ مختلف ایپلیکیشنز، یا ایک ہی ایپلیکیشن کے مختلف کنکشن بھی مختلف ہیش بناتے ہیں۔
اسی لیے گیٹ وے سے کیا گیا تشخیص اتنا کم ثابت کرتا ہے۔ گیٹ وے کی اپنی جانچ کے اپنے پتے اور پورٹس ہوتے ہیں، اور اسی لیے اپنا ہیش بھی۔ یہ صحت مند ٹنل پر اتر سکتا ہے جبکہ صارف خراب ٹنل پر اترتا رہتا ہے۔
پلیٹ فارم اگلا ہاپ کیسے منتخب کرتا ہے
اندازہ لگانے کے بجائے انتخاب دوبارہ پیدا کریں۔ کرنل سے پوچھیں کہ ناکام سیشن جیسے ہی ماخذ اور منزل کے لیے کون سا راستہ استعمال کرے گا۔ اس تلاش میں وہ فیلڈز بھی شامل ہیں جنہیں عام منزل کی تلاش نظر انداز کرتی ہے۔ اسے کام کرنے والے کلائنٹ سے بھی چلائیں اور دونوں جوابات کا موازنہ کریں:
ip route get 10.20.5.7 from 10.20.0.14نئے iproute2 ورژن پروٹوکول اور منزل پورٹ بھی قبول کرتے ہیں، جو اس وقت اہم ہے جب ہیش انہیں شامل کرے۔ اس آؤٹ پٹ کا موازنہ کام کرنے والے کلائنٹ سے کی گئی اسی تلاش سے کریں، اور فرق ہی آپ کا گمشدہ ثبوت ہے۔
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
ناکام فلو کی پیروی کریں، روٹ ٹیبل کی نہیں
روٹ ٹیبل دونوں ٹنل درج کرتا ہے اور تعریف کے مطابق درست دکھتا ہے۔ سوال یہ ہے کہ منتخب ہونے کے بعد ہر ٹنل پیکٹ کے ساتھ کیا کرتا ہے۔ تصدیق کریں کہ دونوں ایک ہی محفوظ پری فکس، ایک ہی فارورڈنگ اجازت اور اسی کلائنٹ تک پہنچنے والا واپسی راستہ رکھتے ہیں۔
درمیان میں موجود حالت والے آلات پر توجہ دیں۔ اگر درخواست ایک ٹنل سے نکلے اور جواب دوسری سے واپس آئے، تو جس فائر وال یا NAT نے اصل فلو کبھی نہیں دیکھا، وہ اسے گرا دے گا۔ دونوں ٹنل ٹریفک صحیح طور پر فارورڈ کرتے ہیں، اور کنکشن پھر بھی ناکام ہوتا ہے۔
ہر راستے پر MTU بھی جانچیں۔ اضافی انکیپسولیشن والا راستہ قابل استعمال سائز کم کر دیتا ہے، اور ایک ٹنل پر کامیاب ہونے والی منتقلی دوسری پر ٹھیک اسی سائز پر رک جاتی ہے جہاں چھوٹی ٹنل ٹوٹتی ہے۔
ایک وقت میں ایک راستے کا موازنہ کریں
جہاں ڈیزائن دیکھ بھال کی اجازت دیتا ہے، وہاں ایک ٹنل سروس سے ہٹائیں اور صارف کا کام دہرائیں۔ اگر خرابی ختم ہو جائے تو مسئلہ اسی راستے کا ہے جو آپ نے ہٹایا، اور اگلا قدم روٹنگ ٹیبل دوبارہ جانچنے کے بجائے اس کی کنفیگریشن کا ہمسایہ سے موازنہ کرنا ہے۔
بار بار ping نہیں، اصل ایپلیکیشن کا موازنہ کریں۔ درج کریں کہ خرابی کسی مخصوص اگلے ہاپ، پیکٹ سائز یا دوبارہ جڑنے کے بعد کی تبدیلی کی پیروی کرتی ہے یا نہیں، کیونکہ یہ تین نمونے مختلف مرمتوں کی طرف اشارہ کرتے ہیں۔
آخر میں لکھیں کہ راستوں کو مساوی کیوں سمجھا جاتا ہے اور خرابی کو ایک کو سروس سے کیسے ہٹانا چاہیے۔ ملٹی پاتھ صرف اسی وقت محفوظ ہے جب راستے واقعی بدلے جا سکنے والے ہوں، اور یہ فرض کرنے کے بجائے جانچنے کے قابل ڈیزائن کا بیان ہے۔