Not affiliated with the Tor Project.
There are several transparently torifying gateways. They suffer from the same problems:
corridor takes a different approach. It allows only connections to Tor relays to pass through (no clearnet leaks!), but client computers are themselves responsible for torifying their own traffic. In other words, it is a filtering gateway, not a proxying gateway.
You can think of it as a fail-safe for your vanilla Tor Browser or Tails, for your beautiful scary experimental Qubes proxying schemes, etc. Or invite the hood to use your WiFi without getting into trouble.
To be safe, corridor needs two separate network interfaces, like two Ethernet NICs, or one WiFi radio and one DSL modem. One is to receive incoming traffic from client computers, the other one is to pass the filtered traffic towards the global internet, and they need to be on different network address spaces: Clients must not be able to take a shortcut via DHCP, DNS, ICMP Redirect requests, and who knows what else.
corridor cannot prevent malware on a client computer from finding out your clearnet IP address, e.g. by sending the GETINFO address command to any Tor control port on the network (incl. the one on the client computer itself). corridor is not a replacement for using a well-designed operating system on your client computers, like Qubes with TorVM/Whonix.
The optional logging of prevented leaks has several limitations:
You probably should not use corridor in combination with other iptables-based firewalls (like ufw): They can easily clobber some or all of corridor's rules. At the very least, start corridor-init-forwarding and corridor-init-snat after your other firewall, e.g. using systemd orderings.
You may also be interested in Patrick Schleizer's corridor Debian package, or the corridor page in the Whonix wiki
# Install corridor and its systemd units to the default location in /usr/local.
make install install-systemd
# Edit the configuration.
$EDITOR /etc/corridor.d/*# Set up IP traffic forwarding.
corridor-init-forwarding
# Set up Source NAT with iptables.
corridor-init-snat
# Keep track of acceptable Tor relays.
corridor-data &
# Log attempted leaks from selected clients.
# This command will block until corridor_relays gets populated!
corridor-init-logged# If you use something other than systemd-networkd to bring up your
# network interfaces (make sure that whatever it is correctly orders
# itself after network-pre.target!), you must add a dependency:
mkdir /etc/systemd/system/some.service.d
cat >/etc/systemd/system/some.service.d/corridor.conf <<END
[Unit]
Requires=corridor-init-forwarding.service
END
# Start corridor
systemctl start corridor.target
# Start corridor when booting
systemctl enable corridor.targetThis has barely even been tested, be careful!
# In your template:
dnf install tor ipset socat perl make # or apt-get ...
make PREFIX=/usr install install-systemd install-qubes
systemctl enable corridor.target
# In dom0:
qvm-create --prop provides_network=True --template your-template --label blue corridor-gateway
qvm-service --enable corridor-gateway corridorIf $TOR_CONTROL_SOCKET is nonempty, use it. Otherwise, connect to $TOR_CONTROL_HOST (localhost if unset) on $TOR_CONTROL_PORT (9051 if unset).
If $TOR_CONTROL_COOKIE_AUTH_FILE is nonempty, use it. Otherwise, pass $TOR_CONTROL_PASSWD.
The default configuration file sets $TOR_CONTROL_SOCKET to /var/run/tor/control, and $TOR_CONTROL_COOKIE_AUTH_FILE to /var/run/tor/control.authcookie. These values work on Debian and Fedora.
Semantic Versioning is used in the form of signed git tags.
corridor is permissively licensed, see the LICENSE-ISC file for details.