iPhone Always On VPN: שתי מנהרות יכולות לחלוק כתובת IP וירטואלית אחת

ב-iPhone מפוקח עם פרופיל Always On מנוהל, הטלפון מחזיק מנהרה לכל ממשק IP פעיל, כך שהסלולרי וה-Wi-Fi מקבלים כל אחד משלו. השרת מציג אז שתי אסוציאציות אבטחה של IKE עבור התקן אחד, לעתים קרובות חולקות כתובת וירטואלית אחת, והדחף הראשון הוא לקרוא לזה לולאת rekey ולהתחיל לשנות טיימרים. הדחף הזה בדרך כלל שגוי. עברו על השלבים שלמטה לפי הסדר שבו הראיות מופיעות בשרת, והשאירו את הגדרות הטלפון בשקט עד שהשרת יגיד לכם איזה מקרה יש לכם.

התחילו בשתי השורות שכבר יש לשרת

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

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

החליטו איזו חפיפה אתם רואים

rekey של IKEv2 ואימות מחדש make-before-break יוצרים בכוונה חפיפה קצרה, בכך שהם מקימים את האסוציאציה החדשה לפני מחיקת הישנה. חותמות זמן מכריעות את המקרה, כי SA ישן שנעלם שנייה או שתיים לאחר שהחדש מופיע הוא חידוש שעושה את עבודתו. מנהרות ממשק עצמאיות לעולם לא נראות כך, שכן כל אחת נמשכת כל עוד הממשק שלה פעיל, ומחיקת האחת אינה נובעת מיצירת האחרת.

ההתנהגות המנוהלת של Always On של Apple היא לפי ממשק, ולכן התקן מפוקח יכול להיראות עמוס יותר באופן לגיטימי מפרופיל שהוגדר ידנית. מתג החיבור האוטומטי של אפליקציית ספק אינו מרמז על אותו דבר, וגם לא כלל on-demand רגיל. סקירת הפריסה של Apple מתארת את המודל לפי ממשק; השוו את שתי השורות שלכם אליה לפני שאתם מניחים לולאה. שתי הצורות גם שואבות מאותו מאגר בצד השרת, כך שהחפיפה היא האות המוקדם היחיד שלכם.

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

תשובה לטלפון ממוענת לכתובת הפנימית, והקרנל בוחר מנהרת יציאה לפי יעד ומדיניות, לא לפי הממשק שהטלפון השתמש בו. שתי אסוציאציות בו-זמניות שמחזיקות את אותה כתובת IP וירטואלית עם מדיניויות חופפות מותירות את החלטת הניתוב בלי דרך לומר לאיזו הפעלה שייכת תשובה. חלק מהתשובות לוקחות את המנהרה הלא נכונה, והטלפון מציג חיבור שעובד בכיוון אחד או מת כשהחיבור ל-Wi-Fi עולה. שני פלטי פקודה מוכיחים את המצב: swanctl --list-sas מציג את אותה כתובת IP וירטואלית בשתי ה-SA, ו-ip xfrm policy מציג שני בוררים זהים.

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

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

שנו את המאגר או את מודל החפיפה, לא את טיימר ה-rekey

בתצורת swanctl, ייחודיות היא מדיניות מפורשת על החיבור: unique = replace מסיר חיבור ישן יותר כשחדש מוקם, ו-unique = keep דוחה את המצטרף החדש. שני הערכים פועלים כשמקים חיבור, לא על אסוציאציות הבן שבתוכו.

connections {
  ios-alwayson {
    unique = replace
  }
}

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

בדקו את המעברים שאתם באמת פורסים

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

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