OpenVPN באנדרואיד: הוספת נתיב פרטי בלי לעשות רוט לטלפון
הוסיפו נתיב אחד בתוך הפרופיל שאנדרואיד באמת טוען, ואז בדקו שהשרת מאפשר אותו. מדריך לעריכה, לחיבור מחדש ולארבע בדיקות.
אתם צריכים עוד תת-רשת פרטית אחת — נגיד 10.60.0.0/24 — שהפרופיל לא כולל כרגע. במחשב נייד הייתם מוסיפים נתיב וממשיכים הלאה. באנדרואיד ה-VPN הוא אפליקציה, התקן ה-tun שייך לאותה אפליקציה, ואין טבלת ניתוב שתוכלו לערוך בלי רוט. הנתיב חייב בכל זאת להתקיים, אבל הוא נכנס לפרופיל שהלקוח טוען, והוא עובד רק אם הצד השני מסכים. הנה העריכה, החיבור מחדש, צד השרת והחזרה לאחור.
לפני העריכה: מה נתיב יכול לעשות ומה הוא לא יכול
נתיב עונה על שאלה אחת: איזה ממשק צריך לשאת את התעבורה אל היעד הזה. הוא לא מאשר דבר. אם בעל הרשת לא הסכים שהטלפון הזה יגיע לתת-הרשת ההיא, נתיב נכון ייצור תצורה שנראית נכונה ונפילה שקטה בשער, ואת השעה הבאה תבזבזו על עריכת הקובץ הלא נכון.
השיגו קודם את ההסכמה, בכתב אם לרשת יש בעלים. אחר כך רשמו מה אתם לא עושים: אתם לא מקצים לטלפון כתובת בתוך ה-LAN ההוא, לא משנים את המאזין של השרת, ולא בוחרים אתר לפי שם מארח. אלה ארבעה שינויים שונים ורק הראשון שלכם.
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
ערכו את הפרופיל שהלקוח באמת טוען
עבור לקוח תואם שמייבא טקסט אפשרויות OpenVPN רגיל, התוספת היא שורה אחת:
route 10.60.0.0 255.255.255.0הוסיפו אותה לגוף הפרופיל, ליד שאר הוראות הניתוב, והשאירו את ה-endpoint, האישורים, טיפול במפתחות ושורות האימות של המפעיל בדיוק כפי שהיו. אל תדביקו דוגמה ישנה שלמה כדי לשאול שורה אחת: דחיסה, נתיבי קבצים מוחלטים והגדרות cipher מיושנות מגיעות איתה ויעלו לכם בסשן ניפוי באגים נפרד.
השלב שאנשים מפספסים הוא הבעלות על הקובץ. אם האפליקציה ייבאה פרופיל, העותק שבו היא משתמשת הוא של האפליקציה, ועריכה של המקור שהורד לא משנה דבר. השתמשו בעורך הנתמך של הלקוח, או ייבאו מחדש את הקובץ הערוך דרך מסלול העדכון, ואשרו את שם הפרופיל הפעיל כשיש כמה שמות דומים. תעדו איזה אחד שיניתם.
אם הפרופיל כבר נושא route-nopull, לא מותקן שום נתיב מהשרת וכל קידומת שהטלפון צריך חייבת להירשם במפורש. זה עיצוב לגיטימי, אבל פירושו ששורה שהושמטה נראית בדיוק כמו סירוב של השרת.
התחברו מחדש ואמתו במכשיר
נתקו קודם, ואז התחברו מחדש לפרופיל הספציפי שערכתם במקום לתת לאפליקציה לשחזר את הסשן האחרון. פתחו את יומן החיבור ואשרו שהלקוח פענח את השורה החדשה; הוראת ניתוב שהממשק מתעלם ממנה היא תוצאה נפוצה של עריכת העותק הלא נכון.
בדקו את היעד לפי כתובת, לא לפי שם. בדיקת TCP לפורט שירות מוכר אחד מספקת יותר מידע מ-ping, כי הרבה מארחים עונים ל-ICMP בזמן שפורט השירות מסונן. אם הכתובת עונה ושם לא, יש לכם שאלת resolver ולא שאלת ניתוב, והסעיף הבא לא בשבילכם.
שתי בדיקות היקף שייכות לכאן גם כן. VPN לפי אפליקציה אומר שנתיב כתובת יכול להתקיים בזמן שהאפליקציה שאתם בודקים איתה נמצאת מחוץ לקבוצה הכלולה, אז בדקו עם אפליקציה שנמצאת באמת בפנים. וקידומת IPv4 לא אומרת דבר על מסלול IPv6; אם השירות dual-stack, הוסיפו את נתיב ה-IPv6 המתאים או צפו שהלקוח יעדיף מסלול שלא התכוונתם אליו.
תוצאה שלילית אחת שווה זיהוי מוקדם: אם נתיב full-tunnel כבר מכסה 0.0.0.0/0, הקידומת לא חסרה והוספה חוזרת שלה לא משנה דבר. כיסוי כפול לא מתקן סירוב מצד השרת ולא תשובה חסרה.
השלימו את המסלול בשרת
שלושה דברים חייבים להיות נכונים מעבר לטלפון. השער צריך נתיב ליעד והרשאה להעביר את מקור הטלפון לעברו. היעד צריך לקבל את המקור הזה ולהחזיר תשובות דרך השער, אחרת העיצוב צריך תרגום מכוון ביציאה. אפשרות route במדריך OpenVPN מכסה את ההוראה בצד הלקוח; העברה וניתוב חזור הם הגדרות נפרדות במכונות נפרדות.
אם היעד יושב מאחורי לקוח VPN אחר ולא ישירות מאחורי השער, השרת צריך iroute עבור תת-הרשת של אותו עמית. ההוראה הזו שייכת לשרת ומתארת איזה לקוח מחזיק בקידומת; טלפון לא יכול לספק אותה מהפרופיל שלו, וכל כמות של עריכה בצד הלקוח לא מחליפה אותה.
בדקו את מסלול החזור במפורש. תשובה שיוצאת בנתיב ברירת המחדל במקום במנהרה מייצרת את התסמין הקלאסי של חיבור חצי-פתוח: החיבור נוצר בכיוון אחד ושום דבר לא חוזר. תרגום מקור בשער הוא תיקון לגיטימי כשהיעד לא יכול לנתב חזרה, אבל זו החלטת מדיניות עם השלכות משלה.
חזרה לאחור וקבלה
שמרו את הפרופיל הקודם לפני העריכה. אם השינוי מחמיר את המצב, שחזרו את העותק הזה דרך אותו מסלול ייבוא מחדש, התחברו מחדש, ואשרו שההתנהגות הישנה חוזרת — זה מאשר ששיניתם את מה שחשבתם ששיניתם. חזרה לאחור שלא משחזרת את המצב הישן משמעה שהאפליקציה מחזיקה עותק שלישי שלא מצאתם.
קבלו את השינוי כשארבעה דברים מתקיימים, נבדקים בסדר הזה אחרי חיבור מחדש טרי: היעד עונה בפורט השירות שלו, השם הפרטי נפתר אם מצפים לו, HTTPS עדיין מאמת את שם המארח המיועד, והכול עדיין עובד אחרי הפעלה מחדש או מעבר מ-Wi-Fi לרשת סלולרית. הבדיקה האחרונה היא זו שתופסת נתיב שקיים רק עד שאנדרואיד משקם את המנהרה.
- אשרו שבעל הרשת מתיר את היעד לפני שמשנים משהו.
- שימו את הנתיב בפרופיל שהלקוח טוען, ואז ייבאו מחדש והתחברו מחדש.
- אמתו לפי פורט שירות, בתוך ההיקף לפי אפליקציה, עבור משפחת הכתובות הנכונה.
- תקנו העברה, ניתוב חזור ו-iroute בשרת, לא בטלפון.
- שמרו עותק לחזרה לאחור, ובדקו שוב אחרי הפעלה מחדש.