Ang exit IP ng VPN ay hindi patunay ng tunnel: ano ang nakikita ng mga server

May humihingi ng serbisyong maaabot lamang ng mga gumagamit ng VPN, at ang halatang implementasyon ay payagan ang isang listahan ng mga exit address. May ginagawang totoo ang listahan: nililimitahan nito kung sino ang maaaring kumonekta. Hindi nito pinapatunayan na ginamit ang isang tunnel, dahil pag-aari ng nagpapatakbo ng exit ang address, at maaaring ipasa ng operator na iyon ang trapiko ng kahit sino. Ang agwat sa pagitan ng mga pahayag na iyon ay ang buong problema sa disenyo.

Isang address kada koneksyon ang nakikita ng server

Dumating ang koneksyon na may source address at destination port, at iyon lang ang iniuulat ng network layer. Kapag gumamit ng tunnel ang isang kliyente, ang mga packet na umabot sa iyong listener ay galing sa exit o sa pagsasalin sa harap nito. Ang sariling address ng kliyente, karaniwang pribado, ay hindi kailanman lumilitaw. Kaya ang tuntunin ng firewall na isinulat para sa LAN range ng kliyente ay walang ginagawa.

Lahat ng sumusunod sa source address na iyon ay data ng application, at mapagkakatiwalaan lamang ito ng application hanggang sa naa-authenticate nito.

Subukan kung ano ang hitsura ng iyong exit

Tingnan ang landas mula sa dalawang dulo bago magsulat ng tuntunin. Ang pananaw ng kliyente sa sariling exit at ang pananaw ng server sa koneksyon ang dalawang katotohanang mahalaga.

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

Iniuulat ng unang utos ang pampublikong address kung saan lumilitaw ang kliyente, at iyon ang halagang dapat taglayin ng anumang listahan ng pinapayagan. Ipinapakita ng pangalawa ang mga naitatag na koneksyon sa server kasama ang mga address ng kanilang kapares, at iyon ang tunay na tutugmaan ng tuntunin. Kung hindi tumutugma ang dalawa sa iyong mental na modelo, ayusin ang modelo bago i-edit ang patakaran. Ang firewall ng cloud database, listahan ng pinapayagan ng application at load balancer ay maaaring bawat isa ay makakita ng ibang layer ng pagsasalin.

Isa lamang sa dalawang set ng exit ang maaaring ilista

Ang isang kaso ay masusuri sa sandali ng kahilingan at ang isa ay hindi, na nagbubunga ng lubos na magkaibang garantiya.

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

Ang nailathalang listahan ng exit ng Tor ay makukuha at maihahambing, depende sa edad ng listahan at sariling patakaran ng bawat exit, kaya ang tuntunin ng pagtanggi laban sa mga kilalang exit ay maipapatupad at masusuri. Walang katumbas na rehistro para sa mga komersyal na VPN. Umiikot ang mga address, maraming provider ay walang inilalathala, at ang isang tunnel ay maaaring tumakbo sa inupahang cloud address na hindi kailanman naging pag-aari ng VPN. Ang listahang binubuo mo ay isang larawan ng mga naobserbahang address, at ang pagpapalawak nito sa mga hosting range ay nagdaragdag ng walang kaugnayang workload nang walang idinadagdag na patunay.

Gamitin ang mga address bilang input ng patakaran, hindi bilang patunay

Magpasya kung para saan ang tuntunin. Dapat manatiling makitid ang paghihigpit sa network, itala ang naobserbahang address kasama ang petsa at dahilan, at bigyan ang mga lehitimong gumagamit ng landas ng pagbawi kapag nagbago ang kanilang exit. Kailangan ng access control ang na-authenticate na account o nilagdaang token, dahil ang mga iyon lamang ang nagbibigkis ng kahilingan sa pagkakakilanlan. Maaaring gamitin ng risk scoring ang address bilang isang hindi mapagkakatiwalaang senyales, tinatanggap ang mga maling positibo at butas nito. Ang isulat ang tuntunin bilang desisyon ng produkto ay tapat; ang isulat ito bilang beripikasyon na may tunnel ay hindi.

Ang kahilingang salamin, ang bawiin ang tunay na address ng gumagamit sa likod ng VPN, ay nabigo sa parehong dahilan: isang koneksyon ang nagdadala ng isang address, at ang pagbabago sa pagitan ng mga session ay tugma sa ilang paliwanag. Ituring ang dating halaga bilang kasaysayan, hindi bilang katotohanan.