VPN lekket ikke din gamle IP: en husket verdi gjorde det

Å se din gamle offentlige adresse i en tjenestes rapport etter at VPN er oppe er ikke i seg selv bevis på en lekkasje. Den levende tilkoblingen kan bruke tunnelens utgang mens applikasjonen sender en verdi den lærte før tunnelen fantes. Det er to forskjellige bevis, og bare ett av dem beskriver den aktuelle pakken. Det andre er en verdi som overlevde gjenoppkoblingen fordi ingenting på nettverksstien eier den.

De to forklaringene bak én adresse

Sekvensen folk forestiller seg er en pakke som forlater det fysiske grensesnittet mens VPN angivelig er aktivt. Sekvensen som ofte forklarer rapporten er kortere og kjedeligere: en applikasjon lærte en adresse tidligere og holder fortsatt på den. Å legge hendelsene i rekkefølge skiller 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

Ingenting i den rekkefølgen krever en levende tilkobling fra den første adressen. Den huskede verdien reiser inne i meldingen, mens hodet bærer den utgangen den nåværende ruten valgte. En tjeneste som logger begge feltene vil vise dem side om side og se motstridende ut.

Det er en mulig forklaring, ikke en anklage mot en bestemt klient. Omdømme er ikke bevis: en kodebase du kan lese, et merke du stoler på eller en annen utgang sier ingenting om hva ett program beholdt eller sendte.

Applikasjonens minne overlever gjenoppkoblingen

Å koble til en VPN endrer ruten en ny tilkobling tar. Det lar applikasjonstilstanden være og kan ikke trekke tilbake informasjon en ekstern tjeneste allerede har lagret. Et program kan sende inn en kontoidentifikator, en lagret plassering, et enhetsnavn eller en annen verdi det fikk tidligere, og kryptering beskytter den nyttelasten underveis uten å fjerne noe fra den. Gjenoppkoblingen er en nettverkshendelse; den beholdte verdien er en applikasjonshendelse.

Forskjellen betyr noe fordi de to bor på forskjellige steder. Applikasjonstilstand tilhører programmet og overlever omstarter, mens ruten tilhører operativsystemet og bygges på nytt ved hver tilkobling. Å rydde den ene har ingen virkning på den andre.

En tjeneste kan også holde på en verdi du ga den for måneder siden, og i så fall vil ingen lokal endring fjerne den. Det er lagring, og den ligger helt utenfor tunnelen.

Les kildehodet først, deretter nyttelasten

Begynn med å fastslå hvor adressen dukket opp. En servers tilkoblingslogg beskriver den levende kilden, mens et meldingsfelt, en kontoprofil eller en lokal diagnostisk visning kan beskrive en verdi som ble sendt eller lagret mye tidligere. De observasjonene svarer på forskjellige spørsmål.

Sammenlign tidene også. Hvis den gamle adressen dukker opp i et felt som ligger før VPN-tilkoblingen, er nyttelastforklaringen sterkere. Hvis serveren registrerer en direkte tilkobling fra den gamle adressen mens tunnelen er oppe, er det et rutingspørsmål og krever en annen undersøkelse. Å sortere observasjonstypene først hindrer at én adresse strekkes til bevis for tre hendelser.

Hold dem atskilt i notatene dine: tilkoblingskilde, meldingsfelt, kontovisning, lokal diagnostikk. Én adresse skrevet fire steder er fortsatt én adresse.

Lagring er et annet trinn enn transport

Personvernveiledningen i RFC 6973 behandler innsamling, bruk, utlevering og lagring som forskjellige trinn, og den advarer om at gjenbrukte identifikatorer gjør korrelasjon enkelt. En ny nettverkssti endrer transporttrinnet og ingenting annet. Oppføringer mottakeren allerede har, berøres ikke, og det samme gjelder enhver profil som lagret verdien ved inngangen. Derfor kan en gjenoppkobling føles mislykket mens transporten oppfører seg riktig.

Ingen pakkefilter kan slette en verdi fra en mottakers oppføringer, og å koble til på nytt vil ikke rydde hvert programs lagrede historikk. Dette er dataeierproblemer snarere enn tunnelproblemer, og de trenger en annen type løsning. Spør tjenesten hva den lagrer og hvor lenge før du ber nettverket skjule det.

Hva du bør sjekke før du klandrer tunnelen

Gå gjennom applikasjonens dokumenterte innsamling og kontokontroller, og avgjør hvilke felt den kan sende inn, hvor lenge tjenesten lagrer dem, og om kontoen kan rydde eller rette dem. Kjør deretter testen som skiller forklaringene: en ny konto eller en ren applikasjonsprofil. Hvis den gamle verdien forsvinner, var lagring eller bufret tilstand involvert. Hvis den overlever en ren profil, undersøk det faktiske forespørselsfeltet før du konkluderer med at VPN feilet.

Hvis en direkte tilkobling virkelig finnes, behandle den som et funn på nettverksstien. Undersøk ruting, delt tunnel og klientpolicy på deres egne vilkår, og ikke bland det resultatet med en nyttelastverdi som bare overlevde gjenoppkoblingen. De to feilene ser like ut på et skjermbilde og oppfører seg helt forskjellig i en opptak.