פורטל captive ו-VPN במבוי סתום: מי זז ראשון
הפורטל של המלון דורש תעבורה לפני שהמנהרה קיימת, וה-VPN חוסם עד שהמנהרה עולה. השוו בין שני הסדרים ומה כל אחד מהם חושף בפער.
הפורטל של המלון רוצה לראות דפדפן לפני שהוא מעביר תעבורה כלשהי. ה-VPN שלכם מסרב להעביר תעבורה לפני שהמנהרה שלו עולה. כל צד מחכה לשני, ושניהם מתנהגים בדיוק כפי שהוגדרו. רק שני סדרים שוברים את המבוי הסתום הזה, והם נבדלים במה שהם חושפים בזמן שהפער פתוח. בחרו אחד בכוונה במקום לכבות ולהדליק איזו הגדרה שגורמת לדפדפן להיטען.
שני סדרים, אחד מהם עובד
או שהרשת מקבלת אתכם קודם והמנהרה באה אחר כך, או שאתם פותחים חריג צר לפורטל ומשחזרים את החסימה לאחר מכן. שניהם לגיטימיים. מה שאינו לגיטימי הוא לכבות את החסימה ולשכוח להחזיר אותה.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
שני הסדרים אינם טובים באותה מידה בכל מצב. למכשיר מנוהל עם תהליך קבלה מחייב יש תשובה אחת, ולמחשב נייד אישי על Wi-Fi של מלון יש תשובה אחרת. ההשוואה היא על מה כל אפשרות מוותרת.
התחילו בלדעת איזה מהם הלקוח ומדיניות המכשיר שלכם באמת תומכים.
אפשרות A: לקבל את הרשת, ואז לחבר את המנהרה
אשרו את שם הרשת הצפוי, ואז השתמשו בהנחיית הכניסה של מערכת ההפעלה או בזרימת פורטל captive שהלקוח תומך בה. באייפון ובאייפד, סגירת גיליון הכניסה יכולה לנתק את השיוך או לשמור אותו עם אזהרה שאין לרשת אינטרנט, ואלה נקודות התחלה שונות. השלימו קודם את שלב הקבלה, ואז העלו את המנהרה. הסדר הזה שומר על החסימה שלמה כל הזמן שהמנהרה למטה.
המלכוד הוא שפורטל שמאשר גישת אינטרנט לא אימת את חשבון ה-VPN שלכם. המנהרה עדיין צריכה להתחבר אחר כך, והיא עלולה להיכשל מסיבות של עצמה. קבלה ואימות הם אירועים נפרדים שאנשים ממזגים לאחד.
אם הקבלה ממשיכה לפוג, רשמו אם הפורטל שואל שוב, אם הרשת נופלת, או שרק ה-VPN נכשל.
אפשרות B: חריג כניסה צר, ואז שחזור החסימה
החלופה היא לאפשר את התעבורה של הפורטל בזמן שהחסימה תקפה בכל השאר, להיכנס, ואז להסיר את החריג. החריג חייב להיות צר: יעד אחד או טווח כתובות אחד, למשך הכניסה, כשהחסימה משוחזרת מיד לאחר מכן. חלון זמני רחב הוא הדרך שבה כניסה של שתי דקות הופכת לצהריים של תעבורה לא מוגנת.
דעו מה הלקוח שלכם באמת מיישם. OpenVPN Connect ב-macOS מתעד זיהוי פורטל captive בנפרד מהאפשרות שלו שחוסמת גישת אינטרנט כשהמנהרה מושהית או מתחברת מחדש. לזהות פורטל ולאפשר את התעבורה שלו הם משימות קשורות, לא הבטחות הניתנות להחלפה.
במכשיר מנוהל, פעלו לפי תהליך הקבלה המוגדר במקום להמציא חריג.
מה הפער חושף, ולמי
החלק המעניין במבוי הסתום אינו לשונית הדפדפן שמולכם. אלא כל השאר שמתחיל להשתמש ברשת ברגע שהקישוריות מופיעה: דואר, סנכרון תמונות, בדיקות עדכון, לקוח צ'אט שמתחבר מחדש, סוכן גיבוי שממשיך.
חלון דפדפן שקט לא אומר לכם דבר על אלה. סגרו או השעו עבודה רגישה לפני כל פרק גישה ישירה מותר, ובדקו מה רץ בכניסה. באנדרואיד, VPN תמיד-פעיל בשילוב עם חסימת חיבורים מחוץ ל-VPN הוא הבקרה הרלוונטית, וחריג מסלול שרירותי אינו תחליף להבנה שלו.
זה המקום היחיד שבו העצה הישנה על חלונות גישה זמניים עדיין מחזיקה. החשש היה נכון גם במקום שבו המנגנון לא היה.
איך לבחור ואיך לאמת
בחרו באפשרות A כשהמכשיר או הלקוח תומכים בזרימת פורטל אמיתית, כי היא שומרת על החסימה שלמה לאורך כל הדרך. בחרו באפשרות B כשהפורטל אינו נגיש בדרך אחרת, והתייחסו לחריג כאל שינוי מוגבל בזמן עם אחראי.
אחר כך אשרו את הסדר ולא את התוצאה:
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'השלימו את הקבלה, הקימו את הפרופיל המיועד, שחזרו כל בקרת חסימה ששונתה זמנית, ואז בצעו בקשה חדשה בלתי מזיקה ואשרו שהיא עוברת במנהרה. בקשה שמצליחה מפני שהחסימה עדיין כבויה לא מוכיחה דבר על המנהרה.
החלפת היציאה של ה-VPN לא תחדש הפעלה של מלון שפג תוקפה. אלה אירועים שונים, וערבוב ביניהם שולח אתכם לחפש במקום הלא נכון.