למה פורטל הלכידה חוסם את ה-VPN שלכם ואיך להתחבר מחדש
ה-Wi-Fi הציבורי מאשר את המכשיר שלכם לפני שיוצאת ממנו חבילה אחת. מה הפורטל משליך, למה ה-VPN שלכם מדווח על כך לא נכון, ואיזה סדר מחבר אתכם מחדש.
ברשת פתוחה נקודת הגישה שלכם לא פשוט מוסרת חבילות לאינטרנט. נקודת מדיניות במעלה הזרם בודקת אם המכשיר שלכם כבר אושר, ועד שהוא מאושר, כמעט הכול נזרק. לקוח ה-VPN שלכם קורא את הדממה הזו כשרת מת. הוא ממעט לומר זאת: WireGuard חוזר על לחיצת יד אל תוך הריק, OpenVPN מדווח על פסק זמן של חיבור, ו-IKEv2 חוזר כשגיאה 809 על שרת מרוחק שאינו מגיב.
מה הפורטל באמת שולט בו
פורטל לכידה הוא שני דברים מוצמדים: נקודת החלטת מדיניות ומפנה. כשהמכשיר שלכם מתחבר ומקבל חכירת DHCP, הרשת מציבה אתכם במצב שלפני אישור.
המצב הזה הוא מערכת כללי חומת אש. היא בדרך כלל מתירה DNS ומתירה HTTP או HTTPS לרשימה קצרה של מארחי הפורטל, והיא משליכה כל השאר. הרשימה המותרת היא הגן המגודר, והיא כמעט אף פעם אינה כוללת נקודת קצה של VPN.
אף אחת מההשלכות האלה אינה מנומסת. חבילות המכוונות לשרת VPN נזרקות ולא נדחות, כך שהלקוח לא מקבל ICMP unreachable ולא TCP reset, רק את היעדר התשובה. בהתאם לספק, המפנה עשוי להשיב לפורט 80 בהפניה לעמוד הכניסה בזמן שפורט 443 נזרק או מיורט. הפניות קלות לזיהוי מפני שהן נושאות תגובת HTTP פשוטה; יירוט ב-443 דורש תעודה שהדפדפן שלכם יסרב לבטוח בה.
האישור עצמו בדרך כלל קשור לכתובת ה-MAC של המכשיר, לעיתים ל-IP המוחכר, והוא חי בטבלת הפעלות עם טיימר. כניסה יוצרת רשומה. כלל חומת האש שמאפשר לתעבורה שלכם לעבור קיים רק כל עוד הרשומה הזו קיימת, ולכן כל הבעיה חוזרת מאוחר יותר בלי ששום דבר משתנה בצד שלכם.
למה לחיצת היד של ה-VPN מתה לפני שהיא מתחילה
לכל פרוטוקול יש התעבורה שלו, וחומת האש שלפני האישור שוברת כל אחד אחרת. IKEv2 ב-Windows וב-iOS נוסע על UDP 500 ו-UDP 4500; השלכה בפורטים האלה מופיעה כ-809, או ככשל מסוג פתרון שמות בלקוחות שמדווחים על שלבים בנפרד. OpenVPN על UDP 1194 נשאר במצב התחברות עד שפסק הזמן שלו פוג. OpenVPN על TCP 443 הוא המקרה המעניין, מפני שהפורטל עשוי להשלים את לחיצת היד של TCP ואז להשיב בעמוד ההפניה שלו, כך שאתם רואים שגיאת TLS במקום פסק זמן.
WireGuard מציג את המנגנון בצורה הבהירה ביותר. הוא UDP בלבד בתכנון, בלי חלופת TCP, כך שחומת אש שמשליכה UDP לא מוכר מסירה את התעבורה לגמרי. הלקוח ממשיך לשלוח התחלות לחיצת יד עם נסיגה הולכת וגדלה ומדווח על לחיצת יד שלעולם אינה מושלמת. שום דבר בהודעה הזו לא מזכיר Wi-Fi, ושום דבר בה לא מרמז שעליכם לפתוח דפדפן.
פלטפורמות מנסות להבחין במצב לפני ה-VPN שלכם. Windows שולף כתובת URL מוכרת כדי להחליט אם להציג את התראת הכניסה שלו, Android מבקש נקודת קצה שאמורה להשיב 204 No Content, ומכשירי Apple פותחים חלון קטן של רשת לכידה. הבדיקות האלה עובדות מפני שהפורטל משיב בהפניה במקום בגוף המצופה. אותה התנהגות מסבירה איך פורטל יכול להיראות בריא לחלוטין בזמן שהמנהרה שלכם מתה: הבדיקה והמנהרה נשפטות לפי כללים שונים.
מה תפוגת הפעלה באמת מאפסת
מקומות מפוגגים הפעלות מסיבות שאינן קשורות לחשבון ה-VPN שלכם: פסק זמן של חוסר פעילות, אורך הפעלה מרבי, חכירת DHCP חדשה, או התחברות מחדש לנקודת גישה אחרת. כשהטיימר פועל, הרשומה בטבלת ההפעלות נעלמת ומערכת הכללים שלפני האישור חוזרת בדיוק כפי שהייתה בכניסה.
מנהרה מבוססת שורדת לעיתים קרובות מספיק זמן כדי להיראות בריאה. הודעות שמירה על החיים ממשיכות לצאת, והאם הלקוח מבחין בכך תלוי באופן שבו הוא מתייחס לתעבורה שאינה נענית, כך שנורית המצב עשויה להישאר ירוקה זמן מה אחרי שהנתיב נעלם. ואז המנהרה נופלת וכל ניסיון התחברות מחדש נכשל באותם פורטים חסומים.
בשלב הזה שגיאת הלקוח אומרת לכם באיזה שלב אתם נמצאים, אם תקראו אותה בתשומת לב:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
פרט אחד מטעה אנשים: כשההפעלה קשורה לכתובת MAC, טעינה מחדש של עמוד הכניסה עשויה לא לעזור. עליכם לנתק את החיבור ולהתחבר שוב כדי שהפורטל יראה ניסיון אישור חדש במקום אחד שפג.
קודם התחברו, ואז העלו את המנהרה
הסדר שעובד הוא: אשרו את המכשיר, הוכיחו את הנתיב, הפעילו את ה-VPN, הוכיחו את המנהרה, ואז החזירו את החסימה הרגילה שלכם. הצעד האחרון חשוב מפני שהמצב הזמני שאתם צריכים כדי להגיע לפורטל הוא בדיוק המצב שמתג הרג חוסם כדי למנוע.
לקוח שולחני עם אפשרות לחסום מחוץ למנהרה חייב להיות מושהה כדי שעמוד הפורטל ייטען, וכדאי להשאיר אפליקציות רגישות סגורות במהלך חלון החוץ-מנהרה הזה; זהו המרווח היחיד שבו תעבורה מקומית יוצאת בלי הגנה. מכשיר מנוהל שדולק תמיד צריך להשתמש בהליך שבעליו פרסם במקום שתסירו אתם את המדיניות. אם הפורטל מציג אזהרת תעודה, עצרו: קבלתה מנתבת את ההפעלה שלכם דרך פרוקסי היירוט של המקום, ופרוקסי כזה יכול לקרוא כל מה שאתם שולחים. ב-Android הנעילה תחת VPN שדולק תמיד חוסמת תעבורה לפני שהמנהרה עולה, וחלק מהבניות אינן יכולות לפטור את זרימת הפורטל; אם שלכם אינה יכולה, השתמשו בגישה החלופית של המקום או במכשיר אחר במקום להשאיר את הנעילה כבויה. כללי Apple לפי דרישה ניתנים לכתיבה כך שיסרבו למנהרה עד שבדיקה תצליח, וזו ההתנהגות שאתם רוצים ברשתות מלון.
אמתו לפי הסדר בכלים שכבר יש לכם. לפני המנהרה, הריצו את הבדיקה כשהכותרות והגוף שניהם גלויים, וצפו אם התעבורה של ה-VPN מקבלת תשובה כלשהי:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'לפני אישור, פורטל רגיל נותן אחת משתי תשובות: 302 שה-Location שלו מצביע לעמוד הכניסה, או 200 עם גוף HTML שהוא עמוד הפורטל. רשמו איזו קיבלתם. הפניה אינה כשל לפני כניסה; הפורטל אומר לכם לאן ללכת. אחרי שהפורטל מדווח על הצלחה, חזרו על הפקודה וצפו ל-200 שגופו הוא המילה המילולית Success. המחרוזת הזו היא מה שהופך את הבדיקה למשמעותית. אם המארח עונה כרגיל לפני שאי פעם התחברתם, אין ברשת הזו פורטל מיירט. בלכידה, השלכה שלפני אישור היא חבילות יוצאות ששום דבר לא חוזר מהן, בעוד נתיב שעובד מציג תשובה לאותו זרם בתוך כשנייה. התחברו, ואז חזרו על הלכידה.
אם המנהרה עדיין נכשלת אחרי שהפורטל אומר כן
הצלחת כניסה אינה אותו דבר כמו תעבורה מותרת. מקומות רבים מתירים את הפורטל ואת הגלישה הרגילה בזמן שהם חוסמים UDP לחלוטין, מה שמשאיר את WireGuard ואת OpenVPN על UDP שבורים ואת TCP 443 עובד. אם TCP 443 עובר ו-UDP לא, זו מדיניות המקום ולא לקוח שהגדרתם לא נכון, אז החליפו תעבורה או קבלו את המגבלה והמשיכו. אם התחברות מחדש עדיין נכשלת אחרי זה, שמרו את השגיאה המדויקת; היא נוקבת בשלב שבו אתם תקועים.
כשלים אחרים חיים במכשיר. הפעלה שעדיין קשורה ל-MAC ישן, מתאם Wi-Fi שני עם החכירה משלו, או לקוח ששמר במטמון את חריגת התעודה של הפורטל — כל אחד מהם יכול להמשיך להיכשל אחרי אישור מחדש נקי. נתקו את החיבור, אשרו מחדש, ונסו פעם אחת לפני שאתם נוגעים בהגדרות הלקוח. RFC 8952 שווה קריאה אם אתם רוצים את הארכיטקטורה שמאחורי הרכיבים שאתם צופים בהם.
אם הפורטל עצמו מסרב לאשר, הבעיה היא בחשבון או בהקצאת המכשיר ואף הגדרת VPN לא תתקן אותה. שינוי ארץ היציאה של ה-VPN אינו מאפס את מצב הגישה המקומי של המקום; הטבלה הזו קשורה למכשיר שלכם, לא לשרת שתבחרו. שאלו את מפעיל המקום ותנו לו זמן, מפני שטבלת ההפעלות היא מה שהוא יסתכל עליו.
לפני הנסיעה הבאה שלכם, רשמו שלושה דברים: עמוד הפורטל כצעד אפס, צעד השהיית החסימה לכל מכשיר שאתם נושאים, וחלופת תעבורה אחת שבאמת בדקתם. כשמנהרה שעבדה לפני עשר דקות נעצרת שוב, התייחסו אליה כאישור שפג ובדקו שוב את הפורטל לפני שאתם נוגעים בפרופיל ה-VPN.