Wi-Fi у готелі: VPN зривається ще до того, як досягне сервера
Тунель зривається, бо портал авторизації ще не дозволив вас. Увійдіть у мережу готелю, переконайтеся, що звичайний HTTPS працює, і лише потім підключайте 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 зламався.