Tor-rele vastaan VPN-palvelin: miksi ne eivät ole vaihdettavissa

Sinulla on osoite, portti vastaa ja asiakas hyväksyy sen valittamatta. Mikään tästä ei tee Tor-releestä VPN-päätepistettä, ja virhe on kallis, koska profiili tuodaan siististi ja epäonnistuu myöhemmin kättelyssä. Käytän alla olevia neljää tarkistusta järjestyksessä; jokaisella on pysäytysehto, ja aikainen pysähtyminen on koko pointti. Jos ensimmäinen tarkistus epäonnistuu, muut eivät voi auttaa sinua.

Tarkista, mitä portti todella palvelee

Avoin portti todistaa kuuntelijan, ei muuta. Releen ORPort puhuu Torin omia soluja TLS-kättelyn jälkeen, joten onnistunut TLS-koetin ei kerro sinulle juuri mitään siitä, hyväksytäänkö siellä VPN-protokollaa:

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

Lue sertifikaatti sen sijaan, että todistaisit sen olemassaolon. Releet esittävät itseallekirjoitetun sertifikaatin tarkoituksellisen huomaamattomalla nimellä, koska releliikenteen on tarkoitus muistuttaa tavallista HTTPS:ää; VPN-palvelimen sertifikaatti kantaa nimeä, jota profiilisi odottaa. Jos vastapuoli ei koskaan vastaa VPN-protokollan ensimmäiseen pakettiin, mikään profiilin muokkaus ei muuta lopputulosta.

Pysähdy tähän, jos osoite ei suorita kättelyä, jonka asiakkaasi lähettää. Se on protokollan vastaus, ei kokoonpano-ongelma, ja se on yleisin syy siihen, että tuotu profiili jää ikuisesti tilaan 'connecting'.

Tarkista releen rooli, ei verkon kokoa

Releen roolit tekevät eri töitä. Guard on asiakkaiden ensimmäinen hyppy, keskirele välittää piirejä muiden releiden välillä, exit on se, joka koskettaa kohteita, ja silta on ei-julkinen sisäänkäynti, jota jaetaan BridgeDB:n kautta. Torin sanasto pitää nämä määritelmät erillään, ja tavoitettavuus on osa jokaista roolia, kun taas lupaa palvella mielivaltaisia asiakkaita ei ole osa mitään niistä.

Exit-käytäntö kannattaa lukea, koska se on ainoa osa, joka muistuttaa välityssääntöä, ja se säätelee kohteita, joihin exit sallii lähdön, ei asiakkaita, joita päästetään sisään. Portin 25 estävä rajoittava exit-käytäntö kertoo jotain lähtevän väärinkäytön valvonnasta, ei siitä, saako OpenVPN-asiakkaan osoittaa koneeseen.

Pysähdy, jos päättelet maineen perusteella: koska releet välittävät liikennettä, osoitteen on hyväksyttävä sinun. Tor valitsee polut konsensuksen ja oman protokollansa kautta; VPN-asiakas ei ole osallistuja eikä sillä ole piiriä, johon liittyä.

Tarkista, onko SOCKS-kuuntelija paikallinen vai julkinen

Torin asiakas tarjoaa SOCKS-rajapinnan saman koneen sovelluksille, oletuksena loopbackissa. Se kuuntelija on paikallinen mukavuus, ei palvelu, jota rele tarjoaa internetille, ja sen kohteleminen julkisena välityspalvelimena on tapa, jolla ihmiset päätyvät ajamaan avointa relettä, jota he eivät tarkoittaneet:

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

Sidontaosoite on vihje. SocksPort osoitteessa 127.0.0.1:9050 tekee työnsä; se, joka kuuntelee osoitteessa 0.0.0.0 ja on ulkopuolelta tavoitettavissa, on avoin välityspalvelin, ja Torin omat käyttöoikeuskäytännön valvonnat ovat olemassa juuri siksi, että tämä paljastuminen on ongelma eikä ominaisuus.

Jos sovellus tarvitsee Torin, osoita se loopback-porttiin ja anna Torin selvittää nimet, minkä yllä oleva muoto socks5h tekee. Älä korvaa releen osoitetta tällä portilla; rele ei tarjoa rajapintaa, jota sovelluksesi pyytää.

Tarkista, että VPN-profiili vastaa todellista päätepistettä

VPN-profiili on joukko odotuksia: OpenVPN tarvitsee palvelimen sertifikaatin tai CA:n, asiakassertifikaatin ja avaimen sekä yleensä TLS-avaimen, kun taas WireGuard tarvitsee vastapuolen julkisen avaimen, päätepisteen ja sallitut IP-osoitteet. Mitään näistä ei voi johtaa osoitteesta ja avoimesta portista, minkä vuoksi näin rakennettu profiili epäonnistuu ensimmäisessä vaihdossa, ei yhdistettäessä.

Kun sinulle annetaan profiili, vahvista se päätepistettä vasten, jota hallitset, tai palveluntarjoajaa vasten, jonka voit tunnistaa:

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

OpenVPN:n lokissa TLS-neuvotteluvirhe nimeää eroavuuden suoraan; wg show-tulosteessa vastapuoli, jolla ei ole kättelyriviä, ei ole koskaan saanut sellaista valmiiksi. Molemmat ovat valaisevampia kuin asiakkaan pyörivä ilmaisin, ja molemmat viittaavat avainmateriaaliin tai protokollaan, eivät Toriin.

Tarkista, mitä suojaa todella tarvitset

Tämä tarkistus ratkaisee arkkitehtuurin. Tor Browser antaa sinulle piirieristyksen ja sormenjälkien vastaiset suojaukset, joita VPN ei anna; VPN muuttaa osoitetta, jonka kohde näkee, ja todentaa sinut palveluntarjoajalle. Niiden välillä valitseminen on uhkamallikysymys, ei yhteensopivuuskysymys, ja niiden sekoittaminen tuottaa asetelman, joka näyttää yksityiseltä eikä ole sitä.

Ketjutuksella on järjestys. Tor-liikennettä kantava VPN on tuettu järjestely, koska Torin asiakas tarvitsee vain lähtevän TCP:n. Torin sisään tunnelioitu VPN-asiakas ei ole sama asia eikä se, mitä Tor-asiakas toteuttaa, joten älä suunnittele sen varaan.

Ennen kuin tuot mitään, vahvista kaikki neljä:

• Portti suorittaa protokollasi kättelyn, ei vain TCP-yhteyttä.
• Tunnet isännän roolin etkä pidä välitystä lupana.
• Käyttämäsi SOCKS-kuuntelija on loopback ja sinun, ei julkinen portti jonkun toisen releessä.
• Profiilin avaimet tai sertifikaatit kuuluvat päätepisteelle, johon yhdistät.