Релей на Tor срещу VPN сървър: защо не са взаимозаменяеми

Отворен порт на релей на Tor не е VPN крайна точка. Първо проверете какво обслужва портът, ролята на релея, обхвата на SOCKS слушателя и профила.

Имате адрес, портът отговаря и клиент го приема без оплакване. Нищо от това не прави релея на 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 ще позволи изход, а не клиентите, които се допускат вътре. Ограничителна изходна политика, която блокира порт 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 и ваш, а не публичен порт на чужд релей.
  • Ключовете или сертификатите на профила принадлежат на крайната точка, към която се свързвате.

Подобни статии