העברת פורטים בנקודה חמה באנדרואיד: שלוש נקודות כניסה

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

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

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

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

בגרסת פיתוח ניתנת לניפוי, adb shell יכול להציג סוקטים דרך /proc/net/tcp, אבל עבור רוב האנשים הסטטוס של האפליקציה עצמה הוא המקור הישר. זה גם מונע את המלכודת של בדיקת סוקט שהאפליקציה פתחה על כתובת שלא ציפיתם לה.

נקודת הכניסה הראשונה: מכשיר אחר בנקודת הגישה

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

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

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

נקודת הכניסה השנייה: המסלול של הספק

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

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

נקודת הכניסה השלישית: יציאת ה-VPN

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

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

בדקו מסלול אחד מקצה לקצה, ואז תנו שם לבעלים

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

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

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

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