A VPN nem szivárogtatta ki a régi IP-t: egy megjegyzett érték tette
Egy szolgáltatás jelentheti a régi nyilvános címedet, miközben az új kapcsolat a VPN kijáratát használja. Válaszd szét a csomag forrásfejlécét attól az értéktől, amelyet az alkalmazás megtartott.
Ha a VPN bekapcsolása után a régi nyilvános címed megjelenik egy szolgáltatás jelentésében, az önmagában nem szivárgás bizonyítéka. Az élő kapcsolat használhatja az alagút kijáratát, miközben az alkalmazás olyan értéket küld, amelyet az alagút létezése előtt tanult. Ez két különböző bizonyíték, és csak az egyik írja le az aktuális csomagot. A másik egy érték, amely túlélte az újracsatlakozást, mert a hálózati útvonalon semmi sem birtokolja.
Két magyarázat egy cím mögött
A sorrend, amelyet az emberek elképzelnek, egy csomag, amely elhagyja a fizikai interfészt, miközben a VPN állítólag aktív. A jelentést gyakran magyarázó sorrend rövidebb és unalmasabb: egy alkalmazás korábban megtanult egy címet, és még mindig tartja. Az események sorba rendezése szétválasztja a kettőt.
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
Ebben a sorrendben semmi sem igényel élő kapcsolatot az első címről. A megjegyzett érték az üzeneten belül utazik, míg a fejléc azt a kijáratot hordozza, amelyet az aktuális útvonal választott. Egy szolgáltatás, amely mindkét mezőt naplózza, egymás mellett mutatja őket, és ellentmondásosnak tűnik.
Ez lehetséges magyarázat, nem vád egy adott kliens ellen. A hírnév nem bizonyíték: egy olvasható kódbázis, egy márka, amelyben bízol, vagy egy másik kijárat semmit sem mond arról, mit tartott meg vagy küldött el egy program.
Az alkalmazás memóriája túléli az újracsatlakozást
A VPN csatlakoztatása megváltoztatja az útvonalat, amelyet egy új kapcsolat vesz. Békén hagyja az alkalmazás állapotát, és nem tud visszavonni olyan információt, amelyet egy távoli szolgáltatás már tárolt. Egy program beküldhet fiókazonosítót, mentett helyet, eszköznevet vagy más korábban szerzett értéket, és a titkosítás megvédi ezt a hasznos terhet útközben, anélkül hogy bármit eltávolítana belőle. Az újracsatlakozás hálózati esemény; a megtartott érték alkalmazásesemény.
A különbség számít, mert a kettő különböző helyen él. Az alkalmazás állapota a programhoz tartozik, és túléli az újraindításokat, míg az útvonal az operációs rendszerhez tartozik, és minden kapcsolatnál újraépül. Az egyik tisztítása nincs hatással a másikra.
Egy szolgáltatás olyan értéket is tarthat, amelyet hónapokkal ezelőtt adtál neki, és ebben az esetben semmilyen helyi változtatás nem távolítja el. Ez megőrzés, és teljesen az alagúton kívül van.
Először a forrásfejlécet olvasd, aztán a hasznos terhet
Kezdd azzal, hogy megállapítod, hol jelent meg a cím. Egy kiszolgáló kapcsolati naplója az élő forrást írja le, míg egy üzenetmező, egy fiókprofil vagy egy helyi diagnosztikai kijelző egy sokkal korábban beküldött vagy tárolt értéket írhat le. Ezek a megfigyelések különböző kérdésekre válaszolnak.
Hasonlítsd össze az időket is. Ha a régi cím a VPN-kapcsolatot megelőző mezőben jelenik meg, a hasznos teher magyarázata erősebb. Ha a kiszolgáló közvetlen kapcsolatot rögzít a régi címről, miközben az alagút aktív, az útvonalazási kérdés, és másfajta vizsgálatot igényel. A megfigyeléstípusok előzetes rendezése megakadályozza, hogy egy címet három esemény bizonyítékává nyújtsanak.
Tartsd őket külön a jegyzeteidben: kapcsolat forrása, üzenetmező, fiókkijelző, helyi diagnosztika. Egy cím, amelyet négy helyen írtak le, még mindig egy cím.
A megőrzés más szakasz, mint az átvitel
A RFC 6973 adatvédelmi irányelvei a gyűjtést, a felhasználást, a közzétételt és a megőrzést külön szakaszként kezelik, és figyelmeztetnek arra, hogy az újrahasznált azonosítók megkönnyítik a korrelációt. Egy új hálózati útvonal megváltoztatja az átviteli szakaszt, és semmi mást. A címzett által már tartott rekordok érintetlenek maradnak, akárcsak minden profil, amely a belépéskor tárolta az értéket. Ezért tűnhet úgy egy újracsatlakozás, mintha kudarcot vallott volna, miközben az átvitel helyesen működik.
Egyetlen csomagszűrő sem tud törölni egy értéket a címzett rekordjaiból, és az újracsatlakozás nem törli minden program tárolt előzményeit. Ezek adattulajdonosi problémák, nem alagútproblémák, és másfajta megoldást igényelnek. Kérdezd meg a szolgáltatást, mit és meddig tart meg, mielőtt a hálózatot kéred, hogy rejtse el.
Mit ellenőrizz, mielőtt az alagutat hibáztatod
Tekintsd át az alkalmazás dokumentált gyűjtését és fiókvezérlőit, és döntsd el, milyen mezőket küldhet be, meddig tartja meg őket a szolgáltatás, és a fiók törölheti vagy javíthatja-e őket. Ezután futtasd a magyarázatokat szétválasztó tesztet: egy új fiók vagy egy tiszta alkalmazásprofil. Ha a régi érték eltűnik, megőrzés vagy gyorsítótárazott állapot volt a háttérben. Ha túléli egy tiszta profilt, vizsgáld meg a tényleges kérelemmezőt, mielőtt arra jutnál, hogy a VPN kudarcot vallott.
Ha valóban létezik közvetlen kapcsolat, kezeld hálózati útvonal-megállapításként. Vizsgáld az útvonalazást, a megosztott alagutat és a kliensházirendet a saját feltételeik szerint, és ne keverd ezt az eredményt egy olyan hasznos teher értékével, amely egyszerűen túlélte az újracsatlakozást. A két hiba képernyőképen hasonlónak tűnik, és egy rögzítésben teljesen másképp viselkedik.