האם ה-VPN של הטלפון מכסה את המחשב הנייד בנקודת הגישה שלו?

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

מה נקודת הגישה באמת מעבירה

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

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

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

תנאי ראשון: איזו מנהרה הטלפון מריץ

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

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

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

תנאי שני: האם שיתוף החיבור נכלל

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

מעבר מ-Wi-Fi ל-USB לא משנה את זה. תת-המערכת של שיתוף החיבור תומכת בכמה אמצעי תעבורה, אבל אמצעי התעבורה אינו החלטת הניתוב. כבל הופך את החיבור ליציב יותר ולא עושה דבר לכיסוי המנהרה, ולכן העצה “פשוט להשתמש ב-USB” עונה על שאלה אחרת מזו שנשאלה.

מתכונים ישנים שמנקים כללי חומת אש ומניחים שמות ממשק מסוימים אינם הוראות ניידות. הם נכתבו עבור מכשיר מסוים, ROM מסוים ושנה מסוימת, והחלתם על מכשיר נוכחי תשבור את שיתוף החיבור לעתים קרובות יותר משתרחיב מנהרה.

תנאי שלישי: איזו זהות היעד צריך

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

ip -brief addr show
curl -sS https://ifconfig.me/ip
dig +short myip.opendns.com @resolver1.opendns.com

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

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

מה לעשות במקום, לפי סדר המאמץ

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

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

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