Du malsamaj sistemoj petas vin ensaluti antaŭ ol vi atingos ion utilan en publika reto: la Wi-Fi de la loko kaj via VPN-enirejo. Ili aspektas same sur la ekrano kaj rajtigas tute malsamajn aferojn. La portalo decidas, ĉu ĉi tiu aparato rajtas uzi la lokan reton; la VPN decidas, ĉu vi rajtas atingi privatan reton aliloke. Mi tenas ilin apartaj demandante ĉe ĉiu fenestro unu demandon: kiu povas vere kontroli tiun sekreton? Tio, kio sekvas, estas la kontrolo-listo, kiun mi uzas en hoteloj, flughavenoj kaj konferencejoj, inkluzive la punktojn, kie mi ĉesas tajpi.

Mapu ĉiun ensaluton al la servo, kiu kontrolas ĝin

Unu hotela konekto povas enhavi kvar apartajn kontrolojn, kaj nur kelkaj volas vian enigon. Metu ilin unue en ordon, ĉar la ekrano malofte diras, al kiu stadio ĝi apartenas.

StageWho checks itWhat you give itWhat it proves
Wi-Fi associationThe access pointWPA2 passphrase or 802.1X credentialsThat the device may join this SSID
Portal authorizationThe venue or its portal providerRoom number, booking name, voucher, email or access codeThat a guest may use local access
VPN authenticationYour gateway or identity providerClient certificate, password, one-time code or SSO approvalThat the user or device may enter the private network
Application loginEach internal serviceThat service's own accountThat you may use that service

802.1X-retoj, oftaj en oficejoj kaj universitatoj, malklarigas la unuajn du vicojn. Tie la Wi-Fi-ensaluto mem estas identokontrolo kontraŭ RADIUS-servilo, kaj la kliento povas prezenti enkursigan identecon dum la efektiva konto vojaĝas ene de la ĉifrita interŝanĝo. Eĉ tiam la kontrolo temas pri aliĝo al la reto; ĝi ne rajtigas la tunelon, kaj la VPN-enirejo ne akceptas ĝin kiel pruvon pri io ajn.

La ordo pli gravas ol la etikedoj. Kaptitaj portaloj ekzistas ĉar aliro povas esti donita post aliĝo, kaj tial loko povas transdoni la paĝon al specialigita provizanto. RFC 8952 de IETF traktas la portalon kiel propran komponenton, do nekonata domajno estas kialo kontroli, ne pruvo de fraŭdo per si mem. Kontrolu la domajnon laŭ la skribaj instrukcioj de la loko, kaj la kampojn laŭ la tabelo.

Kontrolu, pri kio portalo rajtas demandi

Portalaj kampoj temas pri rajtigo, ne pri identeco: ĉambra numero, familia nomo de la rezervo, kupona kodo, la kodo presita sur la ŝlosila ingo, retadreso por temp-limigita permesilo, akcepto de kondiĉoj. La loko jam scias, kiu rezervis la ĉambron, do ĝi povas kongruigi tiujn faktojn sen lerni ion, kio ebligus ĝin agi kiel vi aliloke.

Io ajn preter tiu listo meritas paŭzon. Retpaĝo de kaptilo ne povas kontroli vian domajnan pasvorton, kaj ĝi ankaŭ ne povas kontroli vian unufojan kodon por la VPN, restarigan kodon aŭ privatan ŝlosilon, kaj ĝi havas neniun kialon voli ilin. La sola laŭleĝa escepto estas reto administrata de organizo: gastiga SSID en oficejo aŭ konferenca Wi-Fi povas transdoni vin al la identprovizanto, kiun vi jam uzas por laboro. Ĝi restas distingebla: la ensaluta gastiganto estas via ĉiutaga, la konsenta ekrano nomas vian luanton, kaj la fluo malfermiĝas en videbla folio de la retumilo.

Retpoŝto pri merkatado estas aparta: vojaĝa alinomo kontentigas la kampon sen transdoni vian laboran identecon.

Kontrolu, ĉu la VPN-kliento volas siajn proprajn akreditaĵojn

La kliento petas ĝuste tion, por kio ĝia profilo estas agordita, do la atendata fenestro estas eco de la profilo, ne de la reto, en kiu vi hazarde troviĝas. Certifikaj profiloj kutime montras elekton de profilo kaj poste konektiĝas silente. Profiloj de uzantnomo kaj pasvorto petas ambaŭ, ofte kun unufoja kodo. SSO-profiloj malfermas vian retumilon al la identprovizanto kaj revenas kun ĵetono. WireGuard estas denove malsama: ĝi aŭtentigas aparatojn per publika ŝlosilo kaj havas neniun uzantan ensaluton, do fenestro ofertanta WireGuard-uzantnomon kaj -pasvorton ne priskribas WireGuard.

Legi la profilon antaŭ ol vojaĝi. En OpenVPN auth-user-pass diras al vi, ke pasvorta peto estas atendata, dum cert, key aŭ pkcs12 signifas, ke atestilo devas fari la laboron. Se profilo, kiu kutime konektiĝas sen peto, subite petas pasvorton, suspektu profilon, kiu malsukcesis ŝargi sian atestilon aŭ falis al alia metodo. Peto ne estas invito tajpi vian laboran pasvorton en iun ajn fenestron, kiu aperis.

Neniu laŭleĝa VPN-kliento petas la ĉambran numeron, la portal-kuponon aŭ la Wi-Fi-pasfrazon kiel aŭtentigan enigon. Kiam tio okazas, aŭ la kliento ne estas tio, kion ĝi pretendas, aŭ kaptita portalo interkaptas trafikon antaŭ ol la tunelo formiĝas kaj vi legas HTML-paĝon stilizitan kiel ensaluto.

Haltu ĉe ĉi tiuj kvin kondiĉoj

Tiuj estas la punktoj, kie mi haltas anstataŭ daŭrigi per kredinda ĉirkaŭvojo. Ĉiu estas malmultekosta kontroli kaj multekosta erari.

  1. Atestila aŭ TLS-averto aperas ĉe la portalo aŭ ĉe la SSO-paĝo. Ne klaku preter ĝi por atingi la reton.
  2. La paĝo petas sekreton, kiun nur la VPN-enirejo aŭ la identprovizanto povas kontroli: domajna pasvorto, unufoja kodo, restariga kodo, privata ŝlosilo.
  3. La domajno ne kongruas kun la presitaj instrukcioj de la loko aŭ kun la ensaluta gastiganto, kiun via organizo dokumentas por siaj propraj servoj.
  4. Oni petas vin instali radikan atestilon, agordan profilon aŭ helpan aplikaĵon, kiu ne venas el via aparat-administrado.
  5. Alvenas MFA-approbo, kiun vi ne komencis, aŭ la VPN-kliento petas hotelajn akreditaĵojn.

La rezerva vojo ne estas alia pasvorto. Uzu poŝtelefonan kaptilon, demandu la akceptejon pri la preciza retnomo kaj alirmetodo, kaj raportu la paĝon al tiu, kiu administras la reton, aŭ al via IT-servo. Nenio el tio postulas testi akreditaĵon kontraŭ paĝo, kiun vi ne povas atribui.

Atribuu fiaskon al la ĝusta stadio

Post kiam ambaŭ stadioj pasis, fiaskoj ankoraŭ okazas, kaj la eraro kutime nomas la stadion, se vi legas ĝin laŭorde: aliĝo, adresdono, portal-rajtigo, tunela starigo, poste la interna risurbo. Ŝanĝi VPN-pasvorton ĉar portal-kodo eksvalidiĝis perdas tempon kaj lasas la veran problemon surloke.

Kelkaj provoj apartigas la stadiojn. Post portal-ensaluto, petu ordinaran publikan HTTPS-paĝon. Se la portalo revenas anstataŭe, rajtigo neniam kompletiĝis en tiu tavolo. Se la VPN-kliento raportas, ke ĝi ne povas atingi la enirejon, la problemo sidas sub la tunelo: la portal-sesio, nomresolvo aŭ reto, kiu blokas la pordon. Se la tunelo leviĝas kaj unu interna gastigantnomo fiaskas, nomresolvo aŭ politiko ene de la privata reto estas la pli bona suspektato.

Portal-sesioj ankaŭ eksvalidiĝas sendepende de la tunelo. Kiam la loko revokas aliron, starigita VPN-konekto falas kvankam ĝiaj akreditaĵoj neniam malĝustis. Rajtigu la portalon denove, poste rekonektu la VPN kaj lasu ĝin denove intertrakti. Rotacii la VPN-pasvorton tiam riparas nenion kaj povas ŝlosi vin ekstere.

Donu ĉiun sekreton nur al la sistemo, kiu povas ĝin kontroli, kaj traktu peton, kiu ne kongruas kun la tabelo, kiel haltsignon anstataŭ paŝon por ĉirkaŭiri. Se ambaŭ stadioj pasas kaj la tunelo ankoraŭ rifuzas, kaptu la precizan klient-eraron antaŭ ol ŝanĝi iun ajn akreditaĵon.

Rilataj artikoloj