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 е повреден.