OpenVPN client-connect ناکامی: کیا disconnect پر صفائی کی ضمانت ہے؟
مسترد شدہ کلائنٹ فائر وال قاعدہ یا لکھا ہوا ریکارڈ واپس نہیں لیتا۔ callback معاہدے کا موازنہ اس rollback سے کریں جو آپ کے hook کو خود کرنا پڑتا ہے۔
جب client-connect اسکرپٹ غیر صفر کوڈ کے ساتھ باہر نکلتی ہے، OpenVPN کلائنٹ کو مسترد کر دیتا ہے، اور آپریٹر عام طور پر سمجھتے ہیں کہ متعلقہ client-disconnect اسکرپٹ سب کچھ ٹھیک کر دے گی۔ اکثر وہ کبھی چلتی ہی نہیں، کیونکہ disconnect کی کارروائی اس پر منحصر ہے کہ connect مرحلہ کیا مکمل کر سکا۔ مسترد کرنے اور rollback کو ایک ہی طریقہ سمجھنا ہی ناکام لاگ اِن کو لیک شدہ فائر وال قاعدے یا یتیم ریکارڈ میں بدل دیتا ہے۔ یہ دو الگ ذمہ داریاں ہیں، اور ان میں سے صرف ایک خودکار ہے۔ سرور پر حالت چھوڑنے کا الزام لگانے سے پہلے hook کا اپنا اخراجی راستہ پڑھیں۔
غیر صفر اخراج کلائنٹ کو مسترد کرتا ہے؛ یہ آپ کا کام واپس نہیں لیتا
client-connect کی اخراجی حیثیت داخلے کا فیصلہ ہے۔ صفر کا مطلب داخلہ، باقی کچھ بھی کا مطلب انسٹینس کو مکمل قائم ہونے سے پہلے ڈھا دینا۔ اس معاہدے میں کچھ بھی یہ نہیں دیکھتا کہ اسکرپٹ بیرونی دنیا کے ساتھ پہلے کیا کر چکی ہے۔ اگر اسکرپٹ نے iptables قاعدہ شامل کیا، سطر لکھی یا کاؤنٹر بڑھایا، تو وہ تبدیلیاں مسترد ہونے کے بعد بھی رہتی ہیں۔
یہی عدم توازن پلگ اِنز پر بھی لاگو ہے، جہاں ایک انسٹینس کے لیے کئی connect افعال چل سکتے ہیں۔ بعد کی ناکامی پہلے کی کامیابی کو پس پردہ منسوخ نہیں کرتی، اور پہلے فعل کے پاس یہ جاننے کا کوئی راستہ نہیں کہ ہمشیرہ فعل ناکام ہوا۔
مسترد کرنا خودکار ہے، صفائی نہیں
OpenVPN 2.6 دستی client-disconnect کی کارروائی کو پچھلی connect کارروائی کی کامیابی سے جوڑتا ہے۔ ایک دستاویزی استثنا کاسکیڈ زنجیروں کو محیط ہے: اگر ایک connect مرحلہ پہلے ہی کامیابی واپس کر چکا ہو، تو انسٹینس ڈھاتے وقت متعلقہ disconnect مراحل پھر بھی چلتے ہیں، چاہے بعد کا connect مرحلہ ناکام ہوا ہو۔ وہ استثنا تنگ ہے اور اس پر منحصر ہے کہ کتنے callback ترتیب دیے گئے ہیں، اسی لیے ایک shell اسکرپٹ کی جانچ زنجیر کے بارے میں کچھ نہیں بتاتی۔
ڈیزائن کرنے سے پہلے حقیقی ترتیب کا نقشہ بنائیں: کون سی اسکرپٹ، کون سا پلگ اِن اور کس ترتیب سے چلتے ہیں۔ نیچے دیا گیا جدول بتاتا ہے کہ ادھورا سیٹ اپ پیچھے کیا چھوڑتا ہے۔
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
ہر سطر کلائنٹ کے لیے یکساں اور ہوسٹ کے لیے مختلف طریقے سے ختم ہوتی ہے۔ کلائنٹ نہیں بتا سکتا کہ ان میں سے کون سا ہوا، اس لیے hook کو ناکامی کی حیثیت واپس کرنے سے پہلے اپنا کیا ہوا واپس لینا پڑتا ہے۔
ناکام اسکرپٹ کے اندر ہی تلافی کریں
مشترکہ حالت کو چھونے سے پہلے جو ممکن ہو سب تصدیق کریں: سرٹیفکیٹ کے میدان، پتے کی دستیابی، وہ گروہ جس سے کلائنٹ تعلق رکھتا ہے۔ سب سے سستا مسترد کرنا وہ ہے جو کسی بھی تقسیم سے پہلے ہو۔ جب سیٹ اپ کئی بیرونی کارروائیوں پر محیط ہو، تو ریکارڈ رکھیں کہ کون سی مکمل ہوئیں اور ناکامی کی حیثیت واپس کرنے سے پہلے انہیں الٹی ترتیب میں واپس لیں۔
ایک ٹھوس مثال: اسکرپٹ ہر کلائنٹ کے لیے فائر وال اندراج بناتی ہے، پھر اسے بیان کرنے والی حالت کی سطر لکھنے میں ناکام ہو جاتی ہے۔ ناکام شاخ کو ابھی بنایا گیا اندراج ہٹانا چاہیے اور پھر غیر صفر کوڈ کے ساتھ باہر نکلنا چاہیے۔ ایسے disconnect واقعے کا انتظار کرنا جو شاید کبھی طے نہ ہو، یہی وہ طریقہ ہے جس سے قاعدہ اپنے مقصود سیشن سے زیادہ زندہ رہتا ہے۔
تلافی کو idempotent اور مالک والا بنائیں
صفائی دو بار چلانے کے لیے محفوظ اور اس بارے میں درست ہونی چاہیے کہ کیا مٹا سکتی ہے۔ پچھلی کوشش کا دیر سے آیا واقعہ نئے سیشن کی تقسیم کو صرف اس لیے نہیں ہٹانا چاہیے کہ دونوں ایک مشترکہ نام یا دوبارہ استعمال شدہ ٹنل پتہ رکھتے ہیں۔ مخصوص ہینڈل یا آپریشن آئی ڈی کو وسیلے کے ساتھ ریکارڈ کریں، اور نام سے نہیں، اسی کلید سے حذف کریں۔ ڈیٹا بیس لین دین صرف ڈیٹا بیس کی اپنی تبدیلیوں میں مدد کرتے ہیں؛ اس حد سے باہر کا فائر وال قاعدہ واضح تلافی مرحلہ مانگتا ہے۔
فرض کریں کہ عمل تبدیلی اور صفائی کے درمیان مر سکتا ہے، اور ایک مصالحت کار شامل کریں جو شیڈول کے مطابق بیرونی حالت کا موازنہ منظور شدہ کلائنٹ فہرست سے کرے۔
وہ تین راستے جانچیں جو واقعی مختلف ہیں
تین حالتوں کی مشق کریں: کچھ بھی تقسیم ہونے سے پہلے مسترد، جزوی تقسیم کے بعد مسترد، اور بعد میں ختم ہونے والا عام منظور شدہ سیشن۔ وہ تین الگ لاگ سطریں اور الگ باقیات پیدا کرتے ہیں۔ ہر ایک کے بعد بیرونی حالت کی جانچ کریں، صرف کلائنٹ کے ناکامی پیغام کی نہیں، کیونکہ تین میں سے دو میں کلائنٹ کی ناکامی ہی متوقع نتیجہ ہے۔
hook کا مرحلہ، اخراجی حیثیت اور کیا تقسیم یا جاری ہوا، اسناد کو چھوڑ کر لاگ کریں۔ وہ hook لاگ جو اپنے بنائے گئے وسیلے کا نام لیتا ہے، وہی لیک شدہ قاعدے کو چھ ماہ بعد تلاش کرنے کے قابل بناتا ہے۔