IPsec מעל WAN פרטי: גבולות מדיניות ב-SRX שכדאי לבדוק

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

תעדו קודם את נתיב ה-IKE החיצוני

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

בדקו את המצב המותקן עם show security ike sa ואת התצורה עם show configuration security ike. הראשון מראה אם שלב 1 קיים; השני מראה מה המכשיר חושב שהוא אמור לעשות.

קשרו את ממשק המנהרה למדיניות הנכונה

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

קראו את הקישורים בפועל ולא תרשים ישן: show configuration security ipsec vpn עבור הגדרת הקישור לממשק ו-show configuration security policies עבור הכללים שמפנים לאזור המנהרה.

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

השאירו את נתיב העמית ב-underlay

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

בדקו זאת עם show route 198.51.100.10, כשמחליפים בכתובת העמית האמיתית, ואשרו שהצעד הבא אינו ממשק מנהרה.

אמתו בקרה ושירות לפי הסדר

עבדו מלמטה למעלה: מצב שלב 1, מצב שלב 2, ואז זרימת יישום אמיתית. show security ipsec sa מפרט את אסוציאציות האבטחה, ו-show security flow session destination-prefix 10.60.0.0/16 מראה אם נוצרים מושבים מועברים עבור הרשת המוגנת.

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

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