[tor-relays] Emerald Onion's new relays

[nusenu]

> 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
 

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20190812/f5589376/attachment.sig>