Teil on aadress, port vastab ja klient võtab selle vastu ilma kaebusteta. Miski sellest ei tee Tor-relaisist VPN-i lõpp-punkti ja viga on kallis, sest profiil imporditakse puhtalt ja ebaõnnestub hiljem käepigistuse juures. Ma kasutan nelja allpool olevat kontrolli järjekorras; igaühel on pysäytysehto ja varakult peatamine ongi mõte. Kui esimene kontroll ebaõnnestub, ei aita ülejäänud teid.

Kontrollige, mida port tegelikult teenindab

Avatud port tõestab kuulajat, mitte enamat. Relaisi ORPort räägib pärast TLS-i käepigistust Tori enda rakkudega, seega õnnestunud TLS-kontroll ei ütle teile peaaegu midagi selle kohta, kas seal VPN-protokolli vastu võetakse:

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

Lugege sertifikaati, mitte tõsiasja, et see olemas on. Relaisid esitavad iseallkirjastatud sertifikaadi tahtlikult märkamatu nimega, sest relaisi liiklus peab sarnanema tavalise HTTPS-iga; VPN-serveri sertifikaat kannab nime, mida teie profiil ootab. Kui vastaspool ei vasta kunagi VPN-protokolli esimesele paketile, ei muuda profiili redigeerimine tulemust.

Peatuge siin, kui aadress ei lõpeta käepigistust, mille teie klient saadab. See on protokolli vastus, mitte konfiguratsiooniprobleem, ja see on kõige tavalisem põhjus, miks imporditud profiil jääb igavesti olekusse 'connecting'.

Kontrollige relaisi rolli, mitte võrgu suurust

Relaisi rollid teevad erinevat tööd. Guard on klientide jaoks esimene hüpe, keskmine relais edastab ahelaid teiste relaiside vahel, exit on see, mis puudutab sihtkohti, ja sild on mitteavalik sisenemispunkt, mida jagatakse BridgeDB kaudu. Tori sõnastik hoiab need määratlused lahus ning kättesaadavus on iga rolli osa, samas kui luba teenindada suvalisi kliente ei ole ühegi rolli osa.

Exit-poliitikat tasub lugeda, sest see on ainus osa, mis meenutab edastusreeglit, ja see juhib sihtkohti, kuhu exit välja lubab, mitte kliente, keda sisse lastakse. Piirav exit-poliitika, mis blokeerib pordi 25, ütleb midagi väljuva kuritarvitamise kontrolli kohta, mitte selle kohta, kas tohib suunata OpenVPN-kliendi masina poole.

Peatuge, kui arutlete maine põhjal: kuna relaisid edastavad liiklust, peab aadress teie oma vastu võtma. Tor valib teid konsensuse ja oma protokolli kaudu; VPN-klient ei ole osaleja ja tal ei ole ahelat, millega liituda.

Kontrollige, kas SOCKS-kuulaja on kohalik või avalik

Tori klient pakub SOCKS-liidest samas masinas olevatele rakendustele, vaikimisi loopbackil. See kuulaja on kohalik mugavus, mitte teenus, mida relais internetile pakub, ja selle kohtlemine avaliku puhverserverina on viis, kuidas inimesed jõuavad avatud relaisini, mida nad ei kavatsenud käitada:

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

Sidumisaadress on vihje. SocksPort aadressil 127.0.0.1:9050 teeb oma tööd; see, mis kuulab aadressil 0.0.0.0 ja on väljast kättesaadav, on avatud puhverserver, ja Tori enda juurdepääsupoliitika kontrollid on olemas just seetõttu, et see paljastus on probleem, mitte funktsioon.

Rakendusele, mis vajab Tori, suunake see loopback-pordile ja laske Toril nimesid lahendada, mida ülalolev vorm socks5h teeb. Ärge asendage relaisi aadressi selle pordiga; relais ei paku liidest, mida teie rakendus küsib.

Kontrollige, et VPN-profiil vastab tõelisele lõpp-punktile

VPN-profiil on hulk ootusi: OpenVPN vajab serveri sertifikaati või CA-d, kliendi sertifikaati ja võtit ning tavaliselt TLS-võtit, samas kui WireGuard vajab vastaspoole avalikku võtit, lõpp-punkti ja lubatud IP-sid. Midagi sellest ei saa tuletada aadressist ja avatud pordist, mistõttu nii ehitatud profiil ebaõnnestub esimesel vahetusel, mitte ühendamisel.

Kui teile antakse profiil, kontrollige seda lõpp-punkti vastu, mida te kontrollite, või teenusepakkuja vastu, keda suudate tuvastada:

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

OpenVPN-i logis nimetab TLS-i läbirääkimise viga lahknevuse otse; wg show väljundis ei ole käepigistuse reata vastaspool kunagi ühtegi lõpetanud. Mõlemad on informatiivsemad kui kliendi pöörlev indikaator, ja mõlemad viitavad võtmematerjalile või protokollile, mitte Torile.

Kontrollige, millist kaitset te tegelikult vajate

See on kontroll, mis otsustab arhitektuuri. Tor Browser annab teile ahela isolatsiooni ja sõrmejälgede kaitse, mida VPN ei anna; VPN muudab aadressi, mida sihtkoht näeb, ja autendib teid teenusepakkuja juures. Nende vahel valimine on ohu mudeli küsimus, mitte ühilduvuse küsimus, ja nende segamine annab seadistuse, mis näeb privaatne välja ja ei ole seda.

Aheldumisel on järjekord. Tori liiklust kandev VPN on toetatud lahendus, sest Tori kliendil on vaja ainult väljuvat TCP-d. Tori sees tunnelisse pandud VPN-klient ei ole sama asi ja ei ole see, mida Tori klient rakendab, seega ärge sellele planeerige.

Enne kui midagi impordite, kinnitage kõik neli:

  • Port lõpetab teie protokolli käepigistuse, mitte ainult TCP-ühenduse.
  • Teate hosti rolli ega käsitle edastamist loana.
  • Kasutatav SOCKS-kuulaja on loopback ja teie oma, mitte avalik port kellegi teise relaisil.
  • Profiili võtmed või sertifikaadid kuuluvad lõpp-punktile, millega ühendute.

Seotud artiklid