למה אנדרואיד מתחבר ל־VPN מסוג IPsec בבית ווינדוס לא
הטלפון מתחבר, המחשב הנייד לא, והסיסמה היא לא הבעיה. הנתב מציע פרופיל IKEv1 XAUTH שווינדוס מעולם לא סיפק.
הטלפון מצטרף ל־VPN של הנתב בלי תלונות, בעוד המחשב הנייד באותו Wi-Fi לא מצליח. אותם פרטי התחברות, אותו שרת, אותה דקה. ההבדל הוא תמיכת פרוטוקול, לא הסיסמה: הנתב חושף פרופיל שמערכת הפעלה אחת מיישמת והשנייה מעולם לא הייתה לה.
זהו קודם את הפרופיל, ואז השוו אותו למה שכל לקוח באמת מדבר.
תפריט אחד, שלושה פרוטוקולים
תחת כותרת IPsec אחת יכול קושחה צרכנית להסתיר שלוש מנהרות שונות לגמרי. הראשונה היא IKEv1 עם XAUTH: סוד קבוצתי משותף ומעליו שם משתמש וסיסמה. השנייה היא L2TP/IPsec, שבה PPP פועל בתוך תעבורת IPsec המוגנת במפתח משותף. השלישית היא IKEv2, מאומתת בתעודות או ב־EAP.
קראו את השדות, לא את התווית. סוד קבוצתי עם רשימת משתמשים פירושו IKEv1 XAUTH. מפתח משותף מראש עם חשבון PPP פירושו L2TP/IPsec. תעודת שרת בלי סוד קבוצתי פירושה IKEv2.
פער התמיכה בין טלפון למחשב נייד
אנדרואיד כולל לקוח IKEv1 XAUTH PSK מובנה, וזו בדיוק הסיבה שהטלפון מצליח מול נתב שלא מציע דבר אחר. ווינדוס לא: הלקוח המובנה שלו מטפל ב־L2TP/IPsec וב־IKEv2, ואין אפשרות IKEv1 XAUTH להפעלה. הקלדה חוזרת של הסוד לא תעזור, כי החלק החסר הוא הפרוטוקול ולא פרטי ההתחברות.
הצד של אפל הוא מטרה נעה. גרסאות macOS ו־iOS חדשות נוטות ל־IKEv2, פרופילים ישנים בסגנון סיסקו שורדים בחלק מהבנייות, ועדכון יכול להסיר או להקשיח את מה שעבד בחודש שעבר. מק שמתחבר אתמול ולא היום, בלי שינוי בנתב, הוא בדרך כלל זה.
שתי הגדרות ששוברות פרופילים תקינים
העמוד L2TP/IPsec של Synology מציע תיבת סימון בשם Enable SHA2-256 compatible mode (96 bit). לקוחות אפל מ־iOS 14 ו־macOS Big Sur ואילך דוחים את המצב המקוצר הזה, ולכן התיבה חייבת להיות כבויה אצלם. אם היא נשארת דלוקה, המנהרה מאמתת ואז נופלת, מה שנראה כמו פרטי התחברות גרועים וזה לא. היצרן מתעד את המתג, ועדכון מערכת הפעלה הוא בדרך כלל הרגע שבו זה מתחיל להיות חשוב.
ווינדוס מחזיק תעודות בשני מאגרים נפרדים, ו־IKEv2 קורא רק את זה של המכונה. ייבאו את תעודת הלקוח עם המפתח הפרטי שלה לחשבון המחשב; תעודה שמאוחסנת תחת חשבון המשתמש שלכם מופיעה בקונסולת הניהול ולעולם לא מגיעה לשירות IKEv2. EAP-TLS הוא המקרה היחיד שבו תעודת משתמש שמישה, וה־CA החותם עדיין חייב להיות מהימן למכונה. טעות כאן נראית ככשל אימות, לא כבקשה לתעודה חסרה.
כשהנתב נשאר כפי שהוא
נתב שמדבר רק XAUTH PSK משאיר שלושה מסלולים: הלקוח של היצרן, לקוח צד שלישי שעדיין מיישם את הפרופיל, או העברת נקודת הקצה של המנהרה למשהו שמדבר IKEv2. AVM למשל מפרסמת תוכנת לקוח לווינדוס וקובץ תצורה מיוצא לנתבים שלה. המסלול הזה נתמך, והוא מחייב התקנת כלי של היצרן בכל מחשב נייד.
תמיכה חשובה יותר מאלגנטיות כשהמחשבים הניידים אינם שלכם לבנייה מחדש.
שקלו גם את מחיר האבטחה. סוד קבוצתי אחד מכסה את כל המשתמשים, ולכן כל מי שמחזיק בו יכול לעמוד במקום השרת וללכוד את שם המשתמש והסיסמה שהלקוח מציע. במקום שבו IKEv2 עם תעודות זמין, המעבר הזה שווה יותר מכל עקיפה בצד הלקוח.
אבחנו מבחוץ פנימה
השיגו קודם הפעלה עובדת מהטלפון, כדי שצד השרת יוכח לפני שהמחשב הנייד נכנס לתמונה. אחר כך ייבאו את הפרופיל המיוצא של הנתב ללא שינוי וקראו את יומן הלקוח במקום עמוד המצב של הנתב. אם היומן לא מראה הצעה יוצאת, המחשב הנייד מעולם לא הגיע למשיב. אם הצעות מוחלפות ואז נכשלות, המחלוקת היא על אלגוריתמים, זהות או פרטי התחברות.
שמרו את פרופיל הטלפון העובד כבקרה. כשאחרי עדכון קושחה רק המחשב הנייד נשבר, צד השרת מתנהג כמו קודם. כששניהם נשברים, הביטו בתעודה או במאזין לפני שנוגעים בלקוח כלשהו.