IKEv2 מול L2TP/IPsec: איזה פרופיל השרת שלך מריץ?
תווית אחת מסתירה שתי ערימות, שלושה סוגי סוד והתנהגות אחרת כשהכתובת משתנה. סדרו את השכבות לפני שמשווים בין התפריטים.
שני השמות מופיעים זה לצד זה באותה רשימה נפתחת, מה שמזמין בחירה בין שווים. הם אינם שווים. L2TP הוא פרוטוקול מנהרה בלי סודיות משל עצמו, וההגנה בשירות L2TP/IPsec מגיעה משכבת IPsec שעוטפת אותו. לעומתו IKEv2 מנהל משא ומתן ישירות על אסוציאציית IPsec ואין בו שלב של מנהרה בתוך מנהרה. הידיעה איזו ערימה השרת שלך מציע קובעת את הפרופיל, את ההנחיות ומה קורה כשהמחשב הנייד מחליף רשת.
שתי ערימות, תווית אחת בלקוח
L2TP נושא הפעלה מנקודה לנקודה מעל UDP אל פורט 1701 ומשאיר את ההצפנה למי שעוטף אותו. חברו אותו ל-IPsec ותקבלו שתי שכבות: אסוציאציית IPsec שמגנה על הנתיב, ובתוכה הפעלת L2TP שנושאת את מסגרות שכבת הקישור של המשתמש ואת אימות PPP.
IKEv2 יוצר אסוציאציית בקרה ואז אסוציאציית בת אחת או יותר שמגנות על התעבורה, הכול במשפחת החלפות אחת על UDP 500 ו-4500. אין פרוטוקול מנהרה פנימי ואין משא ומתן PPP.
פרטי זיהוי: שלושה סודות בשלוש שכבות
כאן נעלם רוב זמן התמיכה. פרופיל L2TP/IPsec יכול לבקש מפתח משותף מראש לשכבת IPsec ושם משתמש עם סיסמה להפעלת ה-PPP הפנימית, ושניהם נבדקים בידי רכיבים שונים. המפתח המשותף שייך לשער כולו, ולכן אינו מזהה איש; הוא רק מוכיח שהצד השני יודע סוד.
IKEv2 משתמש בדרך כלל בתעודות, או ב-EAP עם שם משתמש וסיסמה, ויכול להשתמש גם במפתח משותף מראש. האפשרויות האלה אינן ניתנות להחלפה עם צמד L2TP. איפוס סיסמה שמתקן התחברות EAP שנדחתה לא עושה דבר לתעודת לקוח שפגה, וכל כמה שתקלידו מחדש את סיסמת החשבון לא תספקו מפתח שער שגוי. כשהודעת בקשה מופיעה שלא ציפיתם לה, שאלו את המפעיל לאיזו שכבה היא שייכת לפני שתנחשו.
| Question | L2TP/IPsec | IKEv2 |
|---|---|---|
| What encrypts the traffic | A wrapping IPsec association | The child association |
| Ports you must permit | UDP 500/4500 and UDP 1701 inside | UDP 500 and 4500 |
| Typical secrets | Gateway PSK plus PPP credentials | Certificate, EAP, or PSK |
| Address change | Tunnel breaks, reconnect needed | Can migrate with MOBIKE |
מה MOBIKE משנה ומה לא
IKEv2 יכול להעביר אסוציאציה לכתובת חדשה כששני הקצוות תומכים ב-MOBIKE, מה שמכסה את המקרה של מחשב נייד שעוזב את הווייפיי לטובת נקודת גישה של טלפון בלי לפרק את אסוציאציית האבטחה.
אבל הוא לא משאיר כל יישום בחיים במהלך המעבר הזה. זרימת התעבורה בכל זאת מחליפה כתובת, שקעים הקשורים לכתובת הישנה בכל זאת נשברים, ומדיניות שמהדקת תעבורה לממשק בכל זאת יכולה להפיל אותה. בדקו את המעבר שאתם באמת מבצעים, בין אם יציאה מרשת, התעוררות משינה או חזרה אחרי תקופת חוסר פעילות ארוכה, והסתכלו על היישום ולא על התווית מחובר.
צורות כשל שמפרידות ביניהם
פרופיל L2TP/IPsec שמגיע לשער ואז נעצר נוטה להיכשל באחת משתי הודעות: המפתח המשותף או פרטי ה-PPP. מפתח שגוי בדרך כלל לא מראה דבר שימושי ביומן הלקוח, ואילו סיסמה שגויה מפיקה דחיית אימות מפורשת, וההבדל הזה אומר לכם היכן לחפש.
פרופיל IKEv2 נכשל מוקדם יותר ובקול רם יותר כשהזהות או התעודה שגויות, מפני שאסוציאציית הבקרה לעולם אינה מושלמת. אם האסוציאציה מושלמת והתעבורה בכל זאת נכשלת, הבעיה עברה לאסוציאציית הבת, לבוררי התעבורה או לנתיב, וכל שינוי בפרטי הזיהוי לא יעזור.
איפה כל אחד עדיין מתאים
L2TP/IPsec ממשיך להתקיים מפני שהוא קיים כמעט בכל לקוח ולא דורש תוכנה נוספת, וזה חשוב לקבלן על מכשיר שאינכם מנהלים. המחיר הוא השכבה הנוספת, מודל הסוד המשותף והתחברות מחדש אחרי כל שינוי כתובת.
IKEv2 מתאים יותר למכשירים מנוהלים: זהות באמצעות תעודה, ניידות נקייה יותר ומשפחת אסוציאציות אחת לחשוב עליה. הוא גם נכשל חזק יותר כשהלקוח ישן, לכן בדקו את שיטת האימות שהפלטפורמה תומכת בה לפני שתעצבו סביבה.
לבדוק את הפרופיל שקיבלתם
אשרו קודם את המצב בצד השרת, ואז בחרו את פרופיל הלקוח שמתאים לו. בדקו עם שם המארח ופרטי הזיהוי המדויקים שהונפקו לאותו פרופיל, ואמתו את המשאב הפרטי ולא אתר ציבורי.
אם הוא מתחבר ושום דבר לא נטען, המנהרה עובדת והנתיב, ה-DNS או בורר התעבורה לא. החלפת פרוטוקול בנקודה הזו מפעילה את האבחון מחדש במקום לקדם אותו.