peer کے دوبارہ بوٹ کے بعد strongSwan نیچے رہتا ہے: ایک ٹنل بحال کریں

دور دراز گیٹ وے دوبارہ بوٹ ہوتا ہے، ایک منٹ میں واپس آتا ہے، اور مقامی strongSwan daemon چلتا رہتا ہے جبکہ ٹنل اب بھی نیچے ہے۔ ESTABLISHED تلاش کر کے daemon دوبارہ شروع کرنے والا cron کام بالآخر اسے ڈھک دے گا، اور مشین پر ہر غیر متعلقہ ٹنل بھی کاٹ دے گا، جبکہ ممکن ہے ناکام ہونے والی ٹنل ہی چھوٹ جائے۔ بحالی اُس کنکشن کی ہے جسے واپس آنا ہے، اور یہ ایسی سیٹنگز میں ظاہر ہوتی ہے جو reload برداشت کرتی ہیں۔ یہ رن بک اسے ایک کنکشن کے لیے ترتیب دیتی ہے اور نتیجہ نام سے ثابت کرتی ہے۔

عالمی دوبارہ آغاز چھوڑ دیں، اس کے شواہد رکھیں

daemon کے دوبارہ آغاز میں دو واضح خامیاں ہیں: یہ ہر کنکشن کی حالت تباہ کر دیتا ہے، اور یہ نہیں بتاتا کہ اصل میں کون سا واقعہ ناکام ہوا۔ آپ کا تلاش کردہ اسٹیٹس متن کسی دوسرے کنکشن سے آیا ہو سکتا ہے، جبکہ مطلوبہ child بیکار بیٹھا تھا کیونکہ کسی چیز نے اسے شروع نہیں کیا۔

کچھ بھی بدلنے سے پہلے لوڈ شدہ کنکشن اور فعال انجمنیں پڑھیں، تاکہ peer کے واپس آنے پر موازنے کے لیے آپ کے پاس پہلے کی تصویر ہو۔

swanctl --list-conns
swanctl --list-sas

آغاز اور دوبارہ کوششیں واپس آنے والے کنکشن پر رکھیں

swanctl.conf تعیناتی میں یہ سیٹنگز عالمی پالیسی میں نہیں، کنکشن اور child کی سطح پر رہتی ہیں۔ نیچے دیا گیا ٹکڑا آغاز کرنے والے کی طرف سے مثال ہے جو فرض کرتا ہے کہ تجاویز، تصدیق اور منتخب کنندگان پہلے ہی درست ہیں۔

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action طے کرتا ہے کہ child لوڈ ہونے پر کیا ہوتا ہے: start فوراً شروع کرتا ہے، جبکہ trap ایسی پالیسی نصب کرتا ہے جو موزوں ٹریفک آنے پر آغاز کو متحرک کرتی ہے۔ trap|start لکھنے کے لیے strongSwan 5.9.6 یا نیا درکار ہے، اس لیے سطر نقل کرنے سے پہلے ورژن دیکھیں۔ dpd_action=restart peer کے مردہ قرار دیے جانے پر نئی گفت و شنید مانگتا ہے، اور کنکشن سطح کا keyingtries=0 کامیابی یا مستقل خرابی تک مزید کوششوں کی اجازت دیتا ہے۔ IKEv2 کے تحت dpd_timeout کا کوئی اثر نہیں ہوتا، کیونکہ عام دوبارہ ترسیل ہی طے کرتی ہے کہ peer کب جواب نہیں دے رہا۔

اُس مثال میں تاخیر ایک نقطۂ آغاز ہے، عالمگیر مہلت نہیں۔ اسے peer کے دوبارہ بوٹ کے دورانیے اور اس بات کی بنیاد پر چنیں کہ آپ کتنی دوبارہ ترسیل برداشت کر سکتے ہیں۔

جانیں کہ آپ کس واقعے سے بحالی کر رہے ہیں

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

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

daemon کی حالت سے نہیں، نام سے تصدیق کریں

جب peer اب بھی نیچے ہے تو کنکشن اور اس کا child نام سے پڑھیں، پھر واپس آنے پر دوبارہ پڑھیں؛ ان دو آؤٹ پٹس کا فرق ہی ثبوت ہے۔

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

پھر انجمن نہیں، سروس کی تصدیق کریں۔ نیا child سیکیورٹی انجمن اور اس کے پیچھے نجی منزل پر کامیاب درخواست—یہی دو حقیقتیں اہم ہیں، اور صحت مند غیر متعلقہ ٹنل کے ساتھ چلتا daemon دونوں میں سے کوئی ثابت نہیں کرتا۔

اگر child کبھی آغاز نہ کرے تو دیکھیں کہ ٹیسٹ ٹریفک کنفیگر شدہ منتخب کنندگان سے بالکل مطابقت رکھتی ہے، پروٹوکول اور پورٹ سمیت۔ اگر آغاز کر کے ناکام ہو تو لامتناہی لوپ کے پیچھے چھپانے کے بجائے تصدیق یا تجویز کی خرابی پڑھیں، کیونکہ keyingtries=0 مستقل انکار ہمیشہ دہراتا رہے گا۔

تبدیلی ونڈو میں لوڈ کریں اور دوبارہ جانچیں

reload daemon کے دوبارہ آغاز سے محفوظ تر ہے، اور پھر بھی مفت نہیں: child کو بدلنا یا اتارنا شروع شدہ انجمن بند کر سکتا ہے یا اس کا trap گرا سکتا ہے۔

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

swanctl --load-conns
swanctl --list-conns

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