VPN läckte inte din gamla IP: ett ihågkommet värde gjorde det

Att se din gamla offentliga adress i en tjänsts rapport efter att VPN har startat är inte i sig bevis på en läcka. Den levande anslutningen kan använda tunnelns utgång medan appen skickar ett värde som den lärde sig innan tunneln fanns. Det är två olika bevis, och bara ett av dem beskriver det aktuella paketet. Det andra är ett värde som överlevde återanslutningen eftersom ingenting på nätverksvägen äger det.

De två förklaringarna bakom en adress

Sekvensen som människor föreställer sig är ett paket som lämnar det fysiska gränssnittet medan VPN:et påstås vara aktivt. Sekvensen som ofta förklarar rapporten är kortare och tråkigare: en app lärde sig en adress tidigare och håller fortfarande kvar den. Att lägga händelserna i ordning skiljer de två.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

Ingenting i den ordningen kräver en levande anslutning från den första adressen. Det ihågkomna värdet reser inuti meddelandet, medan huvudet bär den utgång som den nuvarande rutten valde. En tjänst som loggar båda fälten visar dem sida vid sida och verkar motsägelsefull.

Det är en möjlig förklaring, inte en anklagelse mot en viss klient. Rykte är inte bevis: en kodbas du kan läsa, ett varumärke du litar på eller en annan utgång säger ingenting om vad ett program behöll eller skickade.

Appens minne överlever återanslutningen

Att ansluta ett VPN ändrar rutten som en ny anslutning tar. Det lämnar appens tillstånd i fred och kan inte dra tillbaka information som en fjärrtjänst redan har lagrat. Ett program kan skicka ett konto-ID, en sparad plats, ett enhetsnamn eller ett annat tidigare erhållet värde, och kryptering skyddar den nyttolasten under vägen utan att ta bort något från den. Återanslutningen är en nätverkshändelse; det behållna värdet är en apphändelse.

Skillnaden spelar roll eftersom de två lever på olika platser. Appens tillstånd tillhör programmet och överlever omstarter, medan rutten tillhör operativsystemet och byggs upp igen vid varje anslutning. Att rensa det ena har ingen effekt på det andra.

En tjänst kan också behålla ett värde som du gav den för månader sedan, och i så fall kommer ingen lokal ändring att ta bort det. Det är lagring, och den ligger helt utanför tunneln.

Läs källhuvudet först, sedan nyttolasten

Börja med att fastställa var adressen dök upp. En servers anslutningslogg beskriver den levande källan, medan ett meddelandefält, en kontoprofil eller en lokal diagnostikvy kan beskriva ett värde som skickades eller lagrades mycket tidigare. De observationerna svarar på olika frågor.

Jämför också tiderna. Om den gamla adressen dyker upp i ett fält som föregår VPN-anslutningen är nyttolastförklaringen starkare. Om servern registrerar en direkt anslutning från den gamla adressen medan tunneln är uppe är det en routingfråga och kräver en annan undersökning. Att sortera observationstyperna först hindrar att en adress sträcks ut till bevis för tre händelser.

Håll dem åtskilda i dina anteckningar: anslutningskälla, meddelandefält, kontovy, lokal diagnostik. En adress skriven på fyra ställen är fortfarande en adress.

Lagring är en annan fas än transport

Integritetsriktlinjerna i RFC 6973 behandlar insamling, användning, utlämnande och lagring som olika faser, och de varnar för att återanvända identifierare gör korrelation enkel. En ny nätverksväg ändrar transportfasen och ingenting annat. Poster som mottagaren redan har berörs inte, och det gäller även varje profil som lagrade värdet vid ingången. Därför kan en återanslutning kännas som ett misslyckande medan transporten beter sig korrekt.

Inget paketfilter kan radera ett värde från en mottagares poster, och att ansluta igen kommer inte att rensa varje programs lagrade historik. Det är dataägarproblem snarare än tunnelproblem, och de behöver en annan typ av lösning. Fråga tjänsten vad den lagrar och hur länge innan du ber nätverket dölja det.

Vad du bör kontrollera innan du skyller på tunneln

Gå igenom appens dokumenterade insamling och kontokontroller, och avgör vilka fält den får skicka, hur länge tjänsten lagrar dem och om kontot kan rensa eller rätta dem. Kör sedan testet som skiljer förklaringarna: ett nytt konto eller en ren appprofil. Om det gamla värdet försvinner var lagring eller cachelagrat tillstånd inblandat. Om det överlever en ren profil, undersök det faktiska begäransfältet innan du drar slutsatsen att VPN:et misslyckades.

Om en direkt anslutning verkligen finns, behandla den som ett fynd om nätverksvägen. Undersök routing, delad tunnel och klientpolicy på deras egna villkor, och blanda inte det resultatet med ett nyttolastvärde som helt enkelt överlevde återanslutningen. De två felen ser likadana ut på en skärmbild och beter sig helt annorlunda i en inspelning.