Зошто порталот за заробување го блокира вашиот 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 и UDP OpenVPN расипани, а TCP 443 работи. Ако TCP 443 поминува а UDP не, тоа е политика на местото, а не клиент што погрешно сте го конфигурирале, затоа сменете транспорт или прифатете го ограничувањето и продолжете. Ако повторното поврзување и потоа не успева, чувајте ја точната грешка; таа ја именува фазата во која сте заглавени.
Другите неуспеси живеат на уредот. Сесија која и понатаму е врзана за стар MAC, втор Wi-Fi адаптер со сопствен закуп, или клиент што го кеширал изземвањето на сертификатот на порталот — секој од нив може да продолжи да не успева по чисто повторно овластување. Прекинете ја поврзаноста, овластете повторно и обидете се еднаш пред да ги допрете поставките на клиентот. RFC 8952 вреди да се прочита ако ја сакате архитектурата зад компонентите што ги набљудувате.
Ако самиот портал одбие да овласти, проблемот е во сметката или во распределбата на уредот и ниту една VPN поставка нема да го поправи. Менувањето на излезната земја на VPN не ја ресетира локалната состојба на пристап на местото; таа табела е врзана за вашиот уред, не за серверот што го избирате. Прашајте го операторот на местото и дајте му време, бидејќи табелата на сесии е она што ќе го гледа.
Пред следното патување, запишете три работи: страницата на порталот како нулти чекор, чекорот за паузирање на блокирањето за секој уред што го носите, и еден резервен транспорт што навистина сте го тестирале. Кога тунел што работел пред десет минути повторно ќе застане, третирајте го како истечено овластување и повторно проверете го порталот пред да го допрете VPN профилот.