ElirIP de VPN ne pruvas tunelon: kion serviloj vidas

Iu petas servon atingeblan nur de VPN-uzantoj, kaj la evidenta realigo estas permesi liston de eliradresoj. La listo faras ion realan: ĝi limigas, kiuj povas konektiĝi. Ĝi ne pruvas, ke tunelo estis uzita, ĉar la adreso apartenas al tiu, kiu funkciigas la eliron, kaj tiu operatoro povas plusendi la trafikon de iu ajn. La breĉo inter tiuj asertoj estas la tuta dezajnoproblemo.

La servilo vidas unu adreson por konekto

Konekto alvenas kun fontadreso kaj celporto, kaj tio estas ĉio, kion la rettavolo raportas. Kiam kliento uzas tunelon, la pakoj atingantaj vian aŭskultilon venas de la eliro aŭ de la traduko antaŭ ĝi. La propra adreso de la kliento, kutime privata, neniam aperas. Sekve fajroŝirma regulo skribita por la loka reto de la kliento faras nenion.

Ĉio post tiu fontadreso estas aplikaj datumoj, kaj la aplikaĵo povas fidi ilin nur tiom, kiom ĝi aŭtentikigas ilin.

Testu, kiel aspektas via eliro

Rigardu la vojon de ambaŭ finoj antaŭ ol skribi regulon. La vido de la kliento pri sia eliro kaj la vido de la servilo pri la konekto estas la du faktoj, kiuj gravas.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

La unua komando raportas la publikan adreson, sub kiu la kliento aperas, kaj tio estas la valoro, kiun ĉiu permeslisto devas enhavi. La dua montras establitajn konektojn sur la servilo kun iliaj kunulaj adresoj, kaj ĝuste tion la regulo efektive kongruos. Se la du malkongruas kun via mensa modelo, riparu la modelon antaŭ ol redakti la politikon. Fajroŝirmilo de nuba datenbazo, permeslisto de aplikaĵo kaj ŝarĝbalancilo povas ĉiu vidi malsaman traduktavolon.

Nur unu el la du eliraj aroj povas esti listigita

Unu kazo estas kontrolebla en la momento de la peto kaj la alia ne, kio produktas tre malsamajn garantiojn.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

La publikigita elirlisto de Tor povas esti elŝutita kaj komparita, depende de la aĝo de la listo kaj de la propra politiko de ĉiu eliro, do malpermesa regulo kontraŭ konataj eliroj estas plenumebla kaj revidebla. Ne ekzistas ekvivalenta registro por komercaj VPN-oj. Adresoj rotacias, multaj provizantoj publikigas nenion, kaj tunelo povas funkcii sur luata nuba adreso, kiu neniam apartenis al VPN. La listo, kiun vi kunmetas, estas momenta bildo de observitaj adresoj, kaj vastigado al gastigaj gamoj aldonas nerilatajn laborŝarĝojn sen aldoni pruvon.

Uzu adresojn kiel enigon de politiko, ne kiel pruvon

Decidu, por kio la regulo estas. Reta limigo devas resti mallarĝa, registri la observitan adreson kun dato kaj kialo, kaj doni al legitimaj uzantoj rekuperan vojon, kiam ilia eliro ŝanĝiĝas. Alirkontrolo bezonas aŭtentikigitan konton aŭ subskribitan ĵetonon, ĉar nur tiuj ligas peton al identeco. Riska taksado povas uzi la adreson kiel unu malfididan signalon, akceptante ĝiajn falsajn pozitivojn kaj blindajn makulojn. Skribi la regulon kiel produkton-decidon estas honesta; skribi ĝin kiel kontrolon, ke tunelo ekzistas, ne estas.

La spegula peto, retrovi la veran adreson de la uzanto malantaŭ VPN, malsukcesas pro la sama kialo: unu konekto portas unu adreson, kaj ŝanĝo inter sesioj kongruas kun pluraj klarigoj. Traktu la antaŭan valoron kiel historion, ne kiel veron.