Offentligt Wi-Fi og VPN: hvad tunnelen ikke dækker

Grønt badge, tilfreds portal, fungerende browser: det er hele den synlige historie. Det, badge'et udelader, er, at den krypterede forbindelse bæres af netop det trådløse link, den skal beskytte dig imod. Det link leverer stadig hver pakke, ser stadig endepunktsadressen og beslutter stadig, om noget overhovedet ankommer. At gå laptop-siden af en hotelforbindelse igennem viser, hvilke dele tunnelen dækker, og hvilke den overlader til dig.

Adgangsvejen bærer alt

En IPsec ESP-tunnel pakker en beskyttet indre pakke ind i en ydre header, som netværket kan route, og RFC 4303 afsnit 3.1.2 beskriver den opdeling. Den indre pakke er det, tunnelen beskytter. Den ydre header er det, hotspot'et læser for at videresende den. Andre design indkapsler anderledes, men planlægningsspørgsmålet er identisk: hvilken adgangsvej bærer denne forbindelse?

En gateway-fejl eller et link, der taber pakker, stopper levering uden at afsløre indhold. At skifte til en stærkere cipher hjælper ikke, fordi det manglende stykke er transport, ikke kryptografi. Vellykket levering beviser lige så lidt i den anden retning, fordi en fungerende vej intet siger om tilstanden af nogen af de to maskiner.

Din laptop har stadig sine egne døre

At tilslutte sig et utroværdigt segment ændrer, hvem der kan nå de porte, din maskine lytter på. En fildelingstjeneste, en fjernadministrationsagent eller en udviklingsserver bundet til alle grænseflader kan nås af enhver på det segment, medmindre noget stopper det. Trafik, der aldrig går ind i tunnelen, beskyttes ikke af den. En lytter, der svarer, før tunnelen er oppe, er udsat præcis i det vindue.

Kravet er snævert og værd at formulere præcist: laptoppen skal nå VPN-endepunktet, og uvedkommende enheder på hotspot'et må ikke nå lokale tjenester. Værtens firewallregler udtrykker den grænse, og platformens egne delingsindstillinger udtrykker en del af den også. En printer eller et portaltrit er en afgrænset undtagelse, du tilføjer bevidst, ikke bevis for, at hele hotspot'et fortjener tillid som kontor-LAN.

Nogle organisationer begrænser også lokal adgang, mens en arbejdsforbindelse er aktiv, hvilket er politik og ikke teknik. Læs den politik, før du deaktiverer en firewall for at få en enhed til at virke.

Kontroller, hvad der faktisk lytter

Se på sockets i stedet for indstillingssiden, fordi siden beskriver hensigten, og socket-tabellen beskriver maskinen. De to lister nedenfor adskiller hver lyttende socket fra dem, en nabo kunne nå. Kør dem på det utroværdige segment, før du tilslutter tunnelen.

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

Den første kommando viser hver socket, og den anden filtrerer til dem, der er bundet ud over loopback. En tjeneste på 0.0.0.0 eller :: er tilgængelig på hver grænseflade, inklusive den trådløse, mens den samme tjeneste på 127.0.0.1 slet ikke kan nås fra segmentet. Resolver-forespørgslen bekræfter, hvilken vej navnet tager, før tunnelen findes, og det er her, tvangsportaler forstyrrer. Gentag listen efter tilslutning, fordi nogle klienter rejser grænseflader, der ændrer svaret.

En port, der kun vises, mens tunnelen er oppe, er mindre udsat, selv om det stadig er værd at vide. Notér forskellen frem for den absolutte liste, fordi deltaet er det, tunnelen tilføjede.

Accepter ikke en ny identitet midt i sessionen

En uventet ruteændring, en genopkobling eller en portalvidereføring er ikke tilladelse til at acceptere en anden serveridentitet. Hvis klienten rapporterer uoverensstemmelse i certifikat eller nøgle, skal du behandle det som en identitetsfund, ikke som en forbindelse, der skal omgås. At installere et uforklaret rodcertifikat for at få en portal til at virke gør et leveringsproblem til et tillidsproblem. Tillidsproblemet overlever derefter den rejse, der skabte det.

Brug portalens egen browsergang, genopkobl derefter tunnelen og læs klientloggen for den identitet, den verificerede. Identitetsfejl betyder, at modparten ikke er den, du forventede, mens leveringsfejl betyder, at modparten aldrig svarede. Det første er en grund til at stoppe, og det andet er en grund til at prøve en anden vej.

Beslut adfærden ved afbrud først

To forskellige funktioner forveksles her. Genopkobling forsøger at genskabe tjenesten, mens en blokeringspolitik styrer, hvilken trafik der er tilladt, mens tunnelen er nede. Ingen af dem leverer et fungerende trådløst link, og ingen af dem beviser, at endepunktet er rent. Vælg eksplicit: lukket fejl for programmer, der aldrig må bruge den lokale vej, og tillad almindelig browsing uden for tunnelen, hvis det er acceptabelt.

Skriv valget ned, fordi standarden i de fleste klienter er ingen af dem, og den varierer efter version. Sørg derefter for en alternativ adgangsvej, hvis tilgængelighed betyder noget, såsom et telefonhotspot med egen dataplan. En acceptabel accepttest har tre separate udfald: tilsigtet trafik bruger den verificerede tunnel, uvedkommende lokale lyttere er utilgængelige, og et afbrud giver den adfærd, du valgte.