Zašto zarobni portal blokira vaš VPN i kako se ponovo prijaviti

Na otvorenoj mreži vaša pristupna tačka ne predaje pakete internetu tek tako. Tačka politike uzvodno provjerava da li je vaš uređaj već odobren, i dok nije, skoro sve se odbacuje. Vaš VPN klijent tu tišinu čita kao mrtav server. Rijetko to i kaže: WireGuard ponavlja rukovanje u prazno, OpenVPN prijavljuje istek veze, a IKEv2 se vraća kao greška 809 o udaljenom serveru koji ne odgovara.

Šta portal zapravo kontroliše

Zarobni portal su dvije stvari spojene: tačka odlučivanja o politici i preusmjerivač. Kada se vaš uređaj poveže i uzme DHCP zakup, mreža vas stavlja u stanje prije odobrenja.

To stanje je skup pravila vatrozida. Obično dopušta DNS i dopušta HTTP ili HTTPS prema kratkoj listi portalnih hostova, a sve ostalo odbacuje. Dopuštena lista je ograđena bašta i skoro nikada ne uključuje VPN odredište.

Nijedno od tih odbacivanja nije učtivo. Paketi namijenjeni VPN serveru se odbacuju, a ne odbijaju, pa klijent ne dobija ni ICMP unreachable ni TCP reset, samo odsustvo odgovora. Zavisno od proizvođača, preusmjerivač može odgovoriti na port 80 preusmjerenjem na stranicu za prijavu, dok se port 443 odbacuje ili presreće. Preusmjerenja je lako uočiti jer nose običan HTTP odgovor; presretanje na 443 traži certifikat kojem vaš pregledač neće vjerovati.

Samo odobrenje obično je vezano za MAC adresu uređaja, ponekad za zakupljeni IP, i živi u tabeli sesija s tajmerom. Prijava stvara zapis. Pravilo vatrozida koje propušta vaš saobraćaj postoji samo dok postoji taj zapis, i zato se cijeli problem vraća kasnije bez ikakve promjene na vašoj strani.

Zašto VPN rukovanje umire prije nego što počne

Svaki protokol ima svoj transport, a vatrozid prije odobrenja kvari svaki drugačije. IKEv2 na Windowsu i iOS-u ide preko UDP 500 i UDP 4500; odbacivanje na tim portovima pojavljuje se kao 809, ili kao kvar nalik razrješavanju imena na klijentima koji faze prijavljuju odvojeno. OpenVPN preko UDP 1194 ostaje u stanju povezivanja dok ne istekne njegov rok. OpenVPN preko TCP 443 je zanimljiv slučaj, jer portal može dovršiti TCP rukovanje i zatim odgovoriti svojom stranicom preusmjerenja, pa vidite TLS grešku umjesto isteka roka.

WireGuard najjasnije pokazuje mehanizam. Dizajniran je samo za UDP, bez TCP rezerve, pa vatrozid koji odbacuje nepoznati UDP potpuno uklanja transport. Klijent nastavlja slati početke rukovanja s rastućim pauzama i prijavljuje rukovanje koje se nikada ne dovrši. Ništa u toj poruci ne spominje Wi-Fi, i ništa u njoj ne sugeriše da treba otvoriti pregledač.

Platforme pokušavaju primijetiti stanje prije vašeg VPN-a. Windows dohvata poznati URL da odluči hoće li prikazati obavještenje o prijavi, Android traži odredište koje bi trebalo odgovoriti 204 No Content, a Apple uređaji otvaraju mali prozor zarobljene mreže. Te provjere rade jer portal odgovara preusmjerenjem umjesto očekivanog tijela. Isto ponašanje objašnjava kako portal može izgledati potpuno zdravo dok je vaš tunel mrtav: provjera i tunel ocjenjuju se po različitim pravilima.

Šta istek sesije zapravo resetuje

Lokali ukidaju sesije iz razloga nepovezanih s vašim VPN računom: istek mirovanja, najveća dužina sesije, novi DHCP zakup ili ponovno povezivanje na drugu pristupnu tačku. Kada tajmer opali, zapis u tabeli sesija nestaje i skup pravila prije odobrenja vraća se tačno onakav kakav je bio pri prijavi.

Uspostavljeni tunel često preživi dovoljno dugo da izgleda zdravo. Poruke za održavanje veze nastavljaju izlaziti, a to hoće li klijent to primijetiti zavisi od toga kako tretira saobraćaj bez odgovora, pa statusno svjetlo može ostati zeleno neko vrijeme nakon što put nestane. Zatim tunel padne i svaki pokušaj ponovnog povezivanja ne uspije na istim blokiranim portovima.

U tom trenutku greška klijenta vam kaže na kojoj ste fazi, ako je pažljivo pročitate:

Jedan detalj zbunjuje ljude: kada je sesija vezana za MAC adresu, ponovno učitavanje stranice za prijavu možda neće pomoći. Morate odbaciti povezanost i ponovo se pridružiti da bi portal vidio novi pokušaj odobrenja umjesto isteklog.

Prvo se prijavite, zatim podignite tunel

Redoslijed koji radi je: odobrite uređaj, dokažite put, pokrenite VPN, dokažite tunel, zatim vratite svoje uobičajeno blokiranje. Taj posljednji korak je važan jer je privremeno stanje koje vam treba da biste došli do portala upravo stanje koje sigurnosni prekidač postoji da spriječi.

Desktop klijent s opcijom blokiranja izvan tunela mora se pauzirati da bi se stranica portala učitala, i osjetljive aplikacije treba držati zatvorene tokom tog prozora izvan tunela; to je jedini interval kada lokalni saobraćaj izlazi nezaštićen. Upravljani uređaj koji je stalno uključen treba da koristi proceduru koju je objavio njegov vlasnik, umjesto da vi uklanjate politiku. Ako portal prikaže upozorenje o certifikatu, stanite: prihvatanje preusmjerava vašu sesiju kroz presretački proxy lokala, a taj proxy može čitati sve što pošaljete. Na Androidu zaključavanje pod stalno uključenim VPN-om blokira saobraćaj prije nego što se tunel podigne, a neke verzije ne mogu izuzeti tok portala; ako vaša ne može, koristite alternativni pristup lokala ili drugi uređaj umjesto da ostavite zaključavanje isključeno. Appleova pravila na zahtjev mogu se napisati tako da odbiju tunel dok provjera ne uspije, a to je ponašanje koje želite na hotelskim mrežama.

Provjeravajte po redu alatima koje već imate. Prije tunela pokrenite provjeru s vidljivim i zaglavljima i tijelom, i gledajte dobija li vaš VPN transport ikakav odgovor:

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'

Prije odobrenja normalan portal daje jedan od dva odgovora: 302 čiji Location pokazuje na stranicu za prijavu, ili 200 s HTML tijelom koje je stranica portala. Zapišite koji ste dobili. Preusmjerenje nije neuspjeh prije prijave; to vam portal govori kuda da idete. Nakon što portal prijavi uspjeh, ponovite komandu i očekujte 200 čije je tijelo doslovna riječ Success. Taj niz je ono što provjeru čini smislenom. Ako host odgovara normalno prije nego što ste se ikada prijavili, na ovoj mreži nema presretačkog portala. U snimku je odbacivanje prije odobrenja odlazne pakete iz kojih se ništa ne vraća, dok radni put pokazuje odgovor na isti tok u roku od oko sekunde. Povežite se, zatim ponovite snimak.

Ako tunel i dalje ne uspijeva nakon što portal kaže da

Uspjeh prijave nije isto što i dopušteni transport. Mnogi lokali dopuštaju portal i obično pregledanje dok potpuno blokiraju UDP, što ostavlja WireGuard i UDP OpenVPN pokvarenim, a TCP 443 radnim. Ako TCP 443 prolazi a UDP ne, to je politika lokala, a ne klijent koji ste pogrešno podesili, pa promijenite transport ili prihvatite ograničenje i nastavite. Ako ponovno povezivanje i nakon toga ne uspije, sačuvajte tačnu grešku; ona imenuje fazu u kojoj ste zaglavili.

Ostali kvarovi žive na uređaju. Sesija koja je još vezana za stari MAC, drugi Wi-Fi adapter s vlastitim zakupom, ili klijent koji je keširao izuzetak certifikata portala, svaki od njih može nastaviti ne uspijevati nakon čistog ponovnog odobrenja. Odbacite povezanost, ponovo odobrite i pokušajte jednom prije nego što dirate postavke klijenta. RFC 8952 vrijedi pročitati ako želite arhitekturu iza komponenti koje gledate.

Ako sam portal odbije odobrenje, problem je u računu ili dodjeli uređaja i nikakva VPN postavka to neće popraviti. Promjena izlazne zemlje VPN-a ne resetuje lokalno stanje pristupa lokala; ta tabela je vezana za vaš uređaj, a ne za server koji odaberete. Pitajte operatera lokala i dajte mu vremena, jer tabela sesija je ono što će gledati.

Prije sljedećeg putovanja zapišite tri stvari: stranicu portala kao nulti korak, korak pauziranja blokiranja za svaki uređaj koji nosite, i jedan rezervni transport koji ste stvarno testirali. Kada tunel koji je radio prije deset minuta ponovo stane, tretirajte to kao isteklo odobrenje i ponovo provjerite portal prije nego što dirate VPN profil.