מדוע IKEv2 באנדרואיד נכשל בפורט UDP לא תקני

השער עונה ל-IKEv2 בפורט UDP 4443 מסיבה כלשהי, בפרופיל יש שדה בשם Server, אתם מקלידים את שם המארח ואת הפורט, והטלפון מדווח שאינו יכול להגיע לשרת או שאינו יכול לפתור את הכתובת. שום דבר לא נחסם. הטופס המקורי של אנדרואיד מצפה למארח, וכך גם ב-Windows. פורט מותאם הוא יכולת של הלקוח לפני שהוא הגדרה של השרת, ורק חלק מהלקוחות מאפשרים לבטא אותו. עברו על שלושת החלקים לפי הסדר: מה הלקוח יכול לומר, על מה השרת מאזין, והאם שני הקצוות ממסגרים את החבילות באותו אופן.

מה הטלפון שלח בפועל

מחרוזת host:port בשדה שנועד לשם נפתרת כשם. הפותר לא מחזיר דבר עבור vpn.example.net:4443, והשגיאה שאתם רואים היא כשל בפתרון שם או אי-נגישות, ולא פסק זמן בפורט. ההבחנה הזו חשובה, כי ניסיון חוזר עם שם קצר יותר או רשת אחרת לעולם לא יתקן מחרוזת שהטופס אינו יכול לנתח.

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

השתמשו בלקוח שחושף את הפורט

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

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

לשרת יש שני פורטים, ושניהם חייבים להתאים

IKE מתחיל בפורט UDP 500, ומעבר NAT מעביר בדרך כלל את IKE ואת ה-ESP העטוף לפורט UDP 4500. אלו הגדרות נפרדות ב-strongSwan, ולכן שרת שהועבר לפורט מותאם אחד צריך לשנות את שניהם לאותו ערך:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

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

העברה קדימה אינה מאזין

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

הנתיב חייב לאפשר גם UDP מקצה לקצה. מעבר של TCP 443 דרך רשת מלון או רשת מפעיל אינו אומר דבר על IKEv2 בפורט UDP, אפילו עם אותו מספר. במקום שבו מותר רק TCP 443, פורט UDP מותאם אינו הופך את IKEv2 ל-HTTPS, והתשובה הנכונה עשויה להיות נתיב גישה אחר ולא ניסוי פורט נוסף.

הפרידו בין שלושת השלבים בבדיקה

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

tcpdump -ni eth0 -vv udp port 4443

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