ہر سائٹ پر دو WAN لنکس فالتو محسوس ہوتے ہیں جب تک آپ یہ ثابت کرنے کی کوشش نہ کریں کہ کسی مخصوص فلو نے واقعی کون سا ایڈریس جوڑا استعمال کیا۔ SRX پر ایک IKE گیٹ وے ایک بیرونی انٹرفیس اور ایک مقامی ایڈریس اٹھاتا ہے؛ دور کے امیدواروں کی فہرست دوسرا مقامی ماخذ نہیں بناتی۔ اسی لیے یہ رہنمائی کنفیگریشن سے نہیں بلکہ جوڑوں کے میٹرکس سے شروع ہوتی ہے، کیونکہ Junos بآسانی ایسا ڈیزائن commit کر دیتا ہے جو آپ کے ارادے کے صرف آدھے امتزاج ڈھکتا ہے۔ میں نے یہ دو SRX345s پر دیکھا: بیک اپ ٹنل صاف اٹھا اور پھر بھی واپسی پر سیشن گرا دیا۔

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

CLI چھونے سے پہلے جوڑوں کا نقشہ بنائیں

اگر سائٹ A، A1 یا A2 سے ماخذ لے سکتی ہے اور سائٹ B، B1 یا B2 پر وصول کر سکتی ہے، تو آپ کے پاس چار بیرونی ایڈریس جوڑے ہیں۔ زیادہ تر ڈیزائنوں کو ان میں سے دو مسلسل درکار ہوتے ہیں اور باقی دو اختیاری سمجھے جاتے ہیں۔ میٹرکس لکھیں اور ہر سطر کو نشان زد کریں، کیونکہ ہر وعدہ شدہ سطر بعد میں آپ کو ایک گیٹ وے، ایک ٹنل انٹرفیس اور ایک روٹنگ فیصلے کی قیمت پڑتی ہے۔

Local sourceRemote candidateRequired?
A1, ISP1 addressB1steady state
A1, ISP1 addressB2decide explicitly
A2, ISP2 addressB1decide explicitly
A2, ISP2 addressB2backup path

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

دور کی سائٹ کے لیے نہیں، ہر مقامی ماخذ کے لیے ایک گیٹ وے

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

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

پھر ٹنلوں کو جوڑیں اور دور کے پری فکس کو دو next hop دیں، ہر ٹنل کے لیے ایک:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

کہ ایک گیٹ وے address قسم کی دو ہدایات رکھ سکتا ہے یا نہیں، یہ ریلیز اور اس بات پر منحصر ہے کہ ڈیوائس کون سا IKE عمل چلا رہی ہے۔ kmd پر مبنی پرانا Junos فی گیٹ وے ایک ہی دور کا ایڈریس لیتا ہے؛ نئی builds کئی امیدوار سنبھالتی ہیں مگر اپنی قیود شامل کرتی ہیں، اور ہائی ایویلیبیلٹی کلسٹرز عام جگہ ہیں جہاں یہ سہارا تنگ ہو جاتا ہے۔ اسے پرانے چیسیس سے نقل کرنے سے پہلے اپنی عین build کے ریلیز نوٹس دیکھیں۔

تصدیق کریں کہ کون سی ایسوسی ایشن نے پیکٹ اٹھایا

دو SAs اور دو ٹنل یہ نہیں بتاتے کہ سیشن کس نے آگے بھیجا۔ ڈیوائس سے براہ راست پوچھیں اور فیلڈز کا موازنہ اس جوڑے سے کریں جو آپ کا ارادہ تھا:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

تفصیلی آؤٹ پٹ ہر ایسوسی ایشن کے لیے مقامی اور دور کا گیٹ وے بتاتی ہے، جو غیر متوقع ماخذ سے طے شدہ ٹنل کو پہچاننے کا تیز ترین طریقہ ہے۔ پھر ٹریفک گزارتے وقت st0.1 اور st0.2 پر فی اکائی پیکٹ کاؤنٹرز دیکھیں؛ جو ٹنل کچھ نہیں اٹھاتا وہ اپنا SA رکھتا ہے اور خلاصے میں صحت مند دکھتا ہے۔

ہر قسم کی خرابی کو اس کا اپنا ڈیٹیکٹر دیں

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

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

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

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

دوسرے کو چھوئے بغیر ایک لنک کو دوبارہ ایڈریس کریں

جب آئی ایس پی آپ کو نیا بلاک دے، ہر بار ایک رشتہ بدلیں۔ اس جوڑے کے لیے دونوں ساتھیوں پر address یا local-address اپ ڈیٹ کریں، commit کریں، اور ڈیوائس پر تمام SAs صاف کرنے کے بجائے صرف متاثرہ ایسوسی ایشنز کو انڈیکس کے حساب سے صاف کریں۔ عالمی صفائی صحت مند ٹنل بھی لے جاتی ہے اور دیکھ بھال کی ونڈو کو تعطل میں بدل دیتی ہے۔

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

تبدیلی کو مختصر چیک لسٹ کے ساتھ بند کریں

ڈوئل WAN ٹنل ڈیزائن تب مکمل ہوتا ہے جب آپ ہر سیشن کے پیچھے جوڑا نام لے سکیں، نہ کہ جب دونوں SAs اٹھ جائیں۔ نیچے دی گئی فہرست اس ڈیوائس پر دیکھیں جو آپ نے واقعی بدلی:

  • ہر وعدہ شدہ جوڑے کے پاس گیٹ وے، st0 اکائی اور روٹ اندراج ہے۔
  • ہر ٹنل کو پیکٹ اٹھاتے دیکھا گیا، صرف SA رکھتے نہیں۔
  • دونوں سرے شناخت اور اس بات پر متفق ہیں کہ کون سا پہلو ترجیح بحال کرتا ہے۔
  • ہر جوڑے کا واپسی راستہ اس کے جانے والے راستے کے ساتھ لکھا ہے۔

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

متعلقہ مضامین