Via servilo vidas la eliron de VPN, ne la vizitanton

Vizitanto konektiĝas per komerca VPN, kaj via aplikaĵo registras la eliran adreson. Tio ne estas kaŝita identeco: ĝi estas la sola fonta adreso, kiun havas la TCP-konekto. Ĉio alia, kion homoj nomas detektado, estas konkludo tavoligita sur tiu unu fakto.

Kion peto efektive portas

La aplikaĵo vidas la fontan adreson kaj pordon de la konekto, la manpremon, kiun ĝi finis, kaj la bajtojn, kiujn la kliento elektis sendi. Sub plena tunelo, tiu fonto estas la eliro, kunhavata de ĉiuj, kiuj uzas ĝin. Sub dividita tunelo, petoj povas alveni el la tunelo aŭ el la loka konekto depende de la celo. Se la kliento kaj la servilo estas ambaŭ ene de la sama VPN, la fonto estas la interna tunela adreso de la kliento, kiu identigas finpunkton anstataŭ lokon.

Neniu kampo en ordinara peto portas la adreson, kiun la kliento havis antaŭ la tunelo. Forwarda kaplinio estas aserto de la kliento aŭ de prokurilo, kaj ĝi povas esti forlasita aŭ falsigita.

Detektado estas klasifiko, kaj klasifiko estas konjekto

La praktikaj metodoj estas listoj de konataj VPN- kaj gastigaj intervaloj, latento, kiu malkongruas kun asertita regiono, formoj de traceroute, kaj konta konduto. Ĉiu el ili produktas probablon. Kompania VPN povas sidi sur adresoj, kiuj aspektas loĝejaj, loĝeja prokurilo povas aspekti kiel hejma linio, kaj la NAT de la operatoro povas aspekti kiel gastiga intervalo.

Blokado de kunhavata eliro blokas ĉiun nerilatan uzanton malantaŭ ĝi, kio transformas detektan decidon en flankefikan interrompon. Fidokvoto ne estas identeco kaj neniam devus esti la sola enigo por decido pri malpermeso aŭ repago.

Se vi posedas la VPN, vi havas fidindan signalon tute senrilatan al detektado: atribuu dediĉitan naĝejon kaj kongruigu la observatan fonton kun ĝi. Tio funkcias ĉar vi regas ambaŭ finojn kaj povas dokumenti la naĝejon. Sed ĝi ne ĝeneraligeblas al vizitantoj, kiujn vi ne administras, kaj ĝi ĉesas esti fidinda en la momento, kiam la naĝejo estas kunhavata kun aliaj servoj.

Lokaj evidentaĵoj kontraŭ pruvo ĉe la servilo

Sur la maŝino mem tunelo estas videbla: virtuala adaptilo, defaŭlta vojo montranta al tunela aparato, solvilo, kiu ŝanĝiĝis. Kodo kuranta tie povas listigi interfacojn kaj serĉi PPP, TAP aŭ vendistan pelilon.

Retpaĝo ne povas legi ion el tio. La kutima ĉirkaŭvojo ŝargas rimedon servatan nur el la interna reto kaj traktas sukceson kiel pruvon pri tunela uzo. Ĝi fakte testas atingeblon: dividita tunelo, malnova kaŝmemora dosiero aŭ interkapta prokurilo donas la saman rezulton en ambaŭ statoj. Lokaj evidentaĵoj restas lokaj.

Elektu alirkontrolojn, kiuj postvivas la ambiguecon

Konstruu alirkontrolon sur konfirmita identeco, aparata sano kaj rajtigo por ĉiu rimedo. Tiuj predikatoj priskribas, kiu demandas kaj kion li rajtas atingi, kaj ili restas signifoplenaj sendepende de tio, ĉu tunelo estas implikita. Ĉu peto alvenis per VPN estas malforta signalo, kiu produktas kaj falsajn akceptojn kaj flankefikajn blokadojn. Tenu la evidentaĵon kaj la decidon en apartaj kampoj, por ke pridisputata blokado havu ion por revizii.

IP-geolokado estas unu enigo inter pluraj, kaj lokaj servoj de la retumilo povas uzi Wi-Fi aŭ GPS, kiuj neniam sekvas la tunelon. Mapo, kiu ankoraŭ montras la urbon de la vizitanto, estas evidentaĵo pri lokaj servoj, ne pruvo, ke la tunelo malsukcesis.

Notu, kiu signalo gvidis ĉiun decidon. Kiam kliento disputas blokadon, tiu registro estas la diferenco inter revizio kaj argumento.