Tenaren din ser VPN-utgangen, ikkje den besøkjande

Ein besøkjande koplar til gjennom ein kommersiell VPN, og applikasjonen din loggar utgangsadressa. Det er ikkje ein skjult identitet: det er den einaste kjeldeadressa TCP-sambandet har. Alt anna folk kallar deteksjon, er slutningar lagde oppå den eine kjensgjerninga.

Kva ein førespurnad faktisk ber

Applikasjonen ser kjeldeadressa og porten til sambandet, handtrykket det fullførte, og byta klienten valde å senda. Under ein full tunnel er den kjelda utgangen, delt av alle som brukar han. Under ein delt tunnel kan førespurnader koma frå tunnelen eller frå det lokale sambandet avhengig av destinasjonen. Viss klienten og tenaren begge er inne i same VPN, er kjelda den indre tunneladressa til klienten, som identifiserer eit endepunkt og ikkje ein stad.

Ingen felt i ein vanleg førespurnad ber adressa klienten hadde før tunnelen. Ein videresendingsheader er påstanden til klienten eller ein proxy, og han kan utelatast eller falskast.

Deteksjon er klassifisering, og klassifisering er gissing

Dei praktiske metodane er lister over kjende VPN- og hostingområde, ventetid som ikkje stemmer med ein påstått region, traceroute-former og kontoåtferd. Kvar av dei gjev ein sannsyn. Ein bedrifts-VPN kan liggja på adresser som ser bustad ut, ein bustadproxy kan sjå ut som ei heimelinje, og NAT-en til operatøren kan sjå ut som eit hostingområde.

Å blokkera ein delt utgang blokkerer kvar ubeslekta brukar bak han, noko som gjer ei deteksjonsavgjerd om til ein følgjefeil. Ein tillitsscore er ikkje ein identitet og bør aldri vera det einaste innspelet til ei avgjerd om utestenging eller refusjon.

Viss du eig VPN-en, har du eit påliteleg signal som ikkje har noko med deteksjon å gjera: tildel ein dedikert pool og match den observerte kjelda mot han. Det verkar fordi du kontrollerer begge endar og kan dokumentera poolen. Men det generaliserer ikkje til besøkjande du ikkje administrerer, og det sluttar å vera påliteleg i det augneblinken poolen blir delt med andre tenester.

Lokale prov mot prov på tenarsida

På sjølve maskinen er ein tunnel synleg: ein virtuell adapter, ei standardrute som peikar på ein tunneleining, ein resolver som er endra. Kode som køyrer der, kan lista opp grensesnitt og leita etter PPP, TAP eller ein leverandørderiver.

Ei nettside kan ikkje lesa noko av dette. Den vanlege omvegen lastar ein ressurs som berre blir servert frå det interne nettet, og behandlar suksess som prov på tunnelbruk. Han testar i staden tilgjenge: ein delt tunnel, ei utdatert bufra fil eller ein avlyttingsproxy gjev same resultat i begge tilstandar. Lokale prov blir verande lokale.

Vel tilgangskontrollar som overlever uklarleiken

Bygg tilgangskontroll på stadfesta identitet, eininghelse og autorisasjon per ressurs. Desse predikata skildrar kven som spør og kva dei kan nå, og dei blir verande meiningsfulle anten ein tunnel er involvert eller ikkje. Om ein førespurnad kom over ein VPN, er eit svakt signal som gjev både falske godkjenningar og følgjeblokkeringar. Hald provet og avgjerda i separate felt, slik at ei omstridd blokkering har noko å gå gjennom.

IP-geolokasjon er eitt innspel blant fleire, og posisjonstenestene til nettlesaren kan bruka Wi-Fi eller GPS som aldri følgjer tunnelen. Eit kart som framleis viser byen til den besøkjande, er prov om posisjonstenester, ikkje prov på at tunnelen svikta.

Skriv ned kva signal som styrte kvar avgjerd. Når ein kunde bestrid ei blokkering, er den registreringa skilnaden mellom ein gjennomgang og ein diskusjon.