VPN دو WAN با IPsec در Junos: تطبیق مسیر مبدأ با دروازهٔ درست
مروری بر SRX در Junos برای IPsec دو WAN: هر مبدأ محلی را با دروازههای نامزدش جفت کنید و سپس ثابت کنید کدام انجمن واقعاً ترافیک را حمل کرده است.
دو لینک WAN در هر سایت شبیه افزونگی به نظر میرسد تا زمانی که بخواهید ثابت کنید یک جریان مشخص واقعاً از کدام جفت آدرس استفاده کرده است. روی SRX، یک دروازهٔ IKE یک رابط خارجی و یک آدرس محلی را حمل میکند؛ فهرست نامزدهای راه دور منبع محلی دوم نمیسازد. به همین دلیل این مرور با ماتریس جفتها آغاز میشود نه با پیکربندی، چون Junos با خیال راحت طرحی را commit میکند که فقط نیمی از ترکیبهای موردنظر را پوشش میدهد. من این را روی دو SRX345s دیدم: تونل پشتیبان تمیز بالا آمد و با این حال هنگام بازگشت جلسه را پایین کشید.
مراحل را به ترتیب طی کنید: جفتهایی را که باید پشتیبانی کنید فهرست کنید، برای هر مبدأ محلی یک دروازه بسازید، تأیید کنید کدام انجمن ترافیک را حمل کرده و تنها پس از آن تصمیم بگیرید هر نوع خرابی چه چیزی را میتواند تغییر دهد.
پیش از دست زدن به CLI جفتها را نقشه کنید
اگر سایت A میتواند از A1 یا A2 مبدأ بگیرد و سایت B میتواند روی B1 یا B2 دریافت کند، چهار جفت آدرس بیرونی دارید. بیشتر طرحها دو تای آنها را پیوسته لازم دارند و دو تای دیگر را اختیاری میدانند. ماتریس را بنویسید و هر ردیف را علامت بزنید، چون هر ردیفی که وعده میدهید بعداً برایتان یک دروازه، یک رابط تونل و یک تصمیم مسیریابی هزینه دارد.
| Local source | Remote candidate | Required? |
|---|---|---|
| A1, ISP1 address | B1 | steady state |
| A1, ISP1 address | B2 | decide explicitly |
| A2, ISP2 address | B1 | decide explicitly |
| A2, ISP2 address | B2 | backup 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 را اجرا میکند بستگی دارد. Junos قدیمیتر مبتنی بر kmd برای هر دروازه یک آدرس دور میپذیرد؛ بیلدهای جدیدتر چند نامزد را مدیریت میکنند اما محدودیتهای خودشان را اضافه میکنند، و خوشههای دسترسپذیری بالا جایی رایجاند که این پشتیبانی باریکتر میشود. پیش از کپی کردن این از یک شاسی قدیمیتر، یادداشتهای انتشار بیلد دقیق خود را بررسی کنید.
تأیید کنید کدام انجمن بسته را حمل کرده است
دو SA و دو تونل نمیگویند کدامیک جلسه را جلو برده است. مستقیماً از دستگاه بپرسید و فیلدها را با جفتی که در نظر داشتید مقایسه کنید:
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 بزنید و فقط انجمنهای متأثر را بر اساس نمایه پاک کنید نه همهٔ SAهای دستگاه. پاکسازی سراسری تونل سالم را هم میبرد و پنجرهٔ نگهداری را به قطعی تبدیل میکند.
پیش از پاکسازی هر چیزی، یک جریان ناموفق و جزئیات جلسهاش را بهعنوان مدرک نگه دارید، سپس بررسیهای بالا را روی جفت آدرس جدید تکرار کنید. بازگرداندن لینک یک تصمیم مسیریابی است، پس بازگشت را گامی مستقل و آزموده بدانید نه اینکه فرض کنید اولویت قدیمی خودبهخود برمیگردد.
تغییر را با یک چکلیست کوتاه ببندید
طرح تونل دو WAN زمانی تمام است که بتوانید جفت پشت هر جلسه را نام ببرید، نه وقتی هر دو SA بالا هستند. فهرست زیر را روی دستگاهی که واقعاً تغییر دادید مرور کنید:
- هر جفت وعدهدادهشده یک دروازه، یک واحد st0 و یک ورودی مسیر دارد.
- هر تونل در حال حمل بسته دیده شده، نه فقط در حال نگه داشتن SA.
- دو انتها بر سر تشخیص و اینکه کدام سمت اولویت را بازمیگرداند توافق دارند.
- مسیر بازگشت هر جفت کنار مسیر رفتش نوشته شده است.
اگر ردیفی رد شود، آن جفت را پیش از افزودن جفت بعدی درست کنید؛ روی هم گذاشتن دو تونل نیمهکاره شمارندهها را بیمعنا و رفتار failover را غیرقابل پیشبینی میکند.