strongSwan send_cert: מתי נשלח אישור IKE

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

מה send_cert באמת שולט בו

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

פריסות ipsec.conf ישנות יותר השתמשו ב-leftsendcert וב-rightsendcert, ושמות אלה מתייחסים לתפקידים מקומיים ומרוחקים, לא ישירות ל-swanctl.

קראו ניסיון אחד לפני שתשנו את החיבור

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

האמון של המקבל הוא החלטה נפרדת

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

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

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

שנו את השולח רק עם ראיות

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

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