מדוע PPTP ו-L2TP/IPsec נעצרים לפני בקשת שם המשתמש?
היעדר בקשת שם משתמש פירושו ש-PPP מעולם לא התחיל, ולכן התקלה נמצאת בהובלה, בחילופי המפתחות או בהקמת המנהרה. בדקו את סדר השלבים לפני התקנה מחדש.
היעדר בקשת שם משתמש הוא מתנה אבחונית: PPP טרם התחיל, ולכן החשבון, הסיסמה ומדיניות התחום טרם נשאלו. בחיבור PPTP או L2TP/IPsec הלקוח מבקש אישורים רק לאחר שהמנהרה קיימת והשרת החל הפעלת PPP. כל מה שיכול להיכשל לפני אותו רגע הוא הובלה, חילופי מפתחות או הקמת מנהרה, שטח קטן בהרבה מ«ה-VPN שבור».
בקשה חסרה מצמצמת את התקלה לשלושה שלבים
רשמו את השלב האחרון שהצליח באופן גלוי, כי לכל אחד יש בעלים שונים ותיקון שונה. ניחוש הגדרות החשבון כשאתם תקועים שני שלבים מוקדם יותר הוא הדרך שבה אחר צהריים נעלם.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
לקוח שפג תוקפו בלי בקשה מעולם לא קיבל שיוך IPsec, ולכן התקלה היא ב-IKE או בשאלה אם החבילות שלכם מגיעות לשער בכלל. זה שמדווח שהוא מאמת אישורים ואז נופל הגיע רחוק יותר ממה שההודעה מרמזת. בקשה שאחריה דחייה היא אימות PPP, וזה שייך למאמר על חשבון ולא לזה.
שלב אחד: הפרוטוקול שחומת אש מפילה בשקט
PPTP זקוק ל-TCP 1723 עבור ערוץ הבקרה ולפרוטוקול IP 47 עבור נתיב הנתונים, והשניים נוסעים בנפרד. רשתות רבות מעבירות 1723 ומפילות את פרוטוקול 47, מה שמייצר מנהרה שמנהלת משא ומתן ואז לא נושאת דבר כלל. נתב שעושה NAT זקוק גם למעבר עם תמיכת GRE, ונתיב גישה ב-IPv6 בלבד אינו יכול לשאת PPTP בשום תצורה.
L2TP מעל IPsec מבזבז את פורט 500 על IKE ואת פורט 4500 על חציית NAT, ואז עוטף את תעבורת L2TP עצמה ב-1701, בעוד ESP נושא את המטען המוגן ברגע שהשיוך קיים. התירו את שני פורטי הבקרה אך לא ESP, ותקבלו בדיוק את התסמין שבכותרת: התקדמות נראית לעין ואז לקוח מת לפני כל דו-שיח לאישורים. בדיקה מנקודת גישה של טלפון היא דרך זולה להפריד בין בעיית לקוח לבעיית נתיב.
שלב שני: מפתח שאינו המפתח, הצעה שאינה מוצעת
מפתח משותף מראש שאינו תואם נכשל מהר ובשקט, והגרסה הנפוצה היא מפתח שנראה נכון על המסך אך נושא שבירת שורה שהודבקה או רווח בסופו. בלקוח לינוקס הדו-שיח אינו בהכרח מקור האמת: תוסף ה-L2TP של NetworkManager שומר סודות בקבצים תחת /etc/ipsec.d/, וקובץ ישן לכל חיבור ש-/etc/ipsec.secrets עדיין כולל אותו ישמש במקום זה שהקלדתם זה עתה. העתיקו את הקובץ ההוא למקום בטוח, הוציאו אותו מנתיב ההכללה, ואז הקלידו את המפתח מחדש ביד.
החצי השני של השלב הזה הוא ההצעה. שני הקצוות חייבים להסכים על אותה קבוצת אלגוריתמים של שלב 1 — הצפנה, שלמות וקבוצת Diffie-Hellman — ועל טרנספורמציות ESP תואמות לשלב 2, אחרת השיוך לא נוצר כלל. שער שמציע רק 3DES, SHA1 ו-MODP1024 ידחה לקוח שהוגדר לאלגוריתמים חזקים יותר, והיומן שלו נוקב בשם הטרנספורמציה שנדחתה. היומן נוקב בשם אי-ההתאמה אם תקראו אותו במקום להפעיל את השירות מחדש. במקום להעתיק מחרוזת אלגוריתמים משרשור בפורום, שאלו את השער אילו טרנספורמציות הוא באמת ינהל משא ומתן: ike-scan שמכוון לכתובתו מחזיר את הטרנספורמציות שהוא ינהל. אם ההצעה היחידה היא הצפנה שהמדיניות שלכם כבר אינה מתירה, התיקון שייך לשער ולא להורדת דרגה של הלקוח.
ב-Windows המפתח ושיטת האימות חיים בפרופיל ה-VPN, ואי-התאמה מתגלה לפני בקשת האישורים ולא אחריה. היכן שהמקבל הוא Windows Server, ודאו שתפקיד הגישה מרחוק מותקן, שהתעודה תואמת לשם שאליו הלקוחות מתחברים, ושאין מסנן פורטים צר מהפרוטוקולים שלמעלה.
שלב שלישי: המנהרה קיימת ו-PPP לא מתחיל
כשה-IKE מסתיים והבקשה עדיין אינה מופיעה, הסתכלו על דמון המנהרה ולא על חומת האש. L2TP זקוק למשהו שמאזין ב-UDP 1701 — xl2tpd או kl2tpd בלינוקס, שירות הגישה מרחוק ב-Windows — ושירות מותקן אך עצור נראה מצד הלקוח בדיוק כמו חבילה שנזרקה. בדקו את המאזין לפני שתפתחו מחדש כללים שכבר אימתתם. אחר כך PPP חייב לנהל משא ומתן, והחלפת ה-LCP הראשונה היא המקום שבו כשל שקט נוחת בדרך כלל.
מלכודת אחת בשלב הזה אינה תקלת רשת כלל: Windows מתיר חיבור אחד בלבד מסוג VPN נתון בו-זמנית, ולכן ניסיון שני מחזיר שגיאה 937, «חיבור אחר מסוג זה נמצא בשימוש». זהו כלל מקומי, והדרך לעקוף אותו היא התקן אחר, סוג מנהרה אחר או שיתוף החיבור האחד שכבר קיים.
קראו את היומן לפי סדר השלבים במקום לנחש
עצרו את הלקוח, הפעילו אותו מחדש, וקראו את הרכיבים לפי הסדר שבו הם כותבים ליומן. כלומר קודם דמון ה-IPsec — strongSwan או Libreswan, ו-ipsec --version אומר לכם איזה — אחר כך דמון ה-L2TP, אחר כך pppd. כל רכיב שכתב אחרון לפני הכשל מסמן את השלב לחקירה, כי כל מה שבא אחריו ברצף לא רץ כלל.
אמתו בחיבור חדש ולא בהפעלה שמורה, כי לקוח שמתחבר מחדש מהמטמון עלול לדלג על חלקים מההחלפה ולשחזר תוצאה מיושנת. אשרו נגישות, חילופי מפתחות, מנהרה ו-PPP אחד אחד, בסדר הזה. אז הבקשה החסרה מפסיקה להיות תעלומה והופכת לשורה השנייה של רשימה שאפשר באמת לעבוד דרכה. הרשימה הזו היא גם מה שאתם מוסרים לצוות הרשת, שבלעדיה יידרש לבדוק את חומת האש בעקבות תקלה שחיה בדמון שלא הופעל.