איזה שלב ב-VPN נכשל: IPsec, בקרת L2TP או אימות PPP
מצאו את השלב האחרון שהצליח ותקנו רק את השכבה הזו: IPsec, ערוץ הבקרה של L2TP, אימות PPP או הקצאת כתובת.
שיניתם את הסיסמה ושום דבר לא זז, כי התקלה מעולם לא הייתה ב-PPP. L2TP/IPsec מדווח על שגיאת חיבור אחת עבור חמש העברות שונות לגמרי, ולכל העברה יש תיקון משלה. עבדו אחורה: מצאו את השלב האחרון שהצליח ושנו רק את מה שבא אחריו. הסדר שלמטה גם קובע אילו ראיות תאספו קודם.
ענו על ארבע שאלות לפי הסדר
כפו ניסיון חדש, כי חלק מהלקוחות ממשיכים להציג את השגיאה הקודמת עד שהפרופיל מנותק ומחובר מחדש. אחר כך ענו על זה: האם היה איגוד אבטחה של IPsec, האם הופיעו חיבור בקרה של L2TP ושיחה, האם PPP הגיע לפסיקת אימות, והאם IPCP נתן ללקוח כתובת? הלא הראשון הוא השלב שאתם מתקנים. כל מה שאחריו לא נבדק, ולכן שם משתמש שנדחה אינו מוכיח דבר כשמעולם לא היה איגוד.
סנכרנו את השעונים בשני הקצוות לפני ההשוואה. ניסיון חוזר שניקה את IPsec ונכשל ב-PPP נראה כמו כשל אחד כשהלקוח מציג רק את ההודעה האחרונה והיומן של השרת עדיין מחזיק את הניסיון הקודם. קראו לפי חותמת זמן, לא לפי השורה הרועשת ביותר.
כשיש לכם רק צילום המסך של המשתמש, הישענו על הפיצול הזול ביותר: מפתח משותף מראש שגוי ו-xl2tpd שאינו עונה לעולם מייצרים את אותו טקסט בתיבת הדו-שיח של Windows, אבל האחד דורש סוד ששונה בשני הקצוות והאחר דורש דמון שהופעל או כלל חומת אש בשרת עצמו. התקן באמצע אינו יכול להפיל את ה-1701 הפנימי לאחר ש-IPsec במצב תעבורה עטף אותו, לכן אל תחפשו מסנן נתיב שאינו קיים.
מה כל שכבה באמת מחזיקה
IPsec מגן על חבילות בין שני העמיתים; L2TP נושא הפעלת PPP בתוך הנתיב המוגן הזה, ולכן RFC 3193 מגדיר מצב תעבורה ולא מנהרה משלו. התווית של הלקוח אומרת L2TP, ולכן המנהרה וההתחברות מרגישות כמנגנון אחד. הן לא: חיבור הבקרה של L2TP מאמת את קצוות המנהרה במקום שבו פריסה מפעילה אותו, ו-PPP מאמת בנפרד את המשתמש עם CHAP, PAP או MS-CHAPv2 לפי מדיניות השרת.
הפיצול הזה מסביר את שני הסודות שאנשים ממשיכים לבלבל. מפתח משותף מראש מאמת את עמיתי IPsec. שם משתמש וסיסמה מזהים את המשתמש בפני PPP. הקלדה מחדש של הסוד המשותף של Windows בפרופיל שמאמת בתעודות אינה משנה דבר בשלב שנכשל, ועריכת סיסמת PPP אינה יכולה לספק ערוץ מוגן חסר. אותה ריסון חלה על בדיקת הזהות: אל תכבו את זהות העמית או את אימות התעודה כדי לקבל מנהרה, כי אז מה שמתחבר הוא הנתיב, לא העמית.
גם האימות אינו סוף PPP. לאחר שהמשתמש התקבל, IPCP מנהל משא ומתן על כתובת הלקוח ועל אפשרויות ה-DNS וה-WINS שהשרת מוכן לתת. לקוח יכול לעבור CHAP או MS-CHAPv2 ועדיין להישאר בלי כתובת, וזו תקלה בתוך PPP ולא בעיית ניתוב. L2TP פשוט בלי IPsec נשאר תקף ולא מוגן, ולכן חיבור מוצלח לעולם אינו מוכיח שהתעבורה מוגנת; בדקו מה השרת מחייב, לא את התווית של הלקוח.
החליטו לפי השלב החסר הראשון
קראו את הטבלה לפי הפריט החסר הראשון, משמאל לימין. העמודה הימנית היא העבודה היחידה ששווה משהו באותו רגע; כל מה שמשמאלה כבר הוכח, ובדיקה חוזרת שלו שורפת את חלון ההשבתה בלי להוסיף מידע.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
שלוש שורות ראויות לאזהרה. שורת ה-1701 היא המקום שבו לקוחות Windows מאחורי NAT נוחתים בדרך כלל: האיגוד מושלם, ואז שום דבר לא מגיע, והסיבה היא עטיפה ולא סיסמה גרועה. שורת IPCP היא זו שנקראת בטעות כבעיית נתיב, כי Windows עוטף כתובת חסרה בשגיאה 720 וסמל המגש רק אומר שהחיבור נכשל; התקלה הזו יושבת אחרי האימות ולפני הניתוב. השורה האחרונה אינה תקלת IPsec כלל, אף שהסמל אומר מנותק.
פקודות שמפרידות בין השכבות
בשרת Linux עם strongSwan, swanctl --list-sas מציג את האיגודים שהוקמו עם זהות העמית, ו-ipsec statusall מכסה מארחים ישנים של strongSwan ו-libreswan. מתחת, ip xfrm state מציג את האיגודים בפועל של הליבה, בעוד ss -lunp | grep 1701 מוכיח היכן xl2tpd קשור. הריצו את xl2tpd -D בחזית כדי לראות חיבורי בקרה ושיחות מופיעים, והפעילו דיבוג pppd ב-/etc/ppp/options.xl2tpd כדי לראות את השיטה המוצעת ואת התשובה.
כשהיומנים מראים אימות מוצלח, השאלה הבאה היא אם IPCP הושלם. בדקו אם ב-ip range בסעיף [lns default] של /etc/xl2tpd/xl2tpd.conf עדיין יש כתובות פנויות, ואם /etc/ppp/options.xl2tpd באמת נושא ms-dns ו-ms-wins אם הלקוח מצפה להם. מאגר מותש ואפשרות DNS חסרה נראים שונים על החוט: הראשון משאיר את הלקוח בלי כתובת ועם 720, השני נותן כתובת אבל בלי פותר, ולכן שמות נכשלים בעוד פינג לכתובות גולמיות עובד. אף אחד מהם אינו מתוקן בהקלדה מחדש של הסיסמה.
בלקוח, תוסף ה-L2TP של NetworkManager כותב את שיחת pppd ליומן, ולכן journalctl -u NetworkManager -b בדרך כלל מפריד בין מנהרה למעלה, האימות נדחה לבין אין מנהרה כלל. ב-Windows, Get-VpnConnection מדווח את הגדרות האימות האמיתיות של הפרופיל, ואירועי RasClient תחת Application ב-Event Viewer מזהים את הרכיב שנכשל. כשהתיבה מעורפלת מדי, הפעילו את netsh ras set tracing * enable.
ללכידות נדרשת זהירות אחת. עם IPsec במצב תעבורה, ה-UDP 1701 הפנימי מוצפן, ולכן לכידה בממשק החיצוני מציגה ESP, או UDP 4500 תחת NAT-T, ולא L2TP כלל. היעדר 1701 בלכידה הוא צפוי ואינו הוכחה לשער חסום; עקבו אחרי מוני ESP או 4500.
NAT, MTU ונתיבים: היכן המחסנית מטעה אתכם
NAT שובר הנחות לפני שמשהו אומת. ESP הוא פרוטוקול IP משל עצמו, ולכן התקן שמתרגם מפיל אותו אלא אם העמיתים עוטפים; זה מה ש-UDP 4500 מספק. בשרת Windows שיושב בעצמו מאחורי נתב ביתי או שער NAT בענן, שלב IPsec נכשל עם שגיאה 789 עד ש-AssumeUDPEncapsulationContextOnSendRule מוגדר ל-2 תחת מפתח PolicyAgent והמכונה מופעלת מחדש, והתקלה נשארת בלתי ניתנת להבחנה משער סגור. לקוחות מאחורי NAT קלים יותר: עם כתובת ציבורית בשרת, NAT-T על UDP 4500 נושא אותם והערך הזה אינו מעורב.
כש-PPP למעלה, MTU עם חור שחור מחקה מנהרה מתה: חבילות קטנות עוברות, לחיצת יד TLS או טעינת עמוד נתקעות, והלקוח עשוי עדיין להציג מחובר. הנמיכו את ה-MTU של הממשק או מהדקים MSS בשער לפני שאתם מאשימים את השרת. ניתוב מנהרה מפוצל הוא המתחזה האחר; תת-רשת שנדחפת עם מסכה שגויה משאירה את המנהרה בריאה ויישום אחד בלתי נגיש. שם מארח פרטי מוסיף קפיצה משלו: אם השאילתה יוצאת דרך הפותר המקומי, השם נכשל להיפתר לפני שנבדק נתיב כלשהו.
רשימת בדיקה לפני שנוגעים באישורים
עברו על הרשימה לפי הסדר ועצרו בפריט הראשון שנכשל. כל שלב זול, וכל אחד שולל מחלקה שלמה של עריכות.
- ודאו שהאיגוד קיים בשני הקצוות, מותאם לפי זהות העמית ולא לפי תווית מחובר.
- ודאו ש-UDP 1701 מגיע ל-xl2tpd; איגוד בלי שיחה הוא התקלה שלכם.
- קראו את פסיקת PPP, ואם אימת, את תוצאת IPCP, לפני שאתם מניחים שהסיסמה שגויה.
- רק עכשיו הקלידו מחדש את האישורים בפורמט שהשרת מצפה לו, כי קידומת דומיין משנה את החשבון.
- אם זה עדיין נכשל, לכדו את שני הקצוות עם חותמות זמן מיושרות והשוו שלב אחר שלב.
עצירה בשלב השני משמעה בעיית נתיב או עטיפה, ושום עריכת סיסמה לא תזיז אותה. עצירה בשלב השלישי משמעה שהיומן כבר מזהיר את השיטה או את מאגר הכתובות לתיקון. בכל מקרה, השינוי הבא הוא כזה שאתם יכולים להצדיק, ואתם מפסיקים להסתובב בהגדרות שמעולם לא היו מעורבות.