VPN ב-Mac מתחבר פעם אחת ואז פוקע הזמן: נקו את דמון ה-IKE

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

ב-macOS, אותו משהו הוא בדרך כלל דמון ה-IKE.

התבנית: חיבור אחד, ואז פקיעת זמן

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

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

שני דמונים, פורט אחד

המערכת מפעילה racoon כאשר חיבור מדבר IKE גרסה 1. גרסאות נוכחיות מביאות גם iked עבור IKEv2 וערימת ה-IPsec החדשה יותר. שניהם יכולים לתפוס את UDP 500 ואת UDP 4500, ושניהם יכולים להחזיק שיוך אבטחה חצי-פתוח לאחר שניסיון חיבור בוטל בהנחיית הסיסמה או נקטע בשינוי רשת.

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

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

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

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

הפעילו מחדש את המשימה ולא את התהליך

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

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

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

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

כאשר השרת הוא זה שמסרב

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

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

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

לקוחות ישנים וליבת 64 הסיביות

לקוח ה-Cisco IPSec הישן טוען הרחבת ליבה שנבנתה למערכות 32 סיביות ו-PowerPC. ב-Mac שעולה בליבת 64 הסיביות, ההרחבה הזו לא יכולה להיטען, והלקוח נכשל מוקדם עם שגיאה 51 כי הוא כלל לא מגיע לתת-מערכת ה-VPN. שום כמות של הפעלה מחדש של הדמון לא מתקנת הרחבת ליבה בארכיטקטורה שגויה.

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

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

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