Tor relay laban sa VPN server: bakit hindi sila mapagpapalit

Mayroon kang address, sumasagot ang port, at tinatanggap ito ng kliyente nang walang reklamo. Wala sa mga ito ang gumagawa sa isang Tor relay na endpoint ng VPN, at mahal ang pagkakamali dahil malinis na na-import ang profile at nabigo lamang mamaya sa handshake. Ginagamit ko ang apat na pagsusuri sa ibaba nang sunod-sunod; bawat isa ay may kondisyon ng pagtigil, at ang maagang pagtigil ang buong punto. Kung mabibigo ang unang pagsusuri, hindi ka matutulungan ng iba.

Suriin kung ano talaga ang pinaglilingkuran ng port

Ang bukas na port ay nagpapatunay ng isang tagapakinig, wala nang iba. Ang ORPort ng isang relay ay nagsasalita ng sariling mga cell ng Tor pagkatapos ng TLS handshake, kaya ang matagumpay na pagsusuri ng TLS ay halos walang sinasabi tungkol sa kung tinatanggap doon ang isang protocol ng VPN:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Basahin ang certificate at hindi ang katotohanang mayroon nito. Nagpapakita ang mga relay ng self-signed na certificate na may sadyang hindi kapansin-pansing pangalan, dahil ang trapiko ng relay ay dapat magmukhang ordinaryong HTTPS; ang certificate ng isang VPN server ay may dalang pangalan na inaasahan ng iyong profile. Kung hindi kailanman sasagot ang kabilang panig sa unang packet ng protocol ng VPN, walang pag-edit ng profile ang makakapagpabago ng resulta.

Huminto dito kung hindi kinukumpleto ng address ang handshake na ipinapadala ng iyong kliyente. Sagot iyon ng protocol, hindi problema sa configuration, at ito ang pinakakaraniwang dahilan kung bakit ang na-import na profile ay nananatiling nasa 'connecting' magpakailanman.

Suriin ang papel ng relay, hindi ang laki ng network

Iba't ibang gawain ang ginagawa ng mga papel ng relay. Ang guard ang unang hakbang para sa mga kliyente, ang gitnang relay ay nagpapasa ng mga circuit sa pagitan ng iba pang relay, ang exit ang humahawak sa mga destinasyon, at ang tulay ay isang hindi pampublikong pasukan na ipinamamahagi sa pamamagitan ng BridgeDB. Pinananatiling hiwalay ng glosaryo ng Tor ang mga kahulugang iyon, at ang pagiging maabot ay bahagi ng bawat papel habang ang pahintulot na maglingkod sa di-makatwirang kliyente ay hindi bahagi ng alinman sa kanila.

Ang patakaran sa exit ay sulit basahin dahil ito lamang ang bahaging kahawig ng patakaran sa pagpapasa, at pinamamahalaan nito ang mga destinasyong papayagan ng exit na lumabas, hindi ang mga kliyenteng papayagang pumasok. Ang mahigpit na patakaran sa exit na humaharang sa port 25 ay may sinasabi tungkol sa kontrol ng pang-aabuso sa labas, hindi tungkol sa kung maaari mong ituro ang isang OpenVPN client sa makina.

Huminto kung nagmamatuwid ka mula sa reputasyon: dahil nagpapasa ng trapiko ang mga relay, dapat tanggapin ng address ang sa iyo, ngunit hindi iyon totoo. Pinipili ng Tor ang mga landas sa pamamagitan ng consensus at sariling protocol; ang VPN client ay hindi kalahok at walang circuit na pagsasamahan.

Suriin kung lokal o pampubliko ang SOCKS listener

Inilalantad ng kliyente ng Tor ang isang SOCKS interface sa mga application sa parehong makina, bilang default sa loopback. Ang tagapakinig na iyon ay lokal na kaginhawahan, hindi serbisyong iniaalok ng relay sa internet, at ang pagtrato dito bilang pampublikong proxy ang paraan kung paano nauuwi ang mga tao sa pagpapatakbo ng bukas na relay na hindi nila sinasadya:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

Ang bind address ang senyales. Ang SocksPort sa 127.0.0.1:9050 ay gumagawa ng trabaho nito; ang nakikinig sa 0.0.0.0 at naaabot mula sa labas ay bukas na proxy, at ang sariling mga kontrol ng patakaran sa access ng Tor ay umiiral dahil problema ang pagkakalantad na iyon at hindi katangian.

Para sa application na nangangailangan ng Tor, ituro ito sa loopback port at hayaan ang Tor ang mag-resolba ng mga pangalan, na siyang ginagawa ng anyo ng socks5h sa itaas. Huwag palitan ng address ng relay ang port na iyon; hindi iniaalok ng relay ang interface na hinihiling ng iyong application.

Suriin na tumutugma ang profile ng VPN sa tunay na endpoint

Ang profile ng VPN ay isang bigkis ng mga inaasahan: kailangan ng OpenVPN ang certificate ng server o CA, isang certificate at key ng kliyente, at karaniwang isang TLS key, samantalang kailangan ng WireGuard ang public key ng kabilang panig, isang endpoint at mga pinapayagang IP. Wala sa mga ito ang makukuha mula sa isang address at bukas na port, kaya ang profile na ginawa nang ganoon ay nabigo sa unang pagpapalitan at hindi sa pagkonekta.

Kapag may nag-abot sa iyo ng profile, i-verify ito laban sa endpoint na kinokontrol mo o provider na makikilala mo:

wg show
openvpn --config client.ovpn --verb 4

Sa log ng OpenVPN, direktang pinapangalanan ng error sa TLS negotiation ang hindi pagtutugma; sa wg show, ang kabilang panig na walang linya ng handshake ay hindi kailanman nakakumpleto ng isa. Pareho silang mas nagbibigay-kaalaman kaysa sa umiikot na indicator ng kliyente, at pareho silang tumuturo sa materyal ng key o protocol at hindi sa Tor.

Suriin kung aling proteksyon ang talagang kailangan mo

Ito ang pagsusuring nagpapasya sa arkitektura. Binibigyan ka ng Tor Browser ng paghihiwalay ng circuit at pagtatanggol laban sa fingerprint na wala ang VPN; binabago ng VPN ang address na nakikita ng destinasyon at pinapatunay ka sa isang provider. Ang pagpili sa pagitan nila ay usapin ng modelo ng banta, hindi ng pagiging tugma, at ang pagsasama-sama nila ay gumagawa ng setup na mukhang pribado at hindi naman.

May pagkakasunod-sunod ang pagkakadena. Ang VPN na nagdadala ng trapiko ng Tor ay sinusuportahang kaayusan, dahil ang kliyente ng Tor ay nangangailangan lamang ng palabas na TCP. Ang VPN client na naka-tunnel sa loob ng Tor ay hindi pareho at hindi ang ipinapatupad ng Tor client, kaya huwag magplano batay doon.

Bago mag-import ng kahit ano, tiyakin ang apat:

• Kinukumpleto ng port ang handshake ng iyong protocol, hindi lamang koneksyon ng TCP.
• Alam mo ang papel ng host at hindi mo itinuturing na pahintulot ang pagpapasa.
• Ang SOCKS listener na ginagamit mo ay loopback at sa iyo, hindi pampublikong port sa relay ng iba.
• Ang mga key o certificate ng profile ay pag-aari ng endpoint na kinokonektahan mo.