Die VPN het nie jou ou IP gelek nie: ’n onthoude waarde het

Om jou ou openbare adres in ’n diens se verslag te sien nadat die VPN opkom, is op sigself nie bewys van ’n lek. Die lewendige verbinding kan die tonneluitgang gebruik terwyl die toepassing ’n waarde instuur wat hy geleer het voordat die tonnel bestaan het. Dit is twee verskillende stukke bewyse, en net een daarvan beskryf die huidige pakket. Die ander is ’n waarde wat die herverbinding oorleef het omdat niks in die netwerkpad dit besit nie.

Die twee verklarings agter een adres

Die reeks wat mense hul voorstel, is ’n pakket wat die fisiese koppelvlak verlaat terwyl die VPN vermoedelik aktief is. Die reeks wat die verslag dikwels verduidelik, is korter en vaal: ’n toepassing het vroeër ’n adres geleer en hou dit steeds. Om die gebeure in volgorde te lê, skei die 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

Niks in daardie volgorde vereis ’n lewendige verbinding vanaf die eerste adres nie. Die onthoude waarde ry binne-in die boodskap, terwyl die kop dra wat die huidige roete ook al gekies het. ’n Diens wat albei velde teken, sal hulle langs mekaar wys en teenstrydig lyk.

Dit is ’n moontlike verklaring, nie ’n beskuldiging teen enige bepaalde kliënt nie. Reputasie is nie bewyse nie: ’n kodebasis wat jy kan lees, ’n handelsmerk wat jy vertrou of ’n ander uitgang sê niks oor wat een program gehou of gestuur het nie.

Toepassingsgeheue oorleef die herverbinding

Om ’n VPN te koppel verander die roete wat ’n nuwe verbinding neem. Dit los toepassingstoestand alleen, en dit kan nie inligting terugtrek wat ’n afgeleë diens reeds gestoor het nie. ’n Program kan ’n rekeningidentifiseerder, ’n gestoorde ligging, ’n toestelnaam of ’n ander waarde instuur wat hy vroeër verkry het, en enkripsie beskerm daardie vrag onderweg sonder om enigiets daaruit te verwyder. Die herverbinding is ’n netwerkgebeurtenis; die behoude waarde is ’n toepassingsgebeurtenis.

Die onderskeid is belangrik omdat die twee op verskillende plekke woon. Toepassingstoestand behoort aan die program en oorleef herstarts, terwyl die roete aan die bedryfstelsel behoort en by elke verbinding herbou word. Om een skoon te maak, het geen uitwerking op die ander nie.

’n Diens kan ook ’n waarde hou wat jy maande gelede aan hom gegee het, en in daardie geval sal geen plaaslike verandering dit verwyder nie. Dit is bewaring, en dit sit heeltemal buite die tonnel.

Lees die bronkop, dan die vrag

Begin deur vas te stel waar die adres opgedaag het. ’n Bediener se verbindingslog beskryf die lewendige bron, terwyl ’n boodskapveld, ’n rekeningprofiel of ’n plaaslike diagnostiese skerm ’n waarde kan beskryf wat veel vroeër ingedien of gestoor is. Daardie waarnemings beantwoord verskillende vrae.

Vergelyk ook die tye. As die ou adres in ’n veld verskyn wat die VPN-verbinding voorafgaan, is die vragverklaring sterker. As die bediener ’n direkte verbinding vanaf die ou adres aanteken terwyl die tonnel op is, is dit ’n roetevraag en verg dit ’n ander ondersoek. Om eers die soorte waarnemings te sorteer, verhoed dat een adres tot bewys van drie gebeurtenisse uitgerek word.

Hou hulle apart in jou notas: verbindingsbron, boodskapveld, rekeningvertoning, plaaslike diagnostiek. Een adres wat op vier plekke geskryf is, is steeds een adres.

Bewaring is ’n ander stadium as vervoer

Die privaatheidsriglyne in RFC 6973 behandel insameling, gebruik, openbaarmaking en bewaring as afsonderlike stadiums, en dit waarsku dat hergebruikte identifiseerders korrelasie maklik maak. ’n Nuwe netwerkpad verander die vervoerstadium en niks anders nie. Rekords wat die ontvanger reeds hou, word daardeur onaangeraak, en so ook enige profiel wat die waarde op pad in gestoor het. Dit is waarom ’n herverbinding kan voel of dit misluk het terwyl die vervoer korrek werk.

Geen pakketfilter kan ’n waarde uit ’n ontvanger se rekords verwyder nie, en weer herverbind sal nie elke program se gestoorde geskiedenis uitwis nie. Dit is data-eienaarsprobleme eerder as tonnelprobleme, en hulle verg ’n ander soort oplossing. Vra die diens wat hy hou en hoe lank voordat jy die netwerk vra om dit weg te steek.

Wat om te kontroleer voordat jy die tonnel blameer

Hersien die toepassing se gedokumenteerde insameling en rekeningbeheermaatreëls, en besluit watter velde dit mag instuur, hoe lank die diens hulle hou, en of die rekening hulle kan skoonmaak of regstel. Hardloop dan die toets wat die verklarings skei: ’n nuwe rekening of ’n skoon toepassingsprofiel. As die ou waarde verdwyn, was bewaring of gekasde toestand betrokke. As dit ’n nuwe profiel oorleef, ondersoek die werklike versoekveld voordat jy tot die gevolgtrekking kom dat die VPN gefaal het.

As ’n direkte verbinding werklik teenwoordig is, behandel dit as ’n netwerkpadbevinding. Ondersoek roetering, split-tonnel en kliëntbeleid op hulle eie voorwaardes, en moenie daardie resultaat meng met ’n vragwaarde wat bloot die herverbinding oorleef het nie. Die twee foute lyk eenders in ’n skermskoot en gedra hulle niks eenders in ’n opname nie.