Publika Wi-Fi kaj VPN: kion la tunelo ne kovras

Verda insigno, kontenta portalo, funkcianta retesplorilo: tio estas la tuta videbla historio. Kion la insigno preterlasas estas, ke la ĉifritan konekton portas ĝuste tiu sendrata ligo, de kiu ĝi devus vin protekti. Tiu ligo ankoraŭ liveras ĉiun pakaĵon, ankoraŭ vidas la finan adreson kaj ankoraŭ decidas, ĉu io ajn alvenos. Trapaŝi la tekokomputilan flankon de hotelkonekto montras, kiujn partojn la tunelo kovras kaj kiujn ĝi lasas al vi.

La alira ligo portas ĉion

IPsec ESP-tunelo volvas protektitan internan pakaĵon en eksteran kaplinion, kiun la reto povas enkursigi, kaj RFC 4303 sekcio 3.1.2 klarigas tiun dividon. La interna pakaĵo estas tio, kion la tunelo protektas. La ekstera kaplinio estas tio, kion la hotspot legas por plusendi ĝin. Aliaj dezajnoj enkapsuligas alie, sed la plana demando estas identa: kiu alira vojo portas ĉi tiun konekton?

Pordo-malsukceso aŭ ligo, kiu faligas pakaĵojn, haltigas liveron sen malkaŝi enhavon. Ŝanĝi al pli forta ĉifro faras nenion por tio, ĉar la mankanta peco estas transporto, ne kriptografio. Sukcesa livero same malmulte pruvas en la alia direkto, ĉar funkcianta vojo diras nenion pri la stato de iu ajn el la du maŝinoj.

Via tekokomputilo ankoraŭ havas siajn proprajn pordojn

Aliĝi al nefidinda segmento ŝanĝas, kiu povas atingi la havenojn, sur kiuj via maŝino aŭskultas. Dosierkunhava servo, fora administra agento aŭ evoluiga servilo ligita al ĉiuj interfacoj estas atingebla de iu ajn en tiu segmento, krom se io haltigas ĝin. Trafiko, kiu neniam eniras la tunelon, ne estas protektita de ĝi. Aŭskultanto, kiu respondas antaŭ ol la tunelo supreniras, estas elmetita ĝuste por tiu fenestro.

La postulo estas mallarĝa kaj indas esti dirita precize: la tekokomputilo devas atingi la VPN-finpunkton, kaj nerilataj aparatoj en la hotspot ne devas atingi lokajn servojn. Reguloj de gastiga fajroŝirmilo esprimas tiun limon, kaj la propraj kunhavigaj agordoj de la platformo ankaŭ esprimas parton de ĝi. Printilo aŭ portala paŝo estas limigita escepto, kiun vi aldonas intence, ne pruvo, ke la tuta hotspot meritas fidon de oficeja LAN.

Kelkaj organizoj ankaŭ limigas lokan aliron dum laborkonekto estas aktiva, kio estas politiko, ne inĝenierado. Legu tiun politikon antaŭ ol malŝalti fajroŝirmilon por funkciigi periferian aparaton.

Kontrolu, kio efektive aŭskultas

Rigardu la ingojn anstataŭ la agordan paĝon, ĉar la paĝo priskribas intencon kaj la inga tabelo priskribas la maŝinon. La du listoj sube apartigas ĉiun aŭskultantan ingon de tiuj, kiujn najbaro povus atingi. Rulu ilin en la nefidinda segmento antaŭ ol konekti la tunelon.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

La unua komando montras ĉiun ingon, kaj la dua filtros al tiuj ligitaj preter loopback. Servo sur 0.0.0.0 aŭ :: estas havebla sur ĉiu interfaco, inkluzive de la sendrata, dum la sama servo sur 127.0.0.1 tute ne atingeblas de la segmento. La peto al la solvilo konfirmas, kiun vojon la nomo prenas antaŭ ol ekzistas la tunelo, kaj ĝuste tie kaptitaj portaloj intervenas. Ripetu la liston post konekto, ĉar kelkaj klientoj levas interfacojn, kiuj ŝanĝas la respondon.

Haveno, kiu aperas nur dum la tunelo estas supren, estas malpli elmetita, kvankam indas scii pri ĝi. Notu la diferencon anstataŭ la absolutan liston, ĉar la delto estas tio, kion la tunelo aldonis.

Ne akceptu novan identecon meze de la seanco

Neatendita voja ŝanĝo, rekonekto aŭ portalalidirektado ne estas permeso akcepti alian servilan identecon. Se la kliento raportas neakordan atestilon aŭ ŝlosilon, traktu ĝin kiel trovaĵon pri identeco, ne kiel konektecon preterireblan. Instali neklarigitan radikan atestilon por funkciigi portalon transformas liveran problemon en fidan problemon. La fida problemo poste postvivas la vojaĝon, kiu ĝin kreis.

Uzu la propran retesplorilan fluon de la portalo, poste rekonektu la tunelon kaj legu la klientan protokolon por la identeco, kiun ĝi kontrolis. Identeca malsukceso signifas, ke la kunulo ne estas tiu, kiun vi atendis, dum livera malsukceso signifas, ke la kunulo neniam respondis. La unua estas kaŭzo halti, kaj la dua estas kaŭzo provi alian vojon.

Unue decidu la konduton ĉe interrompo

Ĉi tie du malsamaj funkcioj konfuziĝas. Rekonekto provas restarigi servon, dum bloka politiko regas, kiu trafiko estas permesita dum la tunelo estas sube. Nek provizas funkciantan sendratan ligon, nek pruvas, ke la finpunkto estas pura. Elektu eksplicite: fermita malsukceso por aplikaĵoj, kiuj neniam rajtas uzi la lokan vojon, kaj permesu ordinaran retesploradon ekster la tunelo, se tio estas akceptebla.

Skribu la elekton, ĉar la defaŭlto en la plej multaj klientoj estas nek unu nek la alia, kaj ĝi varias laŭ versio. Poste aranĝu alternativan aliran vojon, se havebleco gravas, kiel telefona hotspot kun propra datuma plano. Akceptebla akcepta testo havas tri apartajn rezultojn: celita trafiko uzas la kontrolitan tunelon, nerilataj lokaj aŭskultantoj estas neatingeblaj, kaj interrompo produktas la konduton, kiun vi elektis.