A szervered a VPN kijáratát látja, nem a látogatót

Egy látogató kereskedelmi VPN-en keresztül kapcsolódik, és az alkalmazásod rögzíti a kimenő címet. Ez nem rejtett identitás: ez az egyetlen forrás-cím, amivel a TCP-kapcsolat rendelkezik. Minden más, amit az emberek felismerésnek neveznek, erre az egyetlen tényre épülő következtetés.

Mit hordoz valójában egy kérés

Az alkalmazás látja a kapcsolat forrás-címét és portját, a befejezett kézfogást és azokat a bájtokat, amelyeket a kliens elküldeni választott. Teljes alagút esetén ez a forrás a kijárat, amelyet minden használója megoszt. Osztott alagút esetén a kérések a céltól függően az alagútból vagy a helyi kapcsolatból érkezhetnek. Ha a kliens és a szerver ugyanabban a VPN-ben van, a forrás a kliens belső alagútcíme, amely végpontot jelöl, nem helyet.

Egy közönséges kérés egyetlen mezője sem hordozza azt a címet, amely a kliensnek az alagút előtt volt. A továbbítási fejléc a kliens vagy egy proxy állítása, és elhagyható vagy hamisítható.

A felismerés osztályozás, az osztályozás pedig találgatás

A gyakorlati módszerek ismert VPN- és tárhelytartományok listái, a megadott régióval nem egyező késleltetés, traceroute-alakok és fiókviselkedés. Mindegyik valószínűséget ad. Egy vállalati VPN ülhet lakóinak tűnő címeken, egy lakó proxy nézhet ki otthoni vonalként, és a szolgáltató NAT-ja nézhet ki tárhelytartományként.

Egy megosztott kijárat blokkolása minden mögötte lévő független felhasználót blokkol, ami a felismerési döntést járulékos kieséssé változtatja. A bizalmi pontszám nem identitás, és soha nem lehet a tiltási vagy visszatérítési döntés egyetlen bemenete.

Ha a VPN a tiéd, van egy megbízható jeled, amelynek semmi köze a felismeréshez: jelölj ki egy dedikált készletet, és vesd össze vele a megfigyelt forrást. Ez azért működik, mert mindkét végét te irányítod, és a készletet dokumentálhatod. De nem általánosítható azokra a látogatókra, akiket nem kezelsz, és abban a pillanatban megszűnik megbízhatónak lenni, amikor a készletet más szolgáltatásokkal osztják meg.

Helyi bizonyíték a szerver oldali bizonyítással szemben

Magán a gépen egy alagút látható: virtuális adapter, az alagúteszközre mutató alapértelmezett útvonal, megváltozott feloldó. Az ott futó kód felsorolhatja az interfészeket, és kereshet PPP-t, TAP-ot vagy gyártói illesztőprogramot.

Egy weboldal ezekből semmit sem tud kiolvasni. A szokásos kerülőút egy csak a belső hálózatról kiszolgált erőforrást tölt be, és a sikert az alagút használatának bizonyítékaként kezeli. Valójában az elérhetőséget teszteli: egy osztott alagút, egy elavult gyorsítótárazott fájl vagy egy elfogó proxy mindkét állapotban ugyanazt az eredményt adja. A helyi bizonyíték helyi marad.

Válassz olyan hozzáférés-vezérlést, amely túléli a bizonytalanságot

Építsd a hozzáférés-vezérlést igazolt identitásra, eszköz-egészségre és erőforrásonkénti engedélyezésre. Ezek a predikátumok leírják, ki kérdez és mit érhet el, és akkor is értelmesek maradnak, ha alagút van a képben, és akkor is, ha nincs. Az, hogy egy kérés VPN-en keresztül érkezett-e, gyenge jel, amely téves elfogadásokat és járulékos blokkolásokat egyaránt okoz. Tartsd a bizonyítékot és a döntést külön mezőkben, hogy egy vitatott blokkolásnak legyen mit felülvizsgálni.

Az IP-geolokáció egy bemenet a sok közül, és a böngésző helyszolgáltatásai használhatnak Wi-Fi-t vagy GPS-t, amelyek soha nem követik az alagutat. Egy térkép, amely még mindig a látogató városát mutatja, a helyszolgáltatásokról szóló bizonyíték, nem annak bizonyítéka, hogy az alagút meghibásodott.

Írd le, melyik jel vezérelte az egyes döntéseket. Amikor egy ügyfél vitat egy blokkolást, ez a feljegyzés a különbség egy felülvizsgálat és egy vita között.