VPN lækkede ikke din gamle IP: en husket værdi gjorde det

At se din gamle offentlige adresse i en tjenestes rapport, efter VPN er oppe, er ikke i sig selv bevis på en lækage. Den levende forbindelse kan bruge tunnelens udgang, mens applikationen indsender en værdi, den lærte, før tunnelen fandtes. Det er to forskellige beviser, og kun det ene beskriver den aktuelle pakke. Det andet er en værdi, der overlevede genopkoblingen, fordi intet i netværksstien ejer den.

De to forklaringer bag én adresse

Sekvensen, som folk forestiller sig, er en pakke, der forlader den fysiske grænseflade, mens VPN angiveligt er aktiv. Sekvensen, der ofte forklarer rapporten, er kortere og kedeligere: en applikation lærte en adresse tidligere og holder stadig på den. At lægge hændelserne i rækkefølge adskiller de to.

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

Intet i den rækkefølge kræver en levende forbindelse fra den første adresse. Den huskede værdi rejser inde i meddelelsen, mens hovedet bærer den udgang, den aktuelle rute valgte. En tjeneste, der logger begge felter, vil vise dem side om side og se modstridende ud.

Det er en mulig forklaring, ikke en anklage mod en bestemt klient. Omdømme er ikke bevis: en kodebase, du kan læse, et mærke, du stoler på, eller en anden udgang siger intet om, hvad ét program beholdt eller sendte.

Applikationens hukommelse overlever genopkoblingen

At tilslutte en VPN ændrer den rute, en ny forbindelse tager. Det lader applikationstilstand være og kan ikke trække oplysninger tilbage, som en fjern tjeneste allerede har gemt. Et program kan indsende en konto-id, en gemt placering, et enhedsnavn eller en anden værdi, det fik tidligere, og kryptering beskytter den nyttelast undervejs uden at fjerne noget fra den. Genopkoblingen er en netværkshændelse; den beholdte værdi er en applikationshændelse.

Forskellen er vigtig, fordi de to bor forskellige steder. Applikationstilstand tilhører programmet og overlever genstart, mens ruten tilhører styresystemet og genopbygges ved hver forbindelse. Rydning af det ene har ingen virkning på det andet.

En tjeneste kan også holde en værdi, du gav den for måneder siden, og i så fald vil ingen lokal ændring fjerne den. Det er opbevaring, og det ligger helt uden for tunnelen.

Læs kildehovedet, derefter nyttelasten

Begynd med at fastslå, hvor adressen dukkede op. En servers forbindelseslog beskriver den levende kilde, mens et meddelelsesfelt, en kontoprofil eller en lokal diagnostisk visning kan beskrive en værdi, der blev sendt eller gemt meget tidligere. De observationer besvarer forskellige spørgsmål.

Sammenlign også tiderne. Hvis den gamle adresse optræder i et felt, der ligger før VPN-forbindelsen, er nyttelastforklaringen stærkere. Hvis serveren registrerer en direkte forbindelse fra den gamle adresse, mens tunnelen er oppe, er det et rutingspørgsmål og kræver en anden undersøgelse. At sortere observationstyperne først forhindrer, at én adresse strækkes til bevis for tre hændelser.

Hold dem adskilt i dine noter: forbindelseskilde, meddelelsesfelt, kontovisning, lokal diagnostik. Én adresse skrevet fire steder er stadig én adresse.

Opbevaring er en anden fase end transport

Vejledningen om privatliv i RFC 6973 behandler indsamling, brug, videregivelse og opbevaring som forskellige faser og advarer om, at genbrugte identifikatorer gør korrelation let. En ny netværkssti ændrer transportfasen og intet andet. Optegnelser, modtageren allerede har, berøres ikke, og det gør en profil, der gemte værdien undervejs, heller ikke. Derfor kan en genopkobling føles som en fiasko, mens transporten opfører sig korrekt.

Intet pakkefilter kan slette en værdi fra en modtagers optegnelser, og at genopkoble igen vil ikke rydde hvert programs gemte historik. Det er dataejerproblemer snarere end tunnelproblemer, og de kræver en anden slags løsning. Spørg tjenesten, hvad den gemmer, og hvor længe, før du beder netværket om at skjule det.

Hvad du skal kontrollere, før du bebrejder tunnelen

Gennemgå applikationens dokumenterede indsamling og kontokontroller, og beslut, hvilke felter den må indsende, hvor længe tjenesten gemmer dem, og om kontoen kan rydde eller rette dem. Kør derefter testen, der adskiller forklaringerne: en ny konto eller en ren applikationsprofil. Hvis den gamle værdi forsvinder, var opbevaring eller cached tilstand involveret. Hvis den overlever en ren profil, undersøg det faktiske anmodningsfelt, før du konkluderer, at VPN fejlede.

Hvis der virkelig er en direkte forbindelse, skal du behandle det som et netværksstifund. Undersøg routing, delt tunnel og klientpolitik på deres egne betingelser, og bland ikke det resultat med en nyttelastværdi, der blot overlevede genopkoblingen. De to fejl ser ens ud på et skærmbillede og opfører sig helt forskelligt i en optagelse.