فیل اوور ٹیسٹ: کیا قائم شدہ TCP اسٹریم زندہ رہتا ہے؟

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

دو نتائج جو ایک ہی کامیابی جیسے لگتے ہیں

فرض کریں 10.90.0.42 پر ایک کلائنٹ کا 198.51.100.20:443 سے کنکشن ہے۔ بنیادی ایگزٹ اسے ایک عوامی پتہ اور پورٹ میں بدلتا ہے، اور بیک اپ ایگزٹ دوسرے میں۔ کلائنٹ کا اندرونی پتہ کبھی نہیں بدلتا، اسی لیے لوگ توقع کرتے ہیں کہ کنکشن زندہ رہے گا۔

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

اس لیے پرانی اسٹریم وقت ختم ہو کر ختم ہوتی ہے جبکہ اسی سروس سے نئی کنکشن فوراً کام کرتی ہے۔ دونوں مشاہدے ایک ساتھ درست ہیں۔

جب ایگزٹ بدلتا ہے تو سرور کیا دیکھتا ہے

TCP کنکشن اپنے چوکڑی سے پہچانا جاتا ہے، اور ماخذ پتہ یا پورٹ بدلنے سے وصول کرنے والے ہوسٹ کے لیے الگ کنکشن بنتا ہے۔ سرور کی ناواقف کنکشن پر نئے ماخذ سے آنے والے پیکٹ گرا دیے جاتے ہیں یا ری سیٹ سے جواب دیا جاتا ہے۔ VPN کلائنٹ کے پتے میں کچھ بھی اس تبدیلی کے دوران تعلق نہیں بچاتا۔

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

کسی کو تسلسل کا وعدہ کرنے سے پہلے جانچیں کہ جوڑی واقعی حالت رکھتی ہے۔ نیچے دیے گئے احکام دونوں طرف کی موجودہ حالت دکھاتے ہیں۔

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

ایک ہی عوامی پتہ کیوں کافی نہیں

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

RFC 3022 پتوں کے ترجمے کی وضاحت کرتا ہے اور ترجمہ کرنے والے آلات کے درمیان حالت کے تبادلے کو بیک اپ ڈیزائن کا حصہ مانتا ہے۔ تیرتا پتہ یا نقل شدہ پروفائل ترتیب کو ہلاتا ہے مگر حالت نہیں ہلاتا۔

اسی لیے صرف بیک اپ سے پنگ کرنے والا ٹیسٹ بہت کم ثابت کرتا ہے۔ پنگ کے پاس کھونے کو کوئی کنکشن حالت نہیں۔

فیصلہ کریں کہ ضرورت کتنی مضبوط ہے

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

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

واضح کہیں کہ بنیادی راستہ واپس آنے پر کیا ہوتا ہے، کیونکہ خودکار واپسی ایسی کنکشن کاٹ سکتی ہے جو ابھی بیک اپ پر بحال ہوئی تھی۔ وہ معاملہ ٹیسٹ منصوبے کا ہے، حاشیے کا نہیں۔

پرانی اسٹریم اور نئی درخواست جانچیں

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

تین قدریں بتائیں: پرانی اسٹریم جاری رہی، ری سیٹ ہوئی یا وقت ختم ہو کر ختم ہوئی؛ نئی کارروائی پہلی بار کب چلی؛ اور واپسی نے کچھ توڑا یا نہیں۔ وہی تین سطریں قبولیت کا ریکارڈ ہیں۔

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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