Wi-Fi במלון: ה-VPN נכשל לפני שהוא מגיע לשרת

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

המיתוס: המלון חוסם VPN

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

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

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

סיים קודם את הפורטל, ואז בדוק HTTPS רגיל

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

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

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

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

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

שמור על הפרופיל המקורי ועל השגיאה שלו

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

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

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

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

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

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

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

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

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