Vem kan se din trafik på en hyrd VPN-server?

Att hyra en server ändrar vem du litar på och tar inte bort frågan. Tunneln döljer din trafik för näten den korsar och lämnar sedan klartexten till en maskin som någon annans hypervisor kör. Att följa paketet utåt från din klient visar var varje observatör står och vad var och en av dem faktiskt kan se. Den genomgången är mer användbar än något påstående om att vara anonym.

Börja vid klienten och följ paketet utåt

Innan något lämnar den bärbara datorn paketerar klienten paketet och adresserar det till serverns offentliga slutpunkt. Ditt lokala nät och din leverantör ser ett enda flöde till den adressen och porten, med en storlek och en rytm. Det de inte ser är vilken webbplats du öppnade, eftersom den destinationen ligger inne i den krypterade nyttolasten. Linjen mellan metadata och innehåll är hela genomgången i en enda mening.

Det första hoppet är där de flesta marknadsföringspåståenden slutar vara intressanta. En granne på samma Wi-Fi ser det leverantören ser, och ingen av dem ser sidan. Volym och timing förblir dock synliga, och de beskriver beteende även när nyttolasten inte gör det.

Värdnätet ser tunneln, inte sidan

Inne i leverantörens nät anländer det krypterade flödet till en switch, sedan till ett virtuellt gränssnitt, sedan till din VM. Den som driver det nätet kan räkna byte och föra flödesregister utan att inneha någon nyckel, och det behövs ingen nyckel för det. Det är precis den position en webbhotellsleverantör intar.

På vägen ut ändras bilden. VM:en öppnar en ny anslutning till destinationen, så värdnätet kan se den destinationsadressen och TLS-handskakningen runt den. Nyttolasten förblir skyddad av applikationens egen kryptering, och metadatan gör det inte.

Läs raderna i ordning och problemets form visar sig: varje rad ser mer än raden ovanför, och ingen av dem behöver bryta VPN:en för att göra det.

Inne i VM:en slutar tunneln och klartext börjar

Tunneln slutar på din VM, så gästen ser det inre paketet innan något krypterar det igen. Det är inget fel; det är vad en självhostad utgång gör. Det betyder att utgångens säkerhet beror på vem som administrerar gästen, och på det kontot är du administratören.

wg show
ss -tunp | head
nft list ruleset | head -40

Kör dem på servern och du inspekterar samma sockets som en operatör med root på gästen skulle kunna inspektera. Allt som tjänsterna du kör loggar ligger inom samma förtroendegräns, och därför är gästens logginställningar och infrastrukturposter två separata frågor och inte en inställning.

Hypervisorn sitter under gästen

En virtuell maskin äger inte kärnan den kör på. Hypervisorn kartlägger dess minne och dess virtuella nätverkskort, så en operatör på det lagret står utanför gästens förmåga att granska. Gästisolering är verklig och värd att lita på mellan hyresgäster, och den är inte ett löfte om att privilegierad åtkomst är omöjlig. Den asymmetrin förtjänar att sägas rakt ut i stället för att gömma sig bakom ordet isolering.

En dedikerad fysisk server ändrar arrangemanget utan att ta bort nätet, den fysiska åtkomsten eller det administrationsgränssnitt leverantören tillhandahåller. Läs vad produkten dokumenterar i stället för att låta ett enda ord avgöra åtkomstfrågan.

Gör genomgången till ett förtroendebeslut

Skriv ner varje observatör och den förmåga du ger den, och avgör sedan om den tilldelningen passar trafiken du planerar att skicka. Listan är kort: ditt lokala nät, din leverantör, värdnätet, hypervisoroperatören och du. Allt annat är en underleverantör till någon av dem och ärver samma förmåga. Att besluta i förväg är billigare än att upptäcka listan efteråt.

Bekräfta sedan de delar du faktiskt kan kontrollera: vilka loggar dina egna tjänster skriver, hur länge du behåller dem och vad leverantören publicerar om flödesregister och lagring. Policyer du kan läsa och testa slår antaganden om vad ett ord som privat betyder.