Tor реле наспроти VPN сервер: зошто не се заменливи

Имате адреса, портот одговара и клиент го прифаќа без никаква жалба. Ништо од тоа не го прави Tor релето VPN крајна точка, а грешката е скапа бидејќи профилот се увезува чисто и подоцна пропаѓа при ракувањето. Ги користам четирите проверки подолу по редослед; секоја има услов за запирање, а раното запирање е смислата. Ако првата проверка пропадне, останатите не можат да ви помогнат.

Проверете што всушност опслужува портот

Отворениот порт докажува слушател, ништо повеќе. ORPort на релето зборува со сопствените ќелии на Tor по TLS ракување, затоа успешна TLS проверка речиси ништо не ви кажува за тоа дали таму се прифаќа VPN протокол:

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

Читајте го сертификатот, а не фактот дека постои. Релеата прикажуваат самопотпишан сертификат со намерно невпечатливо име, бидејќи сообраќајот на релето треба да личи на обичен HTTPS; сертификатот на VPN серверот го носи името што го очекува вашиот профил. Ако спротивната страна никогаш не одговори на првиот пакет на VPN протоколот, никакво уредување на профилот нема да го промени исходот.

Запрете тука ако адресата не го заврши ракувањето што го испраќа вашиот клиент. Тоа е одговор на протоколот, не проблем со конфигурацијата, и тоа е најчестата причина зошто увезен профил засекогаш останува на 'connecting'.

Проверете ја улогата на релето, не големината на мрежата

Улогите на релето вршат различна работа. Guard е првиот скок за клиентите, средното реле проследува кругови меѓу други релеа, exit е тоа што допира одредишта, а мост е нејавна влезна точка што се дели преку BridgeDB. Речникот на Tor ги држи тие дефиниции одвоени, а достапноста е дел од секоја улога, додека дозволата да служи произволни клиенти не е дел од ниту една од нив.

Exit политиката вреди да се прочита бидејќи е единствениот дел што личи на правило за проследување, и таа ги уредува одредиштата на кои exit ќе дозволи излез, а не клиентите на кои им е дозволен влез. Рестриктивна exit политика што го блокира портот 25 кажува нешто за контролата на излезната злоупотреба, а не за тоа дали можете да насочите OpenVPN клиент кон машината.

Запрете ако заклучувате од репутација: бидејќи релеата проследуваат сообраќај, адресата мора да го прифати вашиот. Tor избира патеки преку консензус и сопствениот протокол; VPN клиентот не е учесник и нема круг за да се приклучи.

Проверете дали SOCKS слушателот е локален или јавен

Клиентот на Tor открива SOCKS интерфејс за апликациите на истата машина, стандардно на loopback. Тој слушател е локална погодност, не услуга што релето ја нуди на интернетот, и неговото третирање како јавен прокси е начинот на кој луѓето завршуваат со отворено реле што не го имале намера:

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

Адресата на сврзување е показателот. SocksPort на 127.0.0.1:9050 ја врши својата работа; тој што слуша на 0.0.0.0 и е достапен однадвор е отворен прокси, а сопствените контроли на политиката за пристап на Tor постојат токму затоа што таа изложеност е проблем, а не функција.

За апликација што бара Tor, насочете ја кон loopback портот и оставете Tor да решава имиња, што го прави формата socks5h погоре. Не заменувајте ја адресата на релето со тој порт; релето не го нуди интерфејсот што го бара вашата апликација.

Проверете дека VPN профилот одговара на вистинска крајна точка

VPN профилот е збир на очекувања: OpenVPN бара сертификат на серверот или CA, клиентски сертификат и клуч, и обично TLS клуч, додека WireGuard бара јавниот клуч на спротивната страна, крајна точка и дозволени IP адреси. Ништо од тоа не може да се изведе од адреса и отворен порт, затоа вака изграден профил пропаѓа при првата размена, а не при поврзувањето.

Кога ви предаваат профил, проверете го спрема крајна точка што ја контролирате или давател што можете да го препознаете:

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

Во дневникот на OpenVPN, грешката при TLS преговори директно го именува несогласувањето; во wg show, спротивната страна без линија за ракување никогаш не завршила ниту една. Двете се поинформативни од ротирачкиот показател на клиентот, и двете укажуваат на клучен материјал или протокол, а не на Tor.

Проверете каква заштита всушност ви треба

Ова е проверката што ја одлучува архитектурата. Tor Browser ви дава изолација на кругови и одбрана од отпечатоци што VPN не ја дава; VPN ја менува адресата што ја гледа одредиштето и ве автентификува кај давател. Изборот меѓу нив е прашање на модел на закана, не на компатибилност, а нивното мешање создава поставка што изгледа приватна и не е.

Верижното поврзување има редослед. VPN што носи Tor сообраќај е поддржано уредување, бидејќи клиентот на Tor бара само излезен TCP. VPN клиент тунелиран внатре во Tor не е истото и не е она што го спроведува Tor клиентот, затоа не планирајте врз основа на тоа.

Пред да увезете нешто, потврдете ги сите четири:

• Портот го завршува ракувањето на вашиот протокол, не само TCP врска.
• Ја знаете улогата на домаќинот и не го сметате проследувањето за дозвола.
• SOCKS слушателот што го користите е loopback и ваш, а не јавен порт на туѓо реле.
• Клучевите или сертификатите на профилот му припаѓаат на крајната точка со која се поврзувате.