| Both sides previous revisionPrevious revision | |
| fuss:tor [2025/02/26 04:09] – [Load-Balancing Multiple Tor Instances via HAProxy] office | fuss:tor [2025/02/26 04:25] (current) – office |
|---|
| |
| </code> | </code> |
| | |
| | ====== Load-Balancing Multiple Tor Instances via HAProxy ====== |
| | |
| | When running multiple Tor instances, it is possible to load-balance the traffic over all Tor instances whilst having a single SOCKS entry point. For instance the proxy chaining page shows [[/networking/proxy_chaining|a configuration that leverages squid and polipo instances]] in order to load balance the traffic accross multiple Tor instances whilst the [[/linux/running_multiple_instances_of_a_daemon|multiple instances page]] demonstrates how to run the same program multiple times while maintaining System D compatibility. |
| | |
| | Nevertheless, there are simpler setups possible by using HAProxy that is able to load balance across multiple SOCKS servers. By contrast, ''privoxy'' is a smaller proxy but uses pattern matching to spread the traffic over backends without actually being able to load-balance over multiple SOCKS connections. |
| | |
| | <ditaa> |
| | . multiple Tor instances |
| | . |
| | +---------+ |
| | +---------+ +----+ Tor | |
| | | | / +---------+ |
| | SOCKS--+ HAProxy +---+ . |
| | | | \ +---------+ |
| | +---------+ +----+ Tor | |
| | +---------+ |
| | . |
| | . |
| | </ditaa> |
| | |
| | Assuming that multiple Tor instances are set up to listen to an array of ports, HAProxy can be set up with the following minimal configuration changes: |
| | <code> |
| | defaults |
| | mode tcp |
| | option redispatch |
| | |
| | listen socks5-balance |
| | bind 0.0.0.0:9050 |
| | balance leastconn |
| | server socks5-1 127.0.0.1:9051 check |
| | server socks5-2 127.0.0.1:9052 check |
| | |
| | </code> |
| | |
| | The configuration declares two upstream proxies on ''127.0.0.1'' and listening on port ''9051'' respectively ''127.0.0.1'' and listening on port ''9052'', listens on ''0.0.0.0'' on port ''9050'' and will proxy all traffic between the declared SOCKS servers with the following options: |
| | * ''balance leastconn'' - the balancing method chosen in ''leastconn'' that will attempt to distribute the load across the two declared SOCKS proxies. However, ''leastconn'' relies on log-term connections in order to distribute weights across the SOCKS servers such that ''roundrobin'' could have been chosen instead. |
| | * ''option redispatch'' - makes HAProxy retry proxies in case one of the backends fail. |
| | |
| | Finally, by pointing an application at the HAProxy port ''9050'', the connection should be spread amongst the declared SOCKS backend servers. Depending on the distribution configuration, the log files can be observed to make sure that the traffic is properly redirected. |
| | |
| | ===== Availability ===== |
| | |
| | Based on [[/fuss/tor#monitoring_tor_health_status|checking the tor status]], it is also possible to make backend checks stronger in order to determine whether a certain tor instance should be used or not. The HAProxy configuration proposed just uses a port check on the tor socks port in order to determine whether the tor instance is running, however that check is weak, checking just connectivity, and it is possible to make the check stronger by polling tor for the circuit status. |
| | |
| | The tor configuration must be updated in order to open up port ''8050'' as a control port as well as specify the password as a hash: |
| | <code> |
| | ControlPort 8050 |
| | HashedControlPassword 16:9F840FFC85EF83CE60469C431DC9FF43DB889305B7653C2CB653302594 |
| | </code> |
| | |
| | For each additional tor instance, a program will be running that will serve the tor circuit status over TCP: |
| | <code bash> |
| | socat TCP-LISTEN:7050,fork,reuseaddr exec:"/usr/local/bin/tor-check-circuit 127.0.0.1 8050 tor |
| | </code> |
| | where: |
| | * ''7050'' is a port that a client can connect to in order to find out the status of the tor circuit, |
| | * ''tor-check-circuit'' is a script that uses "expect" to check tor for the tor circuit and an example thereof can be found [[/assets/docker/build/tor-snowflake#tor-check-circuit|on the tor Docker build page]], |
| | * ''8050'' will be the port opened up by each tor configuration (usually ''torrc'') by specifying ''ControlPort 8050'' |
| | |
| | Finally the HAProxy configuration file should be changed to: |
| | <code> |
| | defaults |
| | mode tcp |
| | option redispatch |
| | |
| | listen socks5-balance |
| | bind 0.0.0.0:9050 |
| | balance leastconn |
| | server socks5-1 127.0.0.1:9051 check weight 100 agent-check agent-port 7050 agent-inter 1s |
| | server socks5-2 127.0.0.1:9052 check weight 100 agent-check agent-port 7050 agent-inter 1s |
| | |
| | </code> |
| | |
| | The mechanism will ensure that each ''socat'' instance will return either ''100'' when a circuit is established and ''0'' otherwise, which, in turn, will allow HAProxy to dynamically change the weight of the given tor instance. |
| | |
| | Incidentally, the same same balancing scheme has been used for [[/networking/leveraging_docker_swarm_for_high-availability_and_load-balancing_services|load-balancing Apache servers within Docker containers]] and the same principle is leveraged here, just that the ''tor-check-circuit'' script will only return ''100'' or ''0'' with weights only varying from "available" (100) to "none" (0), instead of actual "weights" using the full range between ''0'' and ''100''. |
| |
