כיצד עוטף מעבר NAT את ESP בתוך UDP

שני לקוחות מאחורי אותו נתב מדברים עם שער IPsec אחד, ואחד ממשיך ליפול בזמן שהשני נשאר מחובר. ESP המקורי הוא פרוטוקול IP 50 בלי פורטים, ולכן למתרגם אין על מה לתלות מיפוי כשכמה לקוחות חולקים כתובת אחת. מעבר NAT סוגר את הפער הזה על ידי עטיפת ESP ב-UDP בפורט 4500, והכותרת הזו מסבירה את רוב התסמינים שיבואו. היא גם מצביעה על ההתקן שצריך לשנות.

למה מישור הנתונים עובר לפורט 4500

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

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

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

הוכיחו קודם את חילופי הבקרה, אחר כך את נתיב הנתונים, ושמרו את השניים בנפרד בהערות. לכידה שמראה תעבורה ב-500 ואף פעם לא ב-4500 בדרך כלל אומרת שנתיב הנתונים מסונן, ולכן התיקון שייך לכלל חומת האש ולא ללקוח.

עקבו אחרי שני הפורטים עם tcpdump -ni any 'udp port 500 or udp port 4500', וקראו את טבלת התרגום בנתב בזמן שהפעלה חיה. הטבלה הזו מראה את פורט המקור שהשער יראה בפועל, ולכידה במחשב הנייד חולקת עליה בתכנון: המחשב מאמין 500 בעוד השער רואה 4500 עם פורט מקור מתורגם, ושניהם צודקים. אותה זרימה, לפני ואחרי התרגום:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

תסמינים שהעטיפה מסבירה, ושניים שהיא לא מסבירה

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

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

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

שנו את הבעלים של המיפוי, ואז בדקו שוב

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

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