De VPN heeft je oude IP niet gelekt: een onthouden waarde deed dat
Een dienst kan je oude openbare adres melden terwijl de nieuwe verbinding de VPN-uitgang gebruikt. Scheid de bronheader van het pakket van een waarde die de app heeft bewaard.
Je oude openbare adres zien in het rapport van een dienst nadat de VPN actief is, is op zichzelf geen bewijs van een lek. De live verbinding kan de tunneluitgang gebruiken terwijl de applicatie een waarde verstuurt die hij leerde voordat de tunnel bestond. Dat zijn twee verschillende bewijzen, en slechts één beschrijft het huidige pakket. Het andere is een waarde die de herverbinding overleefde omdat niets op het netwerkpad er eigenaar van is.
De twee verklaringen achter één adres
De volgorde die mensen zich voorstellen is een pakket dat de fysieke interface verlaat terwijl de VPN zogenaamd actief is. De volgorde die het rapport vaak verklaart is korter en saaier: een applicatie leerde eerder een adres en houdt het nog steeds vast. De gebeurtenissen op volgorde leggen scheidt de twee.
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
Niets in die volgorde vereist een live verbinding vanaf het eerste adres. De onthouden waarde reist in het bericht, terwijl de header de uitgang draagt die de huidige route koos. Een dienst die beide velden logt, toont ze naast elkaar en ziet er tegenstrijdig uit.
Dat is een mogelijke verklaring, geen beschuldiging aan een bepaalde client. Reputatie is geen bewijs: een codebase die je kunt lezen, een merk dat je vertrouwt of een andere uitgang zeggen niets over wat één programma bewaarde of verstuurde.
Het app-geheugen overleeft de herverbinding
Een VPN verbinden verandert de route die een nieuwe verbinding neemt. Het laat de app-status ongemoeid en kan informatie die een externe dienst al heeft opgeslagen niet intrekken. Een programma kan een account-ID, een opgeslagen locatie, een apparaatnaam of een andere eerder verkregen waarde versturen, en encryptie beschermt die payload onderweg zonder er iets van te verwijderen. De herverbinding is een netwerkgebeurtenis; de bewaarde waarde is een app-gebeurtenis.
Het onderscheid is belangrijk omdat de twee op verschillende plekken leven. App-status hoort bij het programma en overleeft herstarts, terwijl de route bij het besturingssysteem hoort en bij elke verbinding opnieuw wordt opgebouwd. Het ene opschonen heeft geen effect op het andere.
Een dienst kan ook een waarde bewaren die je hem maanden geleden gaf, en in dat geval zal geen lokale wijziging die verwijderen. Dat is bewaring, en die staat volledig buiten de tunnel.
Lees eerst de bronheader, dan de payload
Begin met vast te stellen waar het adres opdook. Het verbindingslog van een server beschrijft de live bron, terwijl een berichtveld, een accountprofiel of een lokale diagnostische weergave een waarde kunnen beschrijven die veel eerder is verzonden of opgeslagen. Die observaties beantwoorden verschillende vragen.
Vergelijk ook de tijden. Als het oude adres opduikt in een veld dat aan de VPN-verbinding voorafgaat, is de payload-verklaring sterker. Als de server een directe verbinding vanaf het oude adres registreert terwijl de tunnel actief is, is dat een routeringsvraag en vraagt dat een ander onderzoek. De observatietypen eerst sorteren voorkomt dat één adres wordt uitgerekt tot bewijs van drie gebeurtenissen.
Houd ze apart in je notities: verbindingsbron, berichtveld, accountweergave, lokale diagnostiek. Eén adres op vier plaatsen is nog steeds één adres.
Bewaren is een andere fase dan transport
De privacyrichtlijnen in RFC 6973 behandelen verzameling, gebruik, openbaarmaking en bewaring als afzonderlijke fasen, en waarschuwen dat hergebruikte identificatoren correlatie makkelijk maken. Een nieuw netwerkpad verandert de transportfase en niets anders. Gegevens die de ontvanger al heeft, blijven onaangeroerd, en dat geldt ook voor elk profiel dat de waarde bij de ingang opsloeg. Daarom kan een herverbinding als een mislukking voelen terwijl het transport correct werkt.
Geen enkel packetfilter kan een waarde uit de gegevens van een ontvanger wissen, en opnieuw verbinden zal niet de opgeslagen geschiedenis van elk programma wissen. Dat zijn problemen van de gegevensbeheerder, niet van de tunnel, en ze vragen een ander soort oplossing. Vraag de dienst wat hij bewaart en hoe lang voordat je het netwerk vraagt het te verbergen.
Wat je moet controleren voordat je de tunnel de schuld geeft
Bekijk de gedocumenteerde verzameling en accountinstellingen van de app, en beslis welke velden hij mag versturen, hoe lang de dienst ze bewaart en of het account ze kan wissen of corrigeren. Voer daarna de test uit die de verklaringen scheidt: een nieuw account of een schoon applicatieprofiel. Als de oude waarde verdwijnt, waren bewaring of gecachte status in het spel. Als hij een schoon profiel overleeft, onderzoek dan het werkelijke verzoekveld voordat je concludeert dat de VPN heeft gefaald.
Als er echt een directe verbinding is, behandel die dan als een bevinding over het netwerkpad. Onderzoek routering, split-tunnel en clientbeleid op hun eigen voorwaarden, en meng dat resultaat niet met een payloadwaarde die simpelweg de herverbinding overleefde. De twee fouten lijken op een schermafbeelding op elkaar en gedragen zich volstrekt anders in een opname.