שרת VPN באנדרואיד: root לא הופך את הטלפון לנגיש
שלוש בעיות נפרדות קובעות אם טלפון יכול לשרת לקוחות VPN: נתיב הכניסה, מודל ההרשאות וההעברה. root נוגע רק באמצעית.
root משנה אילו פעולות רשת מותר לתהליך לנסות. הוא לא נותן לטלפון כתובת נגישה לציבור, לא שומר מיפוי נכנס אצל המפעיל, ולא משאיר דמון חי לאחר אתחול. אם אתם מחליטים אם טלפון אנדרואיד יכול לשמש כשרת VPN, הפרידו שלוש שאלות: האם הלקוח המיועד יכול בכלל להגיע למאזין, איזה מודל הרשאות דורשת מימוש השרת, ומה צריך להעביר לאחר שהמנהרה עולה.
מי צריך להגיע לטלפון, ומאיפה
לקוח באותה רשת LAN מורשית ולקוח על נתונים סלולריים בודקים שתי רשתות שונות. הכריעו קודם לגבי המיועדת, כי התשובות אינן מועברות. ב-Wi-Fi, תעבורה נכנסת לא מבוקשת זקוקה בדרך כלל למיפוי בנתב שמעליו ולנתיב ציבורי שמיש מעבר לו. ברשת הסלולרית, NAT ברמת המפעיל פירושו ש-IPv4 נכנס לעיתים קרובות אינו זמין, יהיה אשר יהיה מה שהטלפון מאפשר.
הנקודה האחרונה היא זו ש-root אינו יכול לגעת בה. חומת האש המקומית של הטלפון וה-NAT של המפעיל הן מערכות שונות, ולשינוי הראשונה אין השפעה על השנייה. כתובת ממשק פרטית, סמל נתונים סלולריים או socket שמאזין אינם הוכחה לנגישות. אם נתיב המפעיל כן מציע IPv6 שניתן לנתבו גלובלית, עדיין דרושה לכם מדיניות מאזין וחומת אש מכוונת עבורו; החזקת כתובת אינה זהה לקבלת חיבורים.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
שירות והעברה הם שני הצלחות שונות
לחיצת יד VPN שהושלמה מוכיחה שהמנהרה קיימת. היא אינה מוכיחה שהלקוח יכול להגיע ל-LAN שמאחורי הטלפון, ואינה מוכיחה שהטלפון יכול לשמש כיציאה לאינטרנט. אלה תצורות נפרדות הבנויות על תוכנית הכתובות הפנימית, המסלולים, התנהגות החזרה ומדיניות העברה מצומצמת למשימה שאתם באמת רוצים.
מצב הכשל צפוי: לחיצת היד מצליחה, הלקוח מציג מחובר, ושום דבר לא נטען. לפני שאתם מאתרים תקלות בלקוח, החליטו איזה משני התפקידים אתם בונים. גישה מרחוק להתקן ברשת הטלפון ויציאה לאינטרנט דרך מנהרה מלאה דורשות כללי העברה שונים, ומתן שניהם כשאתם רציתם אחד מרחיב את החשיפה בלי להוסיף את היכולת שביקשתם.
מודל ההרשאות הוא בחירה, לא root או כלום
דמון OpenVPN קונבנציונלי המשתמש בהתקן TUN של הקרנל זקוק ליכולות המתאימות, לגישה לצומת ההתקן ולשיתוף פעולה של מדיניות האבטחה של אנדרואיד. root אינו פטור גורפת מ-SELinux; תהליך מיוחס עדיין מוגבל על ידי מדיניות הפלטפורמה. לכן קובץ בינארי שרץ היטב בשרת Linux עלול להיכשל בטלפון בלי שגיאה ברורה לגבי הרשאות.
מימוש שער במרחב המשתמש יכול להיות בעל מודל הרשאות שונה לחלוטין, ולכן הטענה הנפוצה שכל שרת VPN באנדרואיד זקוק ל-root רחבה מדי. מה ש-root קונה לכם הוא היכולת לנסות יותר פעולות, לא הבטחה שהן יורשו או שהתוצאה תהיה נגישה.
רישום שירות ה-VPN של אנדרואיד עצמו הוא מנגנון נפרד נוסף. הוא נותן לאפליקציה ממשק לקוח מנוהל עם מחזור חיים מוגדר; הוא אינו מתקין שרת כללי, והפעלת דמון מהמסוף אינה נותנת לו ניהול קבוע, מדיניות לפי אפליקציה או נתיב התאוששות משלו.
אם אתם רוצים נקודת יציאה, שנו את הארכיטקטורה
כשהמטרה היא פשוט יציאת אינטרנט מרחוק דרך הטלפון ולא תאימות לפרופיל OpenVPN קיים, צומת יציאה נתמך ברשת שכבה מתאימה יותר. Tailscale מתעדת תפקיד צומת יציאה לאנדרואיד עם שלבי הרישום, ההרשאה ובחירת הלקוח שלה.
התמורה אמיתית וראויה לומר אותה בפשטות: אתם מקבלים פרוטוקול אחר, מודל אמון אחר ותלות בחשבון ובשירות התיאום האלה. היא אינה גורמת ללקוח OpenVPN שלא שונה להצטרף לרשת השכבה, ואינה נותנת לכם מאזין OpenVPN בכתובת ציבורית.
מה עוד נדרש לפריסה
באיזה נתיב שתבחרו, היסודות התפעוליים קובעים אם זה ישרוד שבוע. שמרו על פרטיות פרטי הכניסה של השרת, הנפיקו זהויות לקוח נפרדות ותכננו ביטול לפני שתזדקקו לו. החליטו איך מגיעים עדכונים, מה משאיר את השירות פועל ברקע ואיך הוא מתאושש לאחר אתחול או שינוי רשת.
הימנעו מקיצורי הדרך שנראים נוחים: קובץ בינארי סטטי מיושן, שמות ממשק מקודדים בקשיחות וסקריפט אתחול שמוחק את מדיניות חומת האש הקיימת. אחר כך קבלו את התוצאה רק מול בדיקה קונקרטית: לקוח מרוחק מורשה מגיע למשאב המיועד, יעדים אסורים נשארים לא זמינים, והמכשיר חוזר מעצמו לאחר אירוע מחזור החיים הנתמך. גישת root היא מרכיב אפשרי בתוצאה הזו, ולעיתים רחוקות המכריע.