פרופיל WireGuard עבור שער IPsec: מה לבקש במקום

פסקי זמן של לחיצת יד עם שער שקט משמעותם בדרך כלל שני פרוטוקולים שלעולם אינם נפגשים. עמית WireGuard מדבר Noise בעוד שער IPsec ממתין ל-IKE. כתובת ופורט נכונים אינם משנים זאת.

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

בקשה ראשונה: גרסת הפרוטוקול

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

שאלו איזו גרסה השירות מסיים והאם הוא מריץ מימוש מבוסס תקנים או גרסת ספק עם לקוח משלו. תפריטי מערכות הפעלה מסתירים לעתים קרובות את התשובה מאחורי תווית אחת. התווית אינה הפרוטוקול.

בקשה שנייה: שיטת האימות של הלקוח

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

מפתח פרטי של WireGuard אינו אף אחד מאלה. זהו מפתח Curve25519 המשמש בלחיצת יד אחת מסוימת. שום המרה אינה הופכת אותו לתעודה או לאישור EAP. כלי שטוען אחרת משנה את שם הקובץ או מייצר משהו לא קשור.

מפרט IKEv2 ב-RFC 7296 מתאר מה מימוש של אותה גרסה חייב לתמוך בו. זהו מקור עיון לתשובה מעורפלת של המפעיל, לא מדריך לתצורת לקוח.

בקשה שלישית: הזהות המהימנה והיעדים

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

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

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

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

כאשר שני הפרוטוקולים חייבים להתקיים יחד

ניהול שתי הרשתות הוא סיבה לגיטימית לשמור על שני הפרוטוקולים. התכנון המקובל מסיים את WireGuard ואת IPsec בממשקים נפרדים או בשערים נפרדים. לאחר מכן התעבורה המאושרת מנותבת ביניהם.

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

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

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