Junos Dual-WAN IPsec VPN: התאמת נתיב המקור לשער הנכון

שני קישורי WAN לאתר נראים כמו יתירות עד שמנסים להוכיח איזו זוג כתובות תעבורה מסוימת באמת השתמשה בו. ב-SRX שער IKE אחד נושא ממשק חיצוני אחד וכתובת מקומית אחת; רשימת מועמדים מרוחקים אינה יוצרת מקור מקומי שני. לכן הסיור הזה מתחיל במטריצת הזוגות ולא בתצורה, כי Junos יבצע commit בלי היסוס לתכנון שמכסה רק חצי מהשילובים שהתכוונתם אליהם. נתקלתי בזה בשני SRX345s: מנהרת הגיבוי עלתה נקי ובכל זאת הפילה את הסשן בחזרה.

עברו על השלבים לפי הסדר: פרטו את הזוגות שעליכם לתמוך בהם, בנו שער אחד לכל מקור מקומי, אשרו איזו אסוציאציה נשאה את התנועה, ורק אחר כך החליטו מה כל סוג כשל רשאי לשנות.

מפו את הזוגות לפני שנוגעים ב-CLI

אם אתר A יכול לשלוח מ-A1 או A2 ואתר B יכול לקבל על B1 או B2, יש לכם ארבעה זוגות כתובות חיצוניים. רוב התכנונים זקוקים לשניים מהם באופן קבוע ומתייחסים לשניים האחרים כאופציונליים. כתבו את המטריצה וסמנו כל שורה, כי כל שורה שתבטיחו תעלה לכם בהמשך שער, ממשק מנהרה והחלטת ניתוב.

כל זוג נדרש צריך שלושה דברים בבת אחת: 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 מקבלות כתובת מרוחקת אחת לכל שער; 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 במתקן. מחיקה גורפת מסירה גם את המנהרה הבריאה והופכת חלון תחזוקה להפסקה.

שמרו תעבורה כושלת אחת ואת פרטי הסשן שלה כראיה לפני שאתם מנקים משהו, ואז הריצו שוב את הבדיקות למעלה מול זוג הכתובות החדש. שחזור קישור הוא החלטת ניתוב, לכן התייחסו לחזרה כשלב נבדק בפני עצמו במקום להניח שההעדפה הישנה חוזרת מעצמה.

סגרו את השינוי ברשימת בדיקה קצרה

תכנון מנהרת dual-WAN מוכן כשאתם יכולים לנקוב בשם הזוג שמאחורי כל סשן, לא כששני ה-SAs למעלה. עברו על הרשימה למטה במתקן שבאמת שיניתם:

• לכל זוג מובטח יש שער, יחידת st0 ורשומת נתיב.
• כל מנהרה נראתה נושאת חבילות, לא רק מחזיקה SA.
• שני הקצוות מסכימים על הזיהוי ועל איזה צד משחזר את ההעדפה.
• נתיב החזור של כל זוג כתוב לצד נתיב ההלוך שלו.

אם שורה נכשלת, תקנו את אותו זוג לפני שתוסיפו את הבא; ערימת שתי מנהרות שעובדות למחצה הופכת את המונים לחסרי משמעות ואת התנהגות ה-failover לבלתי צפויה.