Tor relay na seva ya VPN: kwa nini haziwezi kubadilishana
Bandari iliyo wazi kwenye relay ya Tor si mwisho wa VPN. Kwanza angalia bandari inatumikia nini, jukumu la relay, wigo wa msikilizaji wa SOCKS na wasifu.
Una anwani, bandari inajibu, na mteja anaikubali bila malalamiko. Hakuna kati ya haya yanayofanya relay ya Tor kuwa mwisho wa VPN, na kosa ni ghali kwa sababu wasifu huingizwa kwa usafi na baadaye unashindwa kwenye kupeana mikono. Ninatumia ukaguzi nne hapa chini kwa mpangilio; kila mmoja una sharti la kusimama, na kusimama mapema ndilo jambo kuu. Ikiwa ukaguzi wa kwanza unashindwa, mengine hayawezi kukusaidia.
Angalia bandari inatumikia nini kwa kweli
Bandari iliyo wazi inathibitisha msikilizaji, si zaidi. ORPort ya relay huzungumza seli za Tor wenyewe baada ya kupeana mikono kwa TLS, kwa hivyo jaribio la TLS lililofanikiwa halikwambii karibu chochote kuhusu kama itifaki ya VPN inakubaliwa hapo:
nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null
Soma cheti badala ya ukweli kwamba kipo. Relay huwasilisha cheti kilichojisaini chenyewe chenye jina lisiloonekana kwa makusudi, kwa sababu trafiki ya relay inapaswa kufanana na HTTPS ya kawaida; cheti cha seva ya VPN hubeba jina ambalo wasifu wako unatarajia. Ikiwa upande wa pili hautawahi kujibu pakiti ya kwanza ya itifaki ya VPN, hakuna kiasi cha uhariri wa wasifu kitakachobadilisha matokeo.
Simama hapa ikiwa anwani haikamilishi kupeana mikono ambako mteja wako anatuma. Hilo ni jibu la itifaki, si tatizo la usanidi, na ndilo sababu ya kawaida zaidi kwa nini wasifu ulioingizwa hubaki kwenye 'connecting' milele.
Angalia jukumu la relay, si ukubwa wa mtandao
Majukumu ya relay hufanya kazi tofauti. Guard ni hatua ya kwanza kwa wateja, relay ya kati husambaza mizunguko kati ya relay nyingine, exit ndiyo inayogusa maeneo ya mwisho, na daraja ni sehemu ya kuingia isiyo ya umma inayogawiwa kupitia BridgeDB. Kamusi ya Tor huweka fasili hizo kando, na kufikiwa ni sehemu ya kila jukumu, ilhali ruhusa ya kuhudumia wateja holela si sehemu ya lolote kati ya hayo.
Sera ya exit inafaa kusomwa kwa sababu ni sehemu pekee inayofanana na kanuni ya kusambaza, na inasimamia maeneo ambayo exit itaruhusu kutoka, si wateja wanaoruhusiwa kuingia. Sera kali ya exit inayozuia bandari 25 inasema kitu kuhusu udhibiti wa matumizi mabaya ya kutoka, si kuhusu kama unaweza kuelekeza mteja wa OpenVPN kwenye mashine.
Simama ikiwa unabisha kutokana na sifa: kwa sababu relay husambaza trafiki, anwani lazima ikubali yako — hilo si kweli. Tor huchagua njia kupitia makubaliano na itifaki yake yenyewe; mteja wa VPN si mshiriki na hana mzunguko wa kujiunga nao.
Angalia kama msikilizaji wa SOCKS ni wa ndani au wa umma
Mteja wa Tor hufunua kiolesura cha SOCKS kwa programu kwenye mashine hiyo hiyo, kwa kawaida kwenye loopback. Msikilizaji huyo ni urahisi wa ndani, si huduma ambayo relay inaipa intaneti, na kuutendea kama proksi ya umma ndiyo njia ambayo watu huishia kuendesha relay iliyo wazi ambayo hawakukusudia:
ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org
Anwani ya kufunga ndiyo kidokezo. SocksPort kwenye 127.0.0.1:9050 inafanya kazi yake; inayosikiliza kwenye 0.0.0.0 na inafikiwa kutoka nje ni proksi iliyo wazi, na vidhibiti vya sera ya ufikiaji vya Tor wenyewe vipo kwa sababu hiyo kufichuka ni tatizo si kipengele.
Kwa programu inayohitaji Tor, ielekeze kwenye bandari ya loopback na uache Tor itatue majina, jambo ambalo umbo la socks5h hapo juu hufanya. Usibadilishe anwani ya relay kwa bandari hiyo; relay haitoi kiolesura ambacho programu yako inaomba.
Angalia kama wasifu wa VPN unalingana na mwisho halisi
Wasifu wa VPN ni kifungu cha matarajio: OpenVPN inahitaji cheti cha seva au CA, cheti cha mteja na ufunguo, na kwa kawaida ufunguo wa TLS, ilhali WireGuard inahitaji ufunguo wa umma wa upande wa pili, mwisho na IP zinazoruhusiwa. Hakuna kati ya haya kinachoweza kutolewa kutoka anwani na bandari iliyo wazi, ndiyo sababu wasifu uliojengwa hivyo unashindwa kwenye mabadilishano ya kwanza si wakati wa kuunganisha.
Unapopewa wasifu, uthibitishe kwa mwisho unaodhibiti au mtoa huduma unayoweza kumtambua:
wg show
openvpn --config client.ovpn --verb 4
Kwenye kumbukumbu ya OpenVPN, hitilafu ya mazungumzo ya TLS inataja kutolingana moja kwa moja; kwenye wg show, upande wa pili usio na mstari wa kupeana mikono haujawahi kukamilisha hata mmoja. Zote mbili zina habari zaidi kuliko kiashiria kinachozunguka cha mteja, na zote mbili zinaelekeza kwenye nyenzo za ufunguo au itifaki si Tor.
Angalia ni ulinzi upi unaouhitaji kwa kweli
Huu ndio ukaguzi unaoamua usanifu. Kivinjari cha Tor kinakupa utengano wa mizunguko na ulinzi dhidi ya alama za vidole ambao VPN haina; VPN hubadilisha anwani ambayo mwisho huiona na inakuthibitisha kwa mtoa huduma. Kuchagua kati ya hizi mbili ni swali la modeli ya vitisho, si la upatanishi, na kuzichanganya huzaa usanidi unaoonekana wa faragha na si hivyo.
Mnyororo una mpangilio. VPN inayobeba trafiki ya Tor ni mpangilio unaotumika, kwa sababu mteja wa Tor anahitaji TCP inayotoka tu. Mteja wa VPN aliyewekwa kwenye handaki ndani ya Tor si kitu kimoja na si kile ambacho mteja wa Tor hutekeleza, kwa hivyo usipange kwa msingi wa hilo.
Kabla ya kuagiza kitu chochote, thibitisha yote manne:
- Bandari inakamilisha kupeana mikono kwa itifaki yako, si muunganisho wa TCP pekee.
- Unajua jukumu la mwenyeji na hauchukui usambazaji kama ruhusa.
- Msikilizaji wa SOCKS unaotumia ni loopback na wako, si bandari ya umma kwenye relay ya mtu mwingine.
- Funguo au vyeti vya wasifu ni vya mwisho unaounganisha nao.