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

התחילו במקום שבו התעבורה מתחילה

בחרו אפליקציה אחת שאמורה להשתמש במנהרה ובדקו אם יש לה הגדרת פרוקסי משלה. דפדפן עם שדה SOCKS הוא המקרה הקל: כוונו אותו אל 127.0.0.1:1080, הפעילו DNS מרוחק אם ההגדרה קיימת, והבקשה עוברת. לקוח צ'אט, אפליקציית מפות או משחק בלי שדה כזה אין דרך להשתמש במאזין, ושום דבר שתקלידו בפקודת SSH לא משנה את זה.

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

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

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

הוסיפו את החלק שאנדרואיד צריכה

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

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

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

השאירו את תעבורת ה-SSH מחוץ ללכידה

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

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

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

עקבו אחרי DNS ו-UDP עד סוף השרשרת

ההעברה הדינמית של OpenSSH נושאת חיבורי TCP. היא לא תעבורת UDP-associate או ICMP, ומתאם לא יכול להמציא העברת UDP בכך שהוא מקבל מנות UDP. כל מה שמתעקש על UDP, כולל QUIC ומדיה של WebRTC, ייכשל או ייפול חזרה ל-TCP בהתאם לאפליקציה.

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

השאירו את מאזין ה-SOCKS קשור ל-loopback, אמתו את מפתח המארח של שרת ה-SSH בשימוש הראשון, והשאירו אימות HTTPS רגיל במקומו לאתר הסופי. SSH מגן על הקטע שבין הטלפון לשרת; הוא לא מצפין את מה שהשרת עושה אחר כך.

בדקו את שני מחזורי החיים והחליטו

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

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

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

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