Openbaar Wi-Fi en een VPN: wat de tunnel niet dekt
De tunnel beschermt één pad door een netwerk dat u niet beheert. Loop de verbinding, de lokale luisteraars en het gedrag bij uitval na dat de badge nooit toont.
Groene badge, tevreden portaal, werkende browser: dat is het hele zichtbare verhaal. Wat de badge weglaat, is dat de versleutelde verbinding wordt gedragen door precies de draadloze verbinding waartegen zij u moet beschermen. Die verbinding levert nog steeds elk pakket, ziet nog steeds het eindpuntadres en beslist nog steeds of er überhaupt iets aankomt. De laptopkant van een hotelverbinding doorlopen laat zien welke delen de tunnel dekt en welke hij aan u overlaat.
De toegangsverbinding draagt alles
Een IPsec ESP-tunnel verpakt een beschermd binnenste pakket in een buitenste header die het netwerk kan routeren, en RFC 4303 sectie 3.1.2 legt die splitsing uit. Het binnenste pakket is wat de tunnel beschermt. De buitenste header is wat de hotspot leest om het door te sturen. Andere ontwerpen inkapselen anders, maar de planningsvraag is identiek: welk toegangspad draagt deze verbinding?
Een gateway-storing of een verbinding die pakketten laat vallen, stopt de aflevering zonder inhoud te onthullen. Overstappen op een sterker cijfer helpt daar niet tegen, omdat het ontbrekende stuk transport is en niet cryptografie. Een geslaagde aflevering bewijst in de andere richting even weinig, want een werkend pad zegt niets over de toestand van geen van beide machines.
Uw laptop heeft nog altijd zijn eigen deuren
Deelnemen aan een onbetrouwbaar segment verandert wie de poorten kan bereiken waarop uw machine luistert. Een bestandsdelingsdienst, een agent voor beheer op afstand of een ontwikkelserver die aan alle interfaces is gebonden, is bereikbaar voor iedereen in dat segment tenzij iets hem tegenhoudt. Verkeer dat nooit de tunnel in gaat, wordt er niet door beschermd. Een luisteraar die antwoordt voordat de tunnel staat, is precies voor dat venster blootgesteld.
De eis is smal en verdient een precieze formulering: de laptop moet het VPN-eindpunt bereiken, en ongerelateerde apparaten op de hotspot mogen geen lokale diensten bereiken. Firewallregels op de host drukken die grens uit, en de eigen deelinstellingen van het platform drukken er ook een deel van uit. Een printer of een portalstap is een begrensde uitzondering die u bewust toevoegt, geen bewijs dat de hele hotspot het vertrouwen van een kantoornetwerk verdient.
Sommige organisaties beperken ook lokale toegang zolang een werkverbinding actief is, en dat is beleid, geen techniek. Lees dat beleid voordat u een firewall uitschakelt om een randapparaat te laten werken.
Controleer wat er werkelijk luistert
Kijk naar de sockets in plaats van de instellingenpagina, want de pagina beschrijft de bedoeling en de sockettabel beschrijft de machine. De twee lijsten hieronder scheiden elke luisterende socket van die een buurman zou kunnen bereiken. Voer ze uit op het onbetrouwbare segment voordat u de tunnel verbindt.
ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net
De eerste opdracht toont elke socket, en de tweede filtert naar die buiten loopback zijn gebonden. Een dienst op 0.0.0.0 of :: is beschikbaar op elke interface, inclusief de draadloze, terwijl dezelfde dienst op 127.0.0.1 helemaal niet vanaf het segment bereikbaar is. De resolver-query bevestigt welk pad de naam neemt voordat de tunnel bestaat, en daar storen captive portals. Herhaal de lijst na het verbinden, omdat sommige clients interfaces opzetten die het antwoord veranderen.
Een poort die alleen verschijnt terwijl de tunnel staat, is minder blootgesteld, al is het nog steeds de moeite waard om ervan te weten. Noteer het verschil en niet de absolute lijst, want de delta is wat de tunnel heeft toegevoegd.
Accepteer geen nieuwe identiteit midden in de sessie
Een onverwachte routewijziging, een herverbinding of een portaalomleiding is geen toestemming om een andere serveridentiteit te accepteren. Als de client een certificaat- of sleutelafwijking meldt, behandel dat als een identiteitsbevinding en niet als connectiviteit die omzeild moet worden. Een onverklaard rootcertificaat installeren om een portaal te laten werken, maakt een afleveringsprobleem tot een vertrouwensprobleem. Het vertrouwensprobleem overleeft daarna de reis die het heeft gecreëerd.
Gebruik de eigen browserflow van het portaal, verbind daarna de tunnel opnieuw en lees in het clientlog welke identiteit hij heeft geverifieerd. Identiteitsfout betekent dat de tegenpartij niet is wie u verwachtte, terwijl afleveringsfout betekent dat de tegenpartij nooit heeft geantwoord. Het eerste is een reden om te stoppen, het tweede een reden om een ander pad te proberen.
Bepaal eerst het gedrag bij uitval
Hier worden twee verschillende functies verward. Herverbinden probeert de dienst te herstellen, terwijl een blokkeringsbeleid bepaalt welk verkeer is toegestaan terwijl de tunnel neerligt. Geen van beide levert een werkende draadloze verbinding, en geen van beide bewijst dat het eindpunt schoon is. Kies uitdrukkelijk: gesloten falen voor toepassingen die nooit het lokale pad mogen gebruiken, en sta gewoon browsen buiten de tunnel toe als dat aanvaardbaar is.
Schrijf de keuze op, want de standaard in de meeste clients is geen van beide, en die verschilt per versie. Regel daarna een alternatief toegangspad als beschikbaarheid telt, zoals een telefoonhotspot met een eigen databundel. Een aanvaardbare acceptatietest heeft drie afzonderlijke uitkomsten: bedoeld verkeer gebruikt de geverifieerde tunnel, ongerelateerde lokale luisteraars zijn onbereikbaar, en een uitval levert het gedrag op dat u hebt gekozen.