L2TP, GRE או IPsec: איזה שכבה צריכה לשאת את הסשן?
L2TP נושא סשנים של PPP, GRE נושא מנות מנותבות, ו-IPsec מגן על תעבורה נבחרת. הקצו תפקיד אחד לכל שכבה, ואז אמתו כל אחת בנפרד.
שתי שאלות מסתבכות בכל פעם ש-L2TP, GRE ו-IPsec מופיעים באותו מסמך תכנון: איזה סשן אני נושא, ואיזו שכבה מגנה עליו? אם הראשון שגוי, כל מה שממשיך ממנו נשאר עקבי מבפנים בעודו פותר את הבעיה הלא נכונה — שכבת-על מנותבת שנבנתה במקום שבו המשתמשים היו צריכים לחייג פנימה, או מרכז חיוג שעומד במקום שער אתר-לאתר. הגיליון שלמטה כופה את ההבחנה הזו לפני שמישהו מתחבר להתקן. מלאו אותו לפי הסדר וכל שורה הופכת למשהו שאפשר לבדוק בפני עצמו.
מתחילים מהסשן, לא מרשימת הפרוטוקולים
משתמש מרוחק שמחזיק בסשן PPP ושכבת-על מנותבת בין שני שערים הם שני יחסי רשת שונים, גם כששניהם עטופים בסופו של דבר ב-IPsec. הראשון מסיים קישור לכל משתמש וזקוק להקצאת כתובות, לאימות של אדם או התקן, ולמדיניות שמציינת אילו רשתות פנימיות אותו משתמש רשאי להגיע אליהן. השני מעביר מנות בין אתרים שאיש לא מחייג אליהם.
כתבו משפט אחד שמציין איזה מהשניים אתם בונים, ואז קראו אותו חזרה כאילו אתם האדם שצריך להפעיל אותו. אם המשפט צריך את המילה ״ו״, אתם בונים את שניהם, והגיליון צריך שתי עמודות במקום עמודה אחת של פשרה שמשרתת כל אחד מהם חצי. אם הוא מציין משתמש אבל בלי מאגר כתובות, או קידומת בלי מדיניות העברה, המשפט עדיין חסר. הניסוח נשמע ביורוקרטי, אבל זה המקום הזול ביותר לתפוס תכנון שאחרת יימצא דרך קריאת שירות בתמיכה.
תנו לכל שכבה בדיוק תפקיד אחד
L2TPv2 נושא סשנים של PPP בין שתי נקודות הקצה שלו. PPP מנהל את משא ומתן הקישור, וכשהוא מנוהל, את אימות המשתמש; L2TP לא מוסיף שום הצפנה, ולכן דמון L2TP חשוף אינו מיישם שום חלק מיחסי האבטחה של IPsec ושייך רק לקישור שכבר אתם סומכים עליו.
GRE הוא עטיפה בין שתי כתובות. הוא נושא מנות של שכבת הרשת מעל שכבת-על לוגית, ובעצמו אינו מציע לא סודיות ולא זהות מאומתת של עמית. זה אינו פגם: הכותרת תוכננה להיות פשוטה כדי שתישאר זולה לעיבוד בחומרת העברה. התוצאה היא ש-GRE עונה על השאלה איך להעביר את המנה הזו בין שתי כתובות ותו לא, וזו בדיוק השאלה שכדאי לשאול אותו.
נשאר IPsec כשכבה שבוחרת תעבורה, מאמתת את העמיתים ומצפינה את מה שנאמר לה להגן עליו. איזו תעבורה הוא מגן עליה הוא החלטת תצורה שחייבת להתאים לעטיפה שנקודות הקצה מייצרות בפועל, כי מדיניות שנכתבה עבור הכתובת החיצונית של GRE מתנהגת אחרת מזו שנכתבה עבור הקידומות הפנימיות. מפרט GRE שומר על הפרדה גלויה בין המטען, כותרת GRE ופרוטוקול המסירה החיצוני, והמדיניות שלכם זקוקה לאותה הפרדה.
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry a dial-in user session by itself |
כתבו את מסלול המנה לפני התצורה
קחו מנה אחת ורשמו כל כותרת שמתווספת, לפי הסדר שבו היא מתווספת, וציינו את ההתקן שמוסיף אותה. אצל משתמש מחייג זה בדרך כלל PPP בתוך L2TP בתוך IPsec; בשכבת-על של אתר זו מנת ה-IP הפנימית בתוך GRE בתוך IPsec. אם שני התקנים מוסיפים את אותה כותרת, יש לכם לולאה או מנהרה כפולה, ושום עריכת מדיניות לא תתקן את זה.
אותה רשימה קובעת את ה-MTU, כי הגודל הפנימי השמיש הוא ה-MTU של המסלול כפי שנמדד פחות הכותרות שמניתם זה עתה ותו לא. אל תעתיקו מספר מפוסט בפורום: חברו את תקורת ה-IP, ה-UDP וה-ESP החיצוניים, אחר כך GRE או L2TP, אחר כך PPP היכן שרלוונטי, וחסרו מה-MTU של המסלול שמדדתם בפועל. תסמינים שמופיעים רק בהעברות גדולות, או סשנים שמתבססים ואז מתים בתגובה הגדולה הראשונה, בדרך כלל מובילים לכך שהחיבור הזה נעשה על סמך ניחוש.
בדקו כל שכבה בנפרד, מבחוץ פנימה
הריצו את הבדיקות לפי הסדר ועצרו בראשונה שנכשלת. כל שורה עונה על שאלה אחרת, ולכן כשל מצביע על עמודה אחת בגיליון במקום לומר שהמנהרה שבורה.
ip xfrm state # is the IPsec SA up?
ip -s link show gre1 # does the overlay interface carry packets?
ip route get 10.20.0.5 # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500" # are the L2TP and NAT-T listeners bound?בקופסת Cisco המקבילה תלויה בתפקיד, והתחביר המדויק תלוי בפלטפורמה ובגרסה: show crypto session עבור עמיתי ה-IPsec, מוני ממשק עבור ממשק GRE או המנהרה, ואימות VPDN או PPP עבור תפקיד החיוג. סט פקודות שמסיים PPP לא מוכיח דבר לגבי תמיכה ב-GRE, וממשק GRE עובד לא מוכיח דבר לגבי שירות ה-PPP, לכן אמתו את התפקיד שהגדרתם בפועל ולא את זה שבתרשים.
רשמו כל פלט לצד שורת הגיליון שאליה הוא שייך. הערות שנכתבו כשהתקלה פעילה שוות יותר מטופולוגיה שמצוירת מחדש אחר כך מהזיכרון.
סדרו את הפירוק, ואז אמתו מחדש
הפירוק רץ בסדר הפוך מסיבה: הוציאו את התעבורה המוגנת ממדיניות ה-IPsec לפני שאתם מסירים את העטיפה שהיא נכתבה עבורה, אחרת המדיניות ממשיכה להצביע על ממשק שאינו קיים והטעינה הבאה של התצורה נכשלת במקום שנראה לא קשור. ב-Linux זה אומר למחוק את רשומות המצב והמדיניות לפני ממשק המנהרה; בנתב, להסיר את מפת ה-crypto או רשומת הפרופיל לפני המנהרה.
אחרי הבנייה מחדש, חזרו על ארבע תצפיות הקבלה אחת אחת: נגישות חיצונית, שיוך IPsec מבוסס, סשן PPP מבוסס היכן שהתכנון כולל אחד, והעברה פנימית לכתובת יעד אמיתית. אור ירוק אחד אינו ראיה לשלושת האחרים, והפער הזה הוא הכשל ששורד הכי הרבה זמן בייצור — מנהרה שעולה, מוצפנת, ולא מעבירה דבר כי המסלול הפנימי מעולם לא נוסף.
שמרו את הגיליון המלא לצד תצורת ההתקן. כל עמודה שאינכם יכולים למלא היא שכבה בלי תפקיד מוקצה, ושכבה בלי תפקיד מוקצה היא בדרך כלל שכבה שלא צריכה להיות בערימה.