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

מה באמת מגביל כלל ה-VPN האחד

VpnService הוא משאב בעל משבצת אחת. כשאפליקציה מקימה מנהרה היא הופכת ל-VPN של המכשיר, ואפליקציה שנייה שמנסה להקים אחת נדחית עד שהראשונה נעלמת. זהו כלל על הבעלות במנהרה, והוא מסביר מדוע שני לקוחות VPN אינם יכולים לרוץ בו-זמנית.

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

המאזין הוא יעד, לא חלק מהמנהרה

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

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

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

נתיב התגובה הוא המקום שבו זה בדרך כלל נשבר

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

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

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

עקיפת ה-VPN אינה מתקנת שירות נכנס

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

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

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

אבחנו כיוון אחד בכל פעם

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

הריצו את בדיקת הפורט מהעמית, לא מהטלפון, וקראו את הפלט המפורט של לקוח ה-SSH כדי לראות אם הוא נכשל לפני או אחרי לחיצת היד של TCP. socket שלעולם אינו מתחבר וכניסה שנדחית הם שלבים שונים עם אחראים שונים.

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

מאמרים קשורים