When we originally deployed many new relays using Ansible-Relayor, we used a second IP per process. However, due to routing troubleshooting and relays not showing up on Relay Search, we removed the second IPs.
was this an onionoo issue or did they not show up in the tor consensus either?
Making use of OutboundBindAddressExit should not actually affect the reachability/visiblity on Relay Search.
We are still using only one per relay. We also found it challenging to manage this many relay IPs with Ansible-Relayor. Ansible-Relayor uses sequential IPs based on the listing from ifconfig.
yes, that is the default behavior. You can also set it manually (which ) using the vars: tor_v4ips tor_available_public_ipv4s
These role variables are not actually documented in the README because I aimed for automation (no need to set them manually out of the box), but yes, there might be rare cases where you want to set them manually.
This presents a challenge because it is difficult to setup forward and reverse DNS in a predictable way.
Ideally you would automate that if your DNS provider has an API since the behavior should be deterministic. One other IP usage strategy that I had in mind to make increasing and decreasing the instance count less painful for DNS changes is the following:
current behavior when 4 IPs are available and tor_dedicatedExitIP is used:
.1 OR IP#1 .2 OR IP#2 .3 exit IP #1 .4 exit IP #2
potentially new strategy:
.1 OR IP #1 .2 exit IP #1 .3 OR IP #2 .4 exit IP #2
but that would actually be counterproductive is you want to use two distinct /24 prefixes for in and outbound IPs (but still possible via manually setting above vars).
The second issue we have with running a secondary IP per Tor process is system load. Having more IPs opens more sockets,
I'm not sure I understood you there. Running multiple instances increases the amount of sockets but using OutboundBindAddressExit should not actually increase the amount of TCP connections/sockets used (when compared to not using that tor feature) since exit connections are always new TCP connections, no matter whether it uses the same or a distinct IP address for the exit connection. Maybe you can elaborate?
If you worry about load/sockets you could decrease the amount of tor instances since you can probably do your current exit probability with a lot less instances.
The third issue is that when people block our IPs, they block the scope.
Some will, but most automated blocking mechanisms probably just block the source IP they observed or the IP address as seen in the tor consensus. Maybe it is even enough to have just distinct (smaller) inetnum objects instead of distinct /24 prefixes.
Should we use a secondary IP per relay if the IP is in the same scope?
I do believe it is still valuable to use OutboundBindAddressExit even if they reside in the same /24 prefix. That said, that feature is aimed at operators that have the IPs available, you probably should not use it if you are short on IP addresses.
If we were to use a second /24 for relays, how will Ansible-Relayor know to use a second IP scope for exiting?
by using the vars mentioned above.
to illustrate that: In combination with tor_dedicatedExitIP ansible-relayor would make use of 198.51.100.x for exiting while using 192.0.2.x for OR ports this way:
tor_v4ips: - 192.0.2.1 - 192.0.2.2 tor_available_public_ipv4s: - 192.0.2.1 - 192.0.2.2 - 198.51.100.1 - 198.51.100.2
Tor Project, please increase your #IPv6 awareness/outreach similar to how ARIN and the other RIRs try very hard to do.
+1