Kāpēc gūstekņu portāls bloķē jūsu VPN un kā atkal pieteikties

Atvērtā tīklā jūsu piekļuves punkts vienkārši nenodod paketus internetam. Politikas punkts augstāk pārbauda, vai jūsu ierīce jau ir autorizēta, un, kamēr tā nav, gandrīz viss tiek izmests. Jūsu VPN klients šo klusumu nolasa kā mirušu serveri. Tas to reti pasaka: WireGuard atkārto roku paspiešanu tukšumā, OpenVPN ziņo par savienojuma taimautu, un IKEv2 atgriežas ar kļūdu 809 par attālu serveri, kas neatbild.

Ko portāls patiešām kontrolē

Gūstekņu portāls ir divas saskavotas lietas: politikas lēmuma punkts un pāradresētājs. Kad jūsu ierīce pieslēdzas un saņem DHCP nomu, tīkls jūs ievieto stāvoklī pirms autorizācijas.

Šis stāvoklis ir ugunsmūra noteikumu kopa. Tā parasti atļauj DNS un atļauj HTTP vai HTTPS uz īsu portāla resursdatoru sarakstu, un visu pārējo izmet. Atļautais saraksts ir ar mūri apjozts dārzs, un tajā gandrīz nekad nav VPN galapunkta.

Neviena no šīm izmešanām nav pieklājīga. Uz VPN serveri vērstie paketi tiek izmesti, nevis noraidīti, tāpēc klients nesaņem ne ICMP unreachable, ne TCP reset, tikai atbildes neesamību. Atkarībā no ražotāja pāradresētājs var atbildēt uz 80 portu ar pāradresāciju uz pieteikšanās lapu, kamēr 443 ports tiek izmests vai pārtverts. Pāradresācijas ir viegli pamanīt, jo tās nes vienkāršu HTTP atbildi; pārtveršanai 443 portā vajag sertifikātu, kuram jūsu pārlūks atteiksies uzticēties.

Pati autorizācija parasti ir saistīta ar ierīces MAC adresi, dažreiz ar iznomāto IP, un tā dzīvo sesiju tabulā ar taimeri. Pieteikšanās izveido ierakstu. Ugunsmūra noteikums, kas laiž cauri jūsu datplūsmu, pastāv tikai tik ilgi, kamēr pastāv šis ieraksts, un tāpēc visa problēma atgriežas vēlāk, nekam nemainoties jūsu pusē.

Kāpēc VPN roku paspiešana mirst pirms sākuma

Katram protokolam ir savs transports, un ugunsmūris pirms autorizācijas katru salauž citādi. IKEv2 operētājsistēmās Windows un iOS iet pa UDP 500 un UDP 4500; izmešana šajos portos izpaužas kā 809 vai kā nosaukumu atrisināšanas tipa kļūme klientos, kas posmus ziņo atsevišķi. OpenVPN pa UDP 1194 paliek savienošanās stāvoklī, līdz beidzas tā taimauts. OpenVPN pa TCP 443 ir interesantais gadījums, jo portāls var pabeigt TCP roku paspiešanu un pēc tam atbildēt ar savu pāradresācijas lapu, tāpēc jūs redzat TLS kļūdu, nevis taimautu.

WireGuard parāda mehānismu visskaidrāk. Tas pēc dizaina ir tikai UDP, bez TCP rezerves, tāpēc ugunsmūris, kas izmet nezināmu UDP, transportu pilnībā noņem. Klients turpina sūtīt roku paspiešanas sākumus ar pieaugošu pauzi un ziņo par roku paspiešanu, kas nekad nebeidzas. Nekas šajā ziņojumā nemin Wi-Fi, un nekas tajā neliecina, ka jums vajadzētu atvērt pārlūku.

Platformas cenšas pamanīt stāvokli pirms jūsu VPN. Windows iegūst zināmu URL, lai izlemtu, vai rādīt pieteikšanās paziņojumu, Android pieprasa galapunktu, kam vajadzētu atbildēt 204 No Content, un Apple ierīces atver nelielu gūstekņu tīkla logu. Šīs pārbaudes darbojas, jo portāls atbild ar pāradresāciju, nevis gaidīto saturu. Tā pati uzvedība izskaidro, kā portāls var izskatīties pilnīgi vesels, kamēr jūsu tunelis ir miris: pārbaude un tunelis tiek vērtēti pēc dažādiem noteikumiem.

Ko sesijas beigšanās patiešām atiestata

Vietas beidz sesijas tādu iemeslu dēļ, kas nav saistīti ar jūsu VPN kontu: dīkstāves taimauts, maksimālais sesijas garums, jauna DHCP noma vai atkārtota pievienošanās citam piekļuves punktam. Kad taimeris nostrādā, ieraksts sesiju tabulā pazūd, un noteikumu kopa pirms autorizācijas atgriežas tieši tāda, kāda tā bija reģistrējoties.

Izveidots tunelis bieži izdzīvo pietiekami ilgi, lai izskatītos vesels. Dzīvības uzturēšanas ziņojumi turpina iet ārā, un tas, vai klients to pamana, ir atkarīgs no tā, kā tas apstrādā neatsaucīgu datplūsmu, tāpēc statusa gaisma var kādu laiku palikt zaļa pēc tam, kad ceļš ir pazudis. Tad tunelis krīt, un katrs atkārtotais savienojuma mēģinājums neizdodas tajos pašos bloķētajos portos.

Tajā brīdī klienta kļūda pasaka, kurā posmā jūs esat, ja to uzmanīgi izlasāt:

Viena detaļa maldina cilvēkus: kad sesija ir piesaistīta MAC adresei, pieteikšanās lapas pārlāde var nepalīdzēt. Jums ir jāatmet savienojums un jāpievienojas no jauna, lai portāls redzētu jaunu autorizācijas mēģinājumu, nevis beigušos.

Vispirms piesakieties, tad celiet tuneli

Darba secība ir: autorizējiet ierīci, pierādiet ceļu, palaidiet VPN, pierādiet tuneli un pēc tam atjaunojiet savu parasto bloķēšanu. Pēdējais solis ir svarīgs, jo pagaidu stāvoklis, kas jums nepieciešams, lai sasniegtu portālu, ir tieši tas stāvoklis, kuru avārijas slēdzis pastāv, lai novērstu.

Darbvirsmas klientam ar opciju bloķēt ārpus tuneļa ir jābūt pauzētam, lai ielādētos portāla lapa, un jutīgas programmas jātur aizvērtas šajā ārpus tuneļa logā; tas ir vienīgais intervāls, kad vietējā datplūsma iziet neaizsargāta. Pārvaldītai ierīcei, kas vienmēr ir ieslēgta, vajadzētu izmantot procedūru, ko publicējis tās īpašnieks, nevis jums noņemt politiku. Ja portāls rāda sertifikāta brīdinājumu, apstājieties: tā pieņemšana novirza jūsu sesiju caur vietas pārtveršanas starpniekserveri, un tas starpniekserveris var nolasīt visu, ko jūs sūtāt. Android ierīcē bloķēšana pie vienmēr aktīva VPN bloķē datplūsmu pirms tuneļa pacelšanas, un dažas būves nevar izslēgt portāla plūsmu; ja jūsējā nevar, izmantojiet vietas alternatīvo piekļuvi vai citu ierīci, nevis atstājiet bloķēšanu izslēgtu. Apple pēc pieprasījuma noteikumi var tikt rakstīti tā, lai atteiktu tuneli, līdz pārbaude izdodas, un tā ir uzvedība, ko vēlaties viesnīcu tīklos.

Pārbaudiet secīgi ar rīkiem, kas jums jau ir. Pirms tuneļa palaidiet pārbaudi ar redzamiem gan galvenēm, gan saturu, un vērojiet, vai jūsu VPN transports vispār saņem atbildi:

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'

Pirms autorizācijas parasts portāls dod vienu no divām atbildēm: 302, kura Location norāda uz pieteikšanās lapu, vai 200 ar HTML saturu, kas ir portāla lapa. Pierakstiet, kuru saņēmāt. Pāradresācija pirms pieteikšanās nav kļūme; portāls jums saka, kurp doties. Pēc tam, kad portāls ziņo par panākumiem, atkārtojiet komandu un gaidiet 200, kura saturs ir burtiski vārds Success. Tieši šī virkne padara pārbaudi jēgpilnu. Ja resursdators atbild normāli pirms jūs kādreiz pieteicāties, šajā tīklā nav pārtveršanas portāla. Ierakstā izmešana pirms autorizācijas ir izejoši paketi, no kuriem nekas neatgriežas, kamēr strādājošs ceļš parāda atbildi uz to pašu plūsmu apmēram sekundes laikā. Pieslēdzieties un pēc tam atkārtojiet ierakstu.

Ja tunelis joprojām neizdodas pēc tam, kad portāls saka jā

Pieteikšanās panākumi nav tas pats, kas atļauts transports. Daudzas vietas atļauj portālu un parasto pārlūkošanu, bet pilnībā bloķē UDP, kas atstāj WireGuard un UDP OpenVPN salauztus un TCP 443 strādājošu. Ja TCP 443 iziet un UDP ne, tā ir vietas politika, nevis jūsu nepareizi konfigurēts klients, tāpēc mainiet transportu vai pieņemiet ierobežojumu un dodieties tālāk. Ja atkārtots savienojums pēc tam joprojām neizdodas, saglabājiet precīzu kļūdu; tā nosauc posmu, kurā esat iestrēdzis.

Citas kļūmes dzīvo ierīcē. Sesija, kas joprojām piesaistīta vecai MAC, otrs Wi-Fi adapteris ar savu nomu vai klients, kas saglabājis portāla sertifikāta izņēmumu, katrs var turpināt neizdoties pēc tīras atkārtotas autorizācijas. Atmetiet savienojumu, autorizējiet vēlreiz un pamēģiniet vienreiz, pirms aiztiekat klienta iestatījumus. RFC 8952 ir vērts izlasīt, ja vēlaties arhitektūru aiz uzraudzītajām komponentēm.

Ja pats portāls atsakās autorizēt, problēma ir kontā vai ierīces sadalē, un neviens VPN iestatījums to nelabos. VPN izejas valsts maiņa neatiestata vietas vietējo piekļuves stāvokli; šī tabula ir piesaistīta jūsu ierīcei, nevis izvēlētajam serverim. Jautājiet vietas operatoram un dodiet viņam laiku, jo sesiju tabula ir tas, ko viņš skatīsies.

Pirms nākamā ceļojuma pierakstiet trīs lietas: portāla lapu kā nullto soli, bloķēšanas apturēšanas soli katrai līdzi ņemtajai ierīcei un vienu rezerves transportu, kuru esat tiešām pārbaudījis. Kad tunelis, kas darbojās pirms desmit minūtēm, atkal apstājas, uztveriet to kā beigušos autorizāciju un vēlreiz pārbaudiet portālu, pirms aiztiekat VPN profilu.