בפעם הראשונה שמישהו מוסר לך פרופיל vpnc, תיבת ההתחברות מבקשת ארבעה דברים ונקראת כאילו היא רוצה סיסמה אחת. היא לא: סוד קבוצה משותף מראש והתחברות XAuth אישית הם ערכים נפרדים עם בעלים נפרדים, והכנסת סיסמת החשבון לשדה הקבוצה מניבה כשל שנראה כמו סיסמה שגויה ולא כמו תיבה שגויה. להבין את המיפוי נכון זו כל המשימה כאן. הפרוטוקול שמתחת הוא פרויקט הגירה של מישהו אחר, ולכן שום דבר מזה אינו טיעון לבניית מנהרות IKEv1 חדשות.

שני סודות, שני בעלים, תיבה אחת

סוד קבוצה שייך לפרופיל השער. כל מי שמתחבר דרך אותו פרופיל משתמש באותו ערך, ובדיוק משום כך הוא אינו יכול לזהות אדם ואינו יכול להיגרע ממחשב נייד אחד בלי לשנותו לכל שאר משתמשי הפרופיל. שם המשתמש והסיסמה של XAuth שייכים לאדם, והשער מעריך אותם בשלב שני, לאחר שאסוציאציית IPsec כבר עומדת.

הצורה הדו-שלבית הזאת היא מה שאנשים מפספסים. הקמת המנהרה ואימות המשתמש הם חילופים שונים עם קלטים שונים, ולכן לקוח שלעולם לא מגיע להנחיית ההתחברות כלל לא נכשל בהתחברות. קרא את התיבה כשתי עמודות ולא כאחת: ערכים ברמת הפרופיל משמאל, ערכים אישיים מימין. כשחיבור נכשל, העמודה שמילאת לאחרונה אינה אוטומטית העמודה האשמה.

מפה את השדות לפי תפקיד, לא לפי תווית

vpnc מכנה את ההוראות שלו בתיעוד הפרויקט, וכל ממשק גרפי נותן להן שם אחר. תרגם את תפקידו של כל ערך והתוויות מפסיקות להיות חשובות:

DirectiveWhat it carriesWho owns it
IPSec gatewayAddress or hostname of the remote VPN endpointOperator
IPSec IDGroup identifier selecting the profile on that gatewayOperator
IPSec secretGroup preshared secret, not an account passwordProfile, shared
Xauth username and passwordCredentials for the per-user stage after the tunnelPerson

ממשק שמציג «שם משתמש» ו«סיסמה» לצד שדה קבוצה אינו שגוי — אלה אותם שלושה ערכים בשמות אחרים. מה שנשבר הוא מילוי תיבה מפני שערך מתאים לה. סוד קבוצה שהודבק כסיסמת משתמש מאמת את הפרופיל ואז נכשל בשלב המשתמש; סיסמת חשבון שהודבקה כסוד קבוצה נכשלת מוקדם יותר, לפני כל הנחיה, ושולחת אנשים לחפש חומות אש אחר בעיה שחיה בשדה טקסט.

מה מזהה קבוצה אינו

המילה קבוצה מזמינה קריאה שגויה. מזהה קבוצה כאן הוא בורר שאומר לשער איזו תצורת פרופיל להחיל; הוא אינו אומר דבר על חברות בספרייה, ושם תואם בשני הצדדים הוא צירוף מקרים עד שהמפעיל יאשר אותו. הרשאה מתרחשת לאחר הצלחת XAuth, נקבעת על ידי מה שהשער מוגדר להתייעץ איתו, ושום דבר מזה אינו נראה בתיבת הלקוח.

אותה זהירות חלה על סוד הקבוצה. לדעת אותו אינה זהות, והעברת סוד אחד סביב צוות היא החלטה תפעולית עם השלכות שהלקוח אינו יכול להראות לך.

הכרע את ההוראה הדו-משמעית לפני התחברות

הערות מסירה ישנות מכילות לעיתים שורה כמו «השתמש בכתובת ה-IP הציבורית הייעודית». הביטוי הזה יכול להתכוון לכתובת שממנה רשימת היתרים בצד השני מצפה שהתעבורה שלך תגיע, וזו תכונת יציאה של רשת המפעיל ואין לה שום קשר לנקודת הקצה שאתה מקליד בשדה השער. שאל איזו משתי המשמעויות מכוונת לפני שהערך הולך לאנשהו. מילוי בכיוון ההפוך שולח כל מנה לכתובת שלעולם לא עונה, וזמן ההמתנה שנוצר נקרא כמו פורט חסום.

בקש ארבעה דברים בערוץ המאומת של הארגון: איזה לקוח ופרוטוקול נתמכים, באיזו נקודת קצה להשתמש, איזו זהות השער יציג, ואיך מוסרים אישורי התחברות. הרחק סודות אמיתיים מצילומי מסך, מכרטיסים ומהערות פתרון תקלות משותפות. אל תשבית בדיקות תעודה ואל תדביק רשימת צפנים ישנה כדי לגרום לשירות שהוגדר אחרת להיראות תואם, כי חיבור שעובד רק על ידי החלשת האימות אינו החיבור שהתבקשת לבנות.

שמור על הפרופיל הישן ביושר

IKEv1 מיושן, ו-RFC 9395 הוא המסמך שיש לצטט כשעולה שאלת ההגירה. מיפוי שדות מוצלח אינו הוכחה שהפרוטוקול שייך לתכנון חדש; מה שהוא קונה הוא חיבור עובד בזמן שההחלפה מתוכננת, בתוספת תחום כתוב ובעלים לאותה הגירה.

ואז אמת מול הדרישה ולא מול התיבה. לאחר ההתחברות, ודא שממשק המנהרה מחזיק בכתובת הצפויה ושמטרה פנימית מנותבת דרכו; אם הדרישה המקורית כללה כתובת יציאה לרשימת היתרים, אמת גם את הכתובת הזו, כי זו עובדה שונה מכך שהמנהרה עומדת. פרופיל שמאמת כראוי ואינו מנתב דבר עדיין נכשל במשימה שלשמה נוצר.

מאמרים קשורים