למה L2TP/IPsec צריך UDP 1701 בנוסף ל-IPsec

חומות אש שמאפשרות IKE ו-ESP אך לא UDP 1701 שוברות חיבורי L2TP באופן שנראה כמו בעיית אישורים. הסיבה היא ש-L2TP הוא פרוטוקול שני שנוסע בתוך הראשון. IPsec נושא ומאמת את ההחלפה, ו-L2TP מריץ מנהרה משלו מעל UDP 1701, שאותה על מחסנית הרשת המקומית עדיין למסור. הידיעה היכן מופיע כל כותרת מסבירה איזה התקן צריך איזה כלל.

שני פרוטוקולים, שתי קבוצות פורטים

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

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

העטיפה מסבירה את הפורט

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

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

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

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

מה שסריקת פורטים לא יכולה להראות

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

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