ipsec.conf או swanctl.conf? בחרו חזית strongSwan אחת
ipsec.conf ו-swanctl.conf שייכים לטוענים שונים של strongSwan. זהו את השירות הפעיל לפני תרגום פרופיל IKEv1 ישן.
פרופיל IKEv1 עובד ממדריך ישן נוחת על Ubuntu 24.04, והניסיון הראשון נכשל מפני שהדמון מעולם לא קרא את הקובץ. התגובה הרגילה היא לערוך את הפרופיל שוב. השאלה האמיתית היא איזו חזית strongSwan מותקנת ואיזו משתמשת השירות הפעיל. עד שלא תיענה, כל עריכה מכוונת לטוען שאולי אינו קיים.
שני קבצים, שני טוענים, דמון אחד
סידור ה-starter הישן קורא את ipsec.conf ומעביר חיבורים ל-charon דרך שילוב הניהול הישן שלו. נקודת הכניסה התפעולית שלו היא הפקודה ipsec.
סידור swanctl טוען הגדרות דרך VICI, קורא את swanctl.conf, ומונע על ידי הפקודה swanctl. הדמון charon המובנה ב-systemd משתלב בגישה הזו.
שניהם יכולים להיות מותקנים על אותה מכונה, ושם מתחילה הבלבול. קובץ תחת /etc מוכיח רק שמישהו כתב אותו, לא שהתהליך הפעיל טען אותו. התקנת כל חלופה כדי לראות איזו עובדת יוצרת מארח עם שני נתיבי ניהול ובלי בעלים ברור. בחרו סידור אחד והסירו או השביתו את השני.
קראו את החבילות והיחידות המותקנות
התחילו במצב קריאה בלבד. שמות החבילות ב-Ubuntu 24.04 נפרדים: strongswan-starter, strongswan-swanctl ו-charon-systemd. חבילה חסרה היא מידע שימושי, לא הוראה להתקין אותה.
ערכו רשימה של החבילות והיחידות במעבר אחד:
dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'
לאחר מכן בדקו את היחידה הפעילה ואת פקודת האתחול שלה. שם היחידה אומר איזה דמון מחזיק בהגדרה, ושורת הפקודה מאשרת אילו קבצים נאמר לו לקרוא. יחידה שמופעלת אך אינה פעילה מספרת סיפור אחר מזו שרצה כעת.
אם היחידה הפעילה היא strongswan-starter, הקובץ החשוב הוא ipsec.conf. אם זה charon-systemd עם swanctl, ipsec.conf הוא רק קישוט.
השתמשו בנתיב הבקרה המתאים
לכל חזית יש תפיסה משלה של חיבורים ושיוכים. swanctl --list-conns מציג הגדרות טעונות ו-swanctl --list-sas מציג שיוכים פעילים. הנתיב הישן משתמש ב-ipsec statusall.
ערבובם מייצר שגיאות מטעות. שקע VICI חסר או בקשת בקרה שנדחתה הם בעיה של נתיב ניהול, לא הוכחה שהצד השני דחה אימות.
קראו את התצוגה השייכת לדמון הפעיל, ואז פרשו את התוצאה. אם החיבור נעדר מהתצוגה הזו, הבעיה היא בטעינה, לא במשא ומתן.
הפורמט אינו גרסת IKE
פרופיל ישן בוחר IKEv1 באמצעות keyexchange=ikev1. חיבור swanctl משתמש בהגדרת גרסה, שבה 1 בוחר IKEv1. אלה שני אוצרות מילים לאותו רעיון, לא המרה.
כתובות הצד השני, זהויות מקומיות ומרוחקות, מקורות אישורים, הצעות ובוררי child חייבים להיות ממופים בכוונה. הדבקת בלוק left/right בתחביר swanctl לא עושה מזה דבר.
שינוי גרסת הפרוטוקול בלבד הוא חצי-ההגירה הנפוץ ביותר. הוא מייצר קובץ שנטען ואז נכשל באימות מסיבות שאינן קשורות לגרסה. IKEv1 עצמו הוצא משימוש על ידי RFC 9395, ולכן צד שני קיים שעדיין דורש אותו ראוי למגבלת תאימות מתועדת ולנתיב הגירה, לא לברירת מחדל חדשה.
בדקו את הטוען לפני שנוגעים בפרופיל
הריצו תחילה את בדיקת הטוען, אחר כך טענו את החיבור המיועד, אחר כך העריכו את המשא ומתן, ולבסוף את נתיב התעבורה המוגנת. לכל שלב חתימת כשל אחרת.
שני נתיבי הבקרה עונים ישירות על שאלת הטעינה:
swanctl --list-conns
ipsec statusall
רק אחת מהפקודות האלה שייכת למארח שלכם. הרצת שתיהן והשוואת הפלט היא דרך לגלות מי משקר לכם, לא שיטת אבחון.
התייחסו לבעלות על חבילות, לטעינת הגדרות ולתאימות פרוטוקול כאל שלוש שאלות נפרדות. קובץ שתקף לחזית אחת ייערך שוב ושוב בזמן שדמון אחר הוא זה שרץ.