Releu Tor versus server VPN: de ce nu sunt interschimbabile

Aveți o adresă, portul răspunde, iar un client o acceptă fără nicio plângere. Nimic din toate acestea nu transformă un releu Tor într-un punct final VPN, iar greșeala este scumpă pentru că profilul se importă curat și eșuează mai târziu la handshake. Folosesc cele patru verificări de mai jos în ordine; fiecare are o condiție de oprire, iar oprirea devreme este exact ideea. Dacă prima verificare eșuează, restul nu vă pot ajuta.

Verificați ce deservește de fapt portul

Un port deschis dovedește un ascultător, nimic mai mult. ORPort-ul unui releu vorbește celulele proprii ale Tor după un handshake TLS, așa că o probă TLS reușită nu vă spune aproape nimic despre dacă acolo este acceptat un protocol VPN:

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

Citiți certificatul, nu faptul că există unul. Releele prezintă un certificat autosemnat cu un nume deliberat neobservabil, pentru că traficul releului trebuie să semene cu un HTTPS obișnuit; certificatul unui server VPN poartă numele pe care profilul dumneavoastră îl așteaptă. Dacă cealaltă parte nu răspunde niciodată la primul pachet al protocolului VPN, nicio editare a profilului nu va schimba rezultatul.

Opriți-vă aici dacă adresa nu finalizează handshake-ul pe care clientul dumneavoastră îl trimite. Acesta este un răspuns de protocol, nu o problemă de configurare, și este cel mai frecvent motiv pentru care un profil importat rămâne pe 'connecting' pentru totdeauna.

Verificați rolul releului, nu dimensiunea rețelei

Rolurile releului fac treburi diferite. Un guard este primul salt pentru clienți, un releu de mijloc transmite circuite între alte relee, un exit este cel care atinge destinațiile, iar un pod este un punct de intrare nepublic distribuit prin BridgeDB. Glosarul Tor ține aceste definiții separate, iar accesibilitatea face parte din fiecare rol, în timp ce permisiunea de a servi clienți arbitrari nu face parte din niciunul.

Politica de exit merită citită pentru că este singura parte care seamănă cu o regulă de redirecționare, și guvernează destinațiile pe care exitul le va permite spre exterior, nu clienții cărora li se permite intrarea. O politică de exit restrictivă care blochează portul 25 spune ceva despre controlul abuzului de ieșire, nu despre faptul că puteți îndrepta un client OpenVPN spre mașină.

Opriți-vă dacă raționați din reputație: pentru că releele transmit trafic, adresa trebuie să îl accepte pe al dumneavoastră. Tor alege căi prin consens și prin propriul protocol; un client VPN nu este participant și nu are un circuit la care să se alăture.

Verificați dacă ascultătorul SOCKS este local sau public

Clientul Tor expune o interfață SOCKS aplicațiilor de pe aceeași mașină, implicit pe loopback. Acel ascultător este o comoditate locală, nu un serviciu pe care un releu îl oferă internetului, iar tratarea lui ca proxy public este modul în care oamenii ajung să ruleze un releu deschis pe care nu îl intenționau:

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

Adresa de legare este indiciul. Un SocksPort pe 127.0.0.1:9050 își face treaba; unul care ascultă pe 0.0.0.0 și este accesibil din exterior este un proxy deschis, iar controalele de politică de acces ale Tor există exact pentru că acea expunere este o problemă, nu o caracteristică.

Pentru o aplicație care are nevoie de Tor, îndreptați-o spre portul loopback și lăsați Tor să rezolve numele, ceea ce face forma socks5h de mai sus. Nu înlocuiți adresa releului cu acel port; releul nu oferă interfața pe care o cere aplicația dumneavoastră.

Verificați că profilul VPN corespunde unui punct final real

Un profil VPN este un set de așteptări: OpenVPN are nevoie de certificatul serverului sau de CA, de un certificat de client și de o cheie, și de obicei de o cheie TLS, în timp ce WireGuard are nevoie de cheia publică a celeilalte părți, de un punct final și de IP-uri permise. Nimic din toate acestea nu poate fi derivat dintr-o adresă și un port deschis, motiv pentru care un profil construit astfel eșuează la primul schimb, nu la conectare.

Când vi se înmânează un profil, verificați-l față de un punct final pe care îl controlați sau față de un furnizor pe care îl puteți identifica:

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

În jurnalul OpenVPN, o eroare de negociere TLS numește direct nepotrivirea; în wg show, o parte fără linie de handshake nu a finalizat niciodată una. Ambele sunt mai informative decât indicatorul rotativ al clientului, și ambele indică materialul cheilor sau protocolul, nu Tor.

Verificați de ce protecție aveți nevoie de fapt

Aceasta este verificarea care decide arhitectura. Browserul Tor vă oferă izolarea circuitelor și apărare împotriva amprentelor pe care un VPN nu le are; un VPN schimbă adresa pe care o vede o destinație și vă autentifică la un furnizor. Alegerea între ele este o chestiune de model de amenințare, nu de compatibilitate, iar amestecarea lor produce o configurație care pare privată și nu este.

Înlănțuirea are o ordine. Un VPN care transportă trafic Tor este o aranjare acceptată, pentru că clientul Tor are nevoie doar de TCP de ieșire. Un client VPN tunelat în interiorul Tor nu este același lucru și nu este ceea ce implementează clientul Tor, așa că nu planificați pe baza asta.

Înainte să importați ceva, confirmați toate patru:

• Portul finalizează handshake-ul protocolului dumneavoastră, nu doar o conexiune TCP.
• Cunoașteți rolul gazdei și nu tratați redirecționarea ca permisiune.
• Ascultătorul SOCKS pe care îl folosiți este loopback și al dumneavoastră, nu un port public pe releul altcuiva.
• Cheile sau certificatele profilului aparțin punctului final la care vă conectați.