L2TP/IPsec דרך NAT: מה באמת נשבר ולמה

הטענה ש-NAT שובר את L2TP/IPsec נכונה למחצה ולכן חסרת תועלת. תרגום כתובות הוא דבר רגיל, NAT traversal קיים בדיוק כדי לשרוד אותו, ומיליוני לקוחות מתחברים מדי יום מאחורי נתב. מה שנשבר הוא שלב מסוים של חילוף מסוים: IKE לא מקבל תשובה, המנהרה העטופה נזרקת על ידי מדיניות שמתירה פרוטוקול אחד בלבד, או שהמיפוי של התרגום פג בזמן שהמנהרה לא פעילה. ברגע שיודעים באיזה שלב אתם נמצאים, התיקון הוא בדרך כלל מספיק: כלל אחד או keepalive, ולא תכנון VPN חדש.

המיתוס הוא השאלה הלא נכונה

השאלה המועילה אינה “האם NAT שובר את זה” אלא “איזה חלק מהחילוף מתורגם, ומה ההתקן שמתרגם עושה איתו”. L2TP/IPsec הוא פרוטוקול שכבתי: IKE מנהל משא ומתן, ESP מגן, והפרוטוקול L2TP נושא PPP בתוך ההגנה הזו. תרגום כתובות פועל אחרת על כל שכבה, וחתימות הכשל ניתנות להבחנה אם מסתכלים על שלב המשא ומתן ולא על תיבת השגיאה.

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

שלב 1: IKE חייב לקבל תשובה בכלל

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

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

שלב 2: העטיפה משנה את מה שחומת האש רואה

ESP הוא פרוטוקול IP, לא פורט TCP או UDP, ותרגום כתובות פורטים רגיל אינו כולל שדה פורט לשכתב. לכן NAT traversal מעביר את המטען המוגן לתוך UDP 4500: העטיפה נותנת להתקן המתרגם משהו שהוא יודע לתרגם. ברגע שזה קורה, כלל חומת אש שנכתב רק עבור UDP 500 יתיר את המשא ומתן ויפיל את המנהרה, מה שמייצר את התוצאה המבלבלת שבה הלוג מראה שלב 1 מוצלח ואין תנועה.

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

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

שלב 3: המיפוי פג והמנהרה מתה

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

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

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

אירוח מאחורי NAT של ספק הוא בעיה אחרת

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

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

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