VPN של סניף על 4G: לשמור על זהות יציבה כשכתובת ה-IP זזה

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

היכן המנהרה חייבת להתחיל

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

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

הפרידו בין הכתובת שאליה מחייגים לבין הזהות שמתאימים

המוקד צריך משהו יציב להימצא בו, כתובת קבועה מאושרת או שם מארח מתוחזק. הסניף צריך דרך יציבה להיות מזוהה, וב-IKEv2 זהו מטען הזהות שהוא מציג במהלך האימות, ללא תלות בכתובת המקור שהחבילות שלו נושאות במקרה. מחרוזת כמו @branch-a.vpn.example עובדת כזהות הזו גם כשהכתובת הניידת משתנה בכל שעה.

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

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

כתבו את צד המוקד כעמית בעל שם

במונחי strongSwan צד המשיב הוא חיבור עם right=%any, שמקבל עמית מכל כתובת מקור, בתוספת [email protected], שנעצו את מה שהעמית הזה חייב להצהיר שהוא. הוסיפו rightsubnet=10.20.0.0/16 עבור רשתות ה-LAN של הסניף, auto=add כדי שהחיבור ייטען בלי חייג, dpd_delay=30s לצורך חיות, ו-mobike=yes כדי ששינוי כתובת ייספג ולא ייחשב כעמית חדש.

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

השאירו את הסניף כיוזם

בסניף חל התמונה המשתקפת: left=%defaultroute כדי שהכתובת הניידת המקומית תשמש כפי שהיא כעת, [email protected] להצגת הזהות, right=hub.example.com לשם המוקד היציב, ו-auto=start כדי שהמנהרה תעלה בלי אדם. כשהקישור הנייד מתחבר מחדש, הסניף יוזם שוב והמוקד מתאים את אותה זהות לאותו אובייקט מדיניות.

אפשרו IKE על UDP 500, מעבר NAT על UDP 4500, ואת ה-ESP העטוף שאחריו, בשני הצדדים. אחר כך השאירו אותם מותרים: כלל שנפתח רק בשעות העבודה ייראה כמו מנהרה לא רציפה.

בדקו את החלפת הכתובת, לא רק את לחיצת היד הראשונה

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

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

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