Offentlig Wi-Fi og VPN: det tunnelen ikke dekker

Grønt merke, fornøyd portal, fungerende nettleser: det er hele den synlige historien. Det merket utelater, er at den krypterte forbindelsen bæres av nettopp den trådløse koblingen den skal beskytte deg mot. Den koblingen leverer fortsatt hver pakke, ser fortsatt måladataressen og avgjør fortsatt om noe i det hele tatt kommer frem. Å gå gjennom laptop-siden av en hotellforbindelse viser hvilke deler tunnelen dekker, og hvilke den overlater til deg.

Tilgangskoblingen bærer alt

En IPsec ESP-tunnel pakker en beskyttet indre pakke inn i et ytre hode som nettverket kan rute, og RFC 4303 avsnitt 3.1.2 forklarer den delingen. Den indre pakken er det tunnelen beskytter. Det ytre hodet er det hotspoten leser for å videresende den. Andre design kapsler inn annerledes, men planleggingsspørsmålet er identisk: hvilken tilgangsvei bærer denne forbindelsen?

En gateway-feil eller en kobling som slipper pakker stopper levering uten å avsløre innhold. Å bytte til en sterkere chiffre hjelper ikke, fordi den manglende delen er transport, ikke kryptografi. Vellykket levering beviser like lite i den andre retningen, siden en fungerende vei ikke sier noe om tilstanden til noen av de to maskinene.

Laptopen din har fortsatt sine egne dører

Å koble seg til et ikke-klarert segment endrer hvem som kan nå portene maskinen din lytter på. En fildelingstjeneste, en fjernadministrasjonsagent eller en utviklingsserver bundet til alle grensesnitt er tilgjengelig for alle i det segmentet med mindre noe stopper den. Trafikk som aldri går inn i tunnelen, er ikke beskyttet av den. En lytter som svarer før tunnelen er oppe, er eksponert nøyaktig i det vinduet.

Kravet er smalt og verdt å formulere presist: laptopen må nå VPN-endepunktet, og uvedkommende enheter på hotspoten må ikke nå lokale tjenester. Vertsbrannmurens regler uttrykker den grensen, og plattformens egne delingsinnstillinger uttrykker også en del av den. En skriver eller et portaltiltak er et avgrenset unntak du legger til med vilje, ikke bevis for at hele hotspoten fortjener tillit som kontor-LAN.

Noen organisasjoner begrenser også lokal tilgang mens en arbeidsforbindelse er aktiv, og det er policy, ikke ingeniørfag. Les den policyen før du deaktiverer en brannmur for å få en enhet til å virke.

Kontroller hva som faktisk lytter

Se på socketene og ikke innstillingssiden, fordi siden beskriver intensjonen og socket-tabellen beskriver maskinen. De to listene nedenfor skiller hver lyttende socket fra dem en nabo kunne nå. Kjør dem i det ikke-klarerte segmentet før du kobler til tunnelen.

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

Den første kommandoen viser hver socket, og den andre filtrerer til dem som er bundet utover loopback. En tjeneste på 0.0.0.0 eller :: er tilgjengelig på hvert grensesnitt, inkludert det trådløse, mens den samme tjenesten på 127.0.0.1 ikke kan nås fra segmentet i det hele tatt. Resolver-spørringen bekrefter hvilken vei navnet tar før tunnelen finnes, og det er der captive-portaler forstyrrer. Gjenta listen etter tilkobling, fordi noen klienter reiser grensesnitt som endrer svaret.

En port som bare vises mens tunnelen er oppe, er mindre eksponert, selv om det fortsatt er verdt å vite om den. Noter forskjellen og ikke den absolutte listen, fordi deltaet er det tunnelen la til.

Ikke godta en ny identitet midt i økten

En uventet ruteendring, en gjentilkobling eller en portalviderekobling er ikke tillatelse til å godta en annen serveridentitet. Hvis klienten rapporterer avvik i sertifikat eller nøkkel, skal du behandle det som et identitetsfunn og ikke som en tilkobling som skal omgås. Å installere et uforklart rotsertifikat for å få en portal til å virke gjør et leveringsproblem til et tillitsproblem. Tillitsproblemet overlever deretter reisen som skapte det.

Bruk portalens egen nettleserflyt, koble deretter til tunnelen på nytt og les klientloggen for identiteten den verifiserte. Identitetsfeil betyr at motparten ikke er den du forventet, mens leveringsfeil betyr at motparten aldri svarte. Det første er grunn til å stoppe, og det andre er grunn til å prøve en annen vei.

Bestem oppførselen ved avbrudd først

Her forveksles to forskjellige funksjoner. Gjentilkobling forsøker å gjenopprette tjenesten, mens en blokkeringspolicy styrer hvilken trafikk som er tillatt mens tunnelen er nede. Ingen av dem gir en fungerende trådløs kobling, og ingen av dem beviser at endepunktet er rent. Velg eksplisitt: lukket feil for applikasjoner som aldri må bruke den lokale veien, og tillat vanlig surfing utenfor tunnelen hvis det er akseptabelt.

Skriv ned valget, fordi standarden i de fleste klienter ikke er noen av dem, og den varierer etter versjon. Sørg deretter for en alternativ tilgangsvei hvis tilgjengelighet betyr noe, for eksempel et telefonhotspot med egen dataplan. En akseptabel akseptansetest har tre separate utfall: tiltenkt trafikk bruker den verifiserte tunnelen, uvedkommende lokale lyttere er utilgjengelige, og et avbrudd gir oppførselen du valgte.