OpenVPN באנדרואיד לא מוסיף מסלול בלי כתובת מנהרה

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

קרא את הכשל לפי הסדר שבו הלקוח מבצע אותו

VpnService.Builder של אנדרואיד מפריד בין שני המושגים: addAddress() מציב כתובת על הממשק שהאפליקציה בונה, addRoute() מוסיף קידומת יעד, ו-establish() מסרב ליצור את הממשק עד שנוספה לפחות כתובת אחת. לקוח OpenVPN ממפה את הפרופיל ואת האפשרויות שהשרת דוחף בדיוק לקריאות האלה, ולכן חיבור שלעולם אינו מפרש כתובת לא יכול לבנות את הממשק כלל.

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

בדיקה 1: האם השרת מציב כתובת בתשובה?

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

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

בצורה הזו השרת דוחף משהו כמו ifconfig 10.8.0.6 255.255.255.0. פריסה ישנה יותר של topology net30 דוחפת במקום זאת כתובת עמית, למשל ifconfig 10.8.0.6 10.8.0.5, ולכן פרופיל שהועבר בין שני הדגמים עשוי להיראות תקין בעודו נושא מסכת רשת שגויה.

חפש ביומן החיבור של הלקוח את מערך האפשרויות שנדחף. אם אין בו שורת ifconfig כלל, השרת מעולם לא שלח כתובת או שהלקוח דחה את האפשרות. בשרת שמשתמש ב-client-config-dir, הקובץ הנקרא על שם ה-common name בתעודה חייב להתקיים ולשאת את ההקצאה:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

בדיקה 2: האם הלקוח שומר על הכתובת שקיבל?

מסנן רחב מדי הוא הסיבה השנייה הנפוצה. pull-filter קיים ב-OpenVPN 2.4 ואילך, וכמה מסננים תואמים לאותה אפשרות — האחרון שתואם הוא שמנצח, ולכן catch-all בסוף מסיר את הכתובת בלי שגיאה:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

צמצם את המסנן לאפשרות שאתה באמת רוצה להסיר והשאר את הכתובת במקומה:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

העצה לכבות את כל ה-pull מגיעה בדרך כלל ממי שמנסה להיפטר ממסלול אחד בלבד. route-nopull הוא המתג הצר יותר: הוא שומר על ifconfig ועל שאר האפשרויות הנדחפות ובמקביל דוחה מסלולים נדחפים ואפשרויות בסגנון DHCP. השתמש בו כשזה באמת מה שאתה רוצה, וענה על שאלת הכתובת בנפרד.

בדיקה 3: האם הכתובת שלך לכתוב?

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

קידומת ה-LAN המרוחק במסלול היא יעד, ולעולם לא הזהות של הטלפון. מסלול עבור 10.60.0.0/24 אומר להגיע לרשת הזו דרך המנהרה; הוא לא אומר דבר על איזו כתובת 10.60.0.x הטלפון אמור להחזיק, והטלפון לא אמור להחזיק אף אחת מהן. הקצאות סטטיות שייכות לצד השרת, שם הן לא יכולות להתנגש במאגר הדינמי.

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

בדיקה 4: האם משהו אחר תופס את מקום המנהרה?

אנדרואיד מאפשר שירות VPN פעיל אחד בכל רגע. אפליקציית VPN אחרת, או רשומת VPN תמיד-פעיל שהושארה דלוקה עבור פרופיל שכבר לא עובד, יכולות לתפוס את המקום הזה לפני שלקוח ה-OpenVPN שלך קורא ל-establish(). אז הממשק לא מופיע לעולם אף שהפרופיל תקין, ולכן נתק את ה-VPN האחר, כבה את הגדרת התמיד-פעיל והתחבר מחדש לפני שתיגע בפרופיל.

שירות שמתעקש על גישור Ethernet הוא המבוי הסתום השני. אפליקציית אנדרואיד ללא root יכולה ליצור מנהרת IP, לא מקטע Ethernet מגושר, ולכן שום כתובת שתכתוב לא תגרום לשרת dev tap לעבוד; המפעיל חייב להציע שירות מנותב. כשאתה מדווח על הבעיה, כלול את שם הלקוח והגרסה, את מערך האפשרויות שנדחף, את הטופולוגיה ואת השלב המדויק שבו הכתובת הייתה אמורה להופיע.

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