Öppet Wi-Fi och VPN: vad tunneln inte täcker

Grönt märke, nöjd portal, fungerande webbläsare: det är hela den synliga historien. Det märket utelämnar är att den krypterade anslutningen bärs av just den trådlösa länken som den ska skydda dig mot. Den länken levererar fortfarande varje paket, ser fortfarande måladdressen och avgör fortfarande om något alls kommer fram. Att gå igenom laptopsidan av en hotellanslutning visar vilka delar tunneln täcker och vilka den lämnar till dig.

Åtkomstlänken bär allt

En IPsec ESP-tunnel packar ett skyddat inre paket i ett yttre huvud som nätverket kan routa, och RFC 4303 avsnitt 3.1.2 förklarar den uppdelningen. Det inre paketet är det tunneln skyddar. Det yttre huvudet är det hotspoten läser för att vidarebefordra det. Andra konstruktioner kapslar in annorlunda, men planeringsfrågan är identisk: vilken åtkomstväg bär den här anslutningen?

Ett gatewayfel eller en länk som tappar paket stoppar leveransen utan att avslöja innehåll. Att byta till en starkare chiffer hjälper inte mot det, eftersom den saknade delen är transport och inte kryptografi. Lyckad leverans bevisar lika lite i andra riktningen, eftersom en fungerande väg inte säger något om tillståndet hos någon av de två maskinerna.

Din laptop har fortfarande sina egna dörrar

Att ansluta till ett ej betrott segment ändrar vem som kan nå portarna din maskin lyssnar på. En fildelningstjänst, en fjärradministrationsagent eller en utvecklingsserver bunden till alla gränssnitt är nåbar för alla i det segmentet om inget stoppar den. Trafik som aldrig går in i tunneln skyddas inte av den. En lyssnare som svarar innan tunneln är uppe är exponerad exakt under det fönstret.

Kravet är smalt och värt att formuleras exakt: laptopen måste nå VPN-slutpunkten, och orelaterade enheter på hotspoten får inte nå lokala tjänster. Värdbrandväggens regler uttrycker den gränsen, och plattformens egna delningsinställningar uttrycker också en del av den. En skrivare eller ett portalsteg är ett avgränsat undantag du lägger till medvetet, inte bevis för att hela hotspoten förtjänar förtroende som kontors-LAN.

Vissa organisationer begränsar också lokal åtkomst medan en arbetsanslutning är aktiv, och det är policy, inte ingenjörskonst. Läs den policyn innan du inaktiverar en brandvägg för att få en kringutrustning att fungera.

Kontrollera vad som faktiskt lyssnar

Titta på socketarna och inte på inställningssidan, eftersom sidan beskriver avsikten och sockettabellen beskriver maskinen. De två listorna nedan skiljer varje lyssnande socket från dem en granne skulle kunna nå. Kör dem i det ej betrodda segmentet innan du ansluter tunneln.

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

Det första kommandot visar varje socket, och det andra filtrerar till dem som är bundna utanför loopback. En tjänst på 0.0.0.0 eller :: är tillgänglig på varje gränssnitt, inklusive det trådlösa, medan samma tjänst på 127.0.0.1 inte alls går att nå från segmentet. Resolverfrågan bekräftar vilken väg namnet tar innan tunneln finns, och det är där captive-portaler stör. Upprepa listan efter anslutning, eftersom vissa klienter reser gränssnitt som ändrar svaret.

En port som bara dyker upp medan tunneln är uppe är mindre exponerad, även om det fortfarande är värt att känna till den. Notera skillnaden och inte den absoluta listan, eftersom deltat är det tunneln lade till.

Acceptera inte en ny identitet mitt i sessionen

En oväntad ruttändring, en återanslutning eller en portalomdirigering är inte tillstånd att acceptera en annan serveridentitet. Om klienten rapporterar avvikelse i certifikat eller nyckel ska du behandla det som ett identitetsfynd och inte som en anslutning som ska kringgås. Att installera ett oförklarat rotcertifikat för att få en portal att fungera gör ett leveransproblem till ett tillitsproblem. Tillitsproblemet överlever sedan resan som skapade det.

Använd portalens egen webbläsarflöde, anslut sedan tunneln igen och läs i klientloggen vilken identitet den verifierade. Identitetsfel betyder att motparten inte är den du förväntade dig, medan leveransfel betyder att motparten aldrig svarade. Det första är skäl att stoppa, och det andra är skäl att prova en annan väg.

Bestäm beteendet vid avbrott först

Här blandas två olika funktioner ihop. Återanslutning försöker återställa tjänsten, medan en blockeringspolicy styr vilken trafik som tillåts medan tunneln är nere. Ingen av dem ger en fungerande trådlös länk, och ingen av dem bevisar att slutpunkten är ren. Välj uttryckligen: stängt fel för program som aldrig får använda den lokala vägen, och tillåt vanlig surfning utanför tunneln om det är acceptabelt.

Skriv ner valet, eftersom standarden i de flesta klienter inte är någon av dem, och den varierar med versionen. Ordna sedan en alternativ åtkomstväg om tillgänglighet spelar roll, till exempel en telefonhotspot med egen dataplan. Ett godtagbart acceptanstest har tre separata utfall: avsedd trafik använder den verifierade tunneln, orelaterade lokala lyssnare är onåbara, och ett avbrott ger det beteende du valde.