All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Tutorial: Configuring fast VPN exiting multiple Tor instances
Short intro
Using VPN is an important part of nowadays privacy and blindly trusting even most recognized VPN providers may still represent some risks.
People who already know that, prefer making and using their own solutions, such as buying VPS or dedicated servers and building VPN.
Using Tor as a VPN exit point is a widely used scheme known for its anonimity benefits, but it can be achieved by different ways and each of them has different level of performance. I will quickly show the fastest one that I am very happy with.
Software and technology used
OpenVPN, Tor, HAProxy, transocks_ev or redsocks, Unbound, DNSCrypt.
Clients are connected to the OpenVPN instance and their default gateway is set to the OpenVPN server address. Their connections to the clearnet are transparently redirected to the Haproxy instance and balanced through several Tor instances afterwards, because using one Tor instance for that is a proven bad practice for achieving performance.
Connections that are made to .onion services are not load-balanced as this requires packet mangling and more advanced configuration, for now we will keep it simple.
Thus, basically the scheme is:
I will omit OpenVPN instance configuration here and my reasons are:
it doesn't matter which tunneling software is used, you may prefer WireGuard or any other modern software to OpenVPN
there are plenty of HOW-TO's exist already that can be found on Duckduckgo
less unnecessary information in the article
As for transparent TCP->Socks5 redirector I use transocks_ev, because the current version of redsocks has some issues with recent versions of libevent and they remain unfixed.
However, I will demonstrate examples for both, transocks and redsocks, so it's up to you which one to use.
Initial configuration
To avoid confusion in this article I decided to put all required daemons listening on 127.0.0.1. In practice you might create a separate loopback interface, because linux considers a packet as 'martian' when its destination is 127.0.0.1.
The following kernel parameters are needed to get everything working:
net.ipv4.ip_forward=1
# enable packet forwarding
net.ipv4.conf.all.route_localnet=1
# this is only needed to permit routing packets to 127.0.0.1
Our VPN clients range: 10.11.1.0/24
Configuring Tor
We will make 2 groups of Tor instances:
1. One for resolving, mapping and accessing .onion domains.
# DNS port for resolving and mapping .onion domains to VirtualAddrNetworkIPv4 range
DNSPort 127.0.0.1:5301
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
# TransPort is needed for transparent redirection
TransPort 127.0.0.1:9041
You may use that with your system's default Tor instance, whose usual config location is /etc/tor/torrc
Several instances for making clearnet connections through Tor exits.
I am using a cron script for bringing them up when they are not running.!/bin/bash
TORBINARY=/usr/bin/tor
BASEDIR=/tmp/.tor-nodes # you must change this to a more secure location
PORTS=(9070 9071 9072 9073 9074 9075) # Socks5 ports to listen. A quantity of ports here defines the quantity of Tor instancesif [ ! -d "$BASEDIR" ]; then
mkdir $BASEDIR
fifor port in ${PORTS[]}
do
IS_RUNNING=$(netstat -tlpn 2>/dev/null | awk '{print $4}' | sed 's/^./' | grep "^$port\$")
if [ ! $IS_RUNNING ]; then
$TORBINARY -f /dev/null --allow-missing-torrc --defaults-torrc /dev/null --DataDirectory $BASEDIR/$port --SocksPort $port > /dev/null 2>&1 &
fi
done
Configuring Haproxy
global
daemon
maxconn 2048
defaults
timeout connect 3000ms
timeout client 0ms
timeout server 0ms
frontend rotatingproxies
mode tcp
# the IP:port Haproxy will listen on
bind 127.0.0.1:9999
default_backend torproxies
backend torproxies
mode tcp
option persist
# you should put all the ports defined in $PORTS array from
# the cron script we discussed in the previous section
server tor1 127.0.0.1:9070 check
server tor2 127.0.0.1:9071 check
server tor3 127.0.0.1:9072 check
server tor4 127.0.0.1:9073 check
server tor5 127.0.0.1:9074 check
server tor6 127.0.0.1:9075 check
Configuring transocks and redsocks
Either piece of software will "transform" our clients clearnet TCP traffic into Socks5 requests and redirect them to Haproxy.
I am using 'transocks_ev' (http://oss.tiggerswelt.net/transocks_ev/) fork instead of transocks due to livevent and updated code.
libevent library is required for it.
Get & compile it with:
git clone https://github.com/tiernano/transocks_ev ; cd transocks_ev ; make
Now just make another cron script for it and add to cron:
#!/bin/bash
TRANSOCKS_DIR="/opt/transocks" # you should define your own here
PROCTEST=$(pgrep -f transocks_ev)
if [ -z "$PROCTEST" ]; then
$TRANSOCKS_DIR/transocks_ev -H 127.0.0.1 -p 9035 -S 127.0.0.1 -s 9999
fi
It will now listen on 127.0.0.1:9035
for TCP connections. We still need to point all our clients to that port and iptables rules will be discussed at the end of this tutorial.
Now, as I promised, the alternative config for redsocks with the same function:
base {
log_debug = off;
log_info = off;
daemon = on;
user = redsocks;
group = redsocks;
redirector = iptables;
}
redsocks {
local_ip = 127.0.0.1;
local_port = 9035;
ip = 127.0.0.1;
port = 9999; // haproxy
type = socks5;
}
Configuring DNSCrypt
Tor's DNSPort is able to resolve all the clearnet requests as well, but it is very slow and gives significant decrease in performance.
DNSCrypt is a compromise between security and performance, though providers for our DNS requests should be selected carefully, because some of them may store logs.
Full list of them can be found on (https://dnscrypt.info/public-servers), alternatively, you may host a DNSCrypt server by yourself.
ResolverName bn-nl0
ResolverName d0wn-nl-ns4
ResolverName scaleway-fr
Daemonize yes
# DNSCrypt will listen on this port
LocalAddress 127.0.0.1:5399
Configuring Unbound
Unbound will listen on 127.0.0.1:53
and act as a router for domain names.
.onion domains will be resolved by our main Tor instance, that is listening on 127.0.0.1:5301
.
Everything else will be resolved through dnscrypt-proxy.
server:
access-control: 10.0.0.0/8 allow
access-control: 127.0.0.0/8 allow
access-control: 192.168.0.0/16 allow
cache-max-ttl: 14400
cache-min-ttl: 900
hide-identity: yes
hide-version: yes
interface: 127.0.0.1 # Unbound will listen as a DNS resolver on the port 53
minimal-responses: yes
prefetch: yes
rrset-roundrobin: yes
use-caps-for-id: yes
verbosity: 0
do-not-query-localhost: no
local-zone: "onion." nodefault
local-zone: "." nodefault
forward-zone:
name: "onion"
forward-addr: 127.0.0.1@5301 # this is our main Tor DNSPort
forward-first: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5399 # this is our dnscrypt-proxy instance port
Glue everything together with iptables
Now, everything we have configured above won't work without proper iptables rules.
Firstly, add a rule that redirects all outbound UDP requests made by clients to port 53 to Unbound's 53.
-A PREROUTING -i tun0 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
.onion resolved domains will be mapped to 10.192.0.0/10 range, thus we redirect this range to our main Tor instance
-A PREROUTING -d 10.192.0.0/10 -i tun0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DNAT --to-destination 127.0.0.1:9041
The restant clearnet connections will be redirected to transocks or redsocks.
-A PREROUTING -i tun0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DNAT --to-destination 127.0.0.1:9035
It's everything and your ultra-fast VPN should be working now. Sorry if I have disappointed you because you were expecting 100500 lines of boring configurations, along with examples using a 'sudo' command.
Bottom line
I am using this configuration for 2 years already and it has become best for me among many other configurations I've been using in the past.
Please share your own practice and experience as I am very eager to learn other ways of realizing this task.
This tutorial is special for LET.
Comments
Here is a cron script for making several Tor instances because its markup got wrecked in the article:
Now make this into single .sh installer and I'll buy several Ubuntu 16.04 servers with bitcoins and VPN.
Sounds like you have a plan stefeman
In all seriousness, that's one super-detailed, clear tutorial. Well done, and consider creating a step-by-step video, maybe post on Youtube for more people to see.
Please explain why using Tor is not a privacy/security risk. All plain non encrypted traffic can be read by the exit node operator. There is many articles about that, google that. Thank you for spending your time sharing this useful tutorial.
Maybe because by now there's little to no non-encrypted traffic with any importance to privacy left. Everything where it mattered (and more), all went HTTPS.
That's exactly it. You can run transparent proxy on the exit node and inject your own malicious JavaScript, or just pcap all traffic.
Many sites still don't use HTTPS.
Thank you for raising a such important question. In some use cases it certainly is, but I had in mind the audience who already consider such security risks, providing only technical information in the article.
However, this question is quite relative and already invoked many heated discussions on the popular 'to Tor or not to Tor' threads among the Internet, at least because all plain non-encrypted traffic can be also read by your ISP, VPN or VPS provider, and there is no guarantee that all this data won't be used maliciously.
I'd still prefer exiting non-encrypted connections from a Tor node, because malicious ones are quickly excluded from the Tor public directory servers.
In addition, decent browsers such as Firefox or Chromium provide very informative notifications about the risks on accessing plain http sites, so the only thing left to do is turn healthy consciousness on and start making right decisions.
Most of the important sites use HTTPS, as @postcd already said.
@ralph THANK YOU SIR!
If you are really brave why not just have your WiFi as an open access point and let all the pedos and Russian hackers just use your net directly? Seems as good an idea as any.
VPN, TOR, ...
just makes you more suspicious.
Privacy gained=0 (zero).
Suspicion gained=100 (one hundred).
Not to resurrect a dead thread; but, as a beginner who understands enough to follow this post I'd be interested in what people think about this issue nowadays? Is using Tor with a VPN a bad/good idea?
The value of privacy enhancing technologies depends on what you consider a threat and how you use them.
In some situations and locations, using such technologies can make you a target.
In other situations where using them is appropriate, you must understand how to use them properly. Improper use may be worse than not using them at all.
Is using TOR with a VPN a good or bad idea?
My answer: It depends. What threat are you concerned about? How will you use a VPN'd TOR connection? How will it mitigate that threat?
Using VPN is good idea than plain connection. Then on top of that using Tor is also good idea in some cases when you really need to extra protect your identity (be anonymous). I was helping translate ProtonVPN recently ( https://crowdin.com/profile/pmtranslator ) so i know they have Tor enabled VPN servers where you can enable Tor on their VPN using single click. That would be useful for the people who do not want to spend time setting up their own server, Tor etc..
A good discussion on Tor/VPN:
https://security.stackexchange.com/questions/64583/vpn-tor-go-to-jail-whats-the-logic-behind-this
I see several solutions and recommendations (e.g., VPN to TOR), but I am not seeing a common set of problems that they solve or the threats that they mitigate. What threat(s) are people solving here?
Examples: