Зашто портал за прихватање блокира ваш 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 профил.