Защо порталът за прихващане спира вашия 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 наем или повторно свързване към друга точка за достъп. Когато таймерът задейства, записът в таблицата на сесиите изчезва и наборът от правила преди разрешение се връща точно такъв, какъвто е бил при регистрацията.

Установеният тунел често оцелява достатъчно дълго, за да изглежда здрав. Съобщенията за поддържане на връзката продължават да излизат и дали клиентът ще го забележи, зависи от това как третира трафик без отговор, така че индикаторът за състояние може да остане зелен известно време след изчезването на пътя. После тунелът пада и всеки опит за повторно свързване се проваля на същите блокирани портове.

В този момент грешката на клиента ви казва на кой етап сте, ако я прочетете внимателно:

Една подробност обърква хората: когато сесията е обвързана с 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 профила.