On Saturday, January 29, 2022, 9:46:59 PM PST, David Fifield <da...@bamsoftware.com> wrote: >> > I'm not using nyx. I'm just looking at the bandwidth on the network >> > interface.
>> If you have time, would you mind installing nyx to validate observed >> similarities/differences between our loadbalanced configurations? > I don't have plans to do that. I appreciate you setting expectations. >> > > I'm glad to hear you feel the IPv6 reporting appears to be a >> > > false-negative. Does this mean there's something wrong with IPv6 >> > > Heartbeat reporting? >> > I don't know if it's wrong, exactly. It's reporting something different >> > than what ExtORPort is providing. The proximate connections to tor are >> > indeed all IPv4. >> I see. Perhaps IPv6 connections are less prolific and require more time to >> ramp? > No, it's not that. The bridge has plenty of connections from clients that use >an IPv6 address, as the bridge-stats file shows: > ```plain > bridge-ip-versions v4=15352,v6=1160 > ``` > It's just that, unlike a direct TCP connection as the the case with a guard >relay, the client connections pass through a chain of proxies and processes on >the way to the tor: client → Snowflake proxy → snowflake-server WebSocket >server → extor-static-cookie adapter → tor. The last link in the chain is >IPv4, and evidently that is what the heartbeat log reports. The client's >actual IP address is tunnelled, for metrics purposes, through this chain of >proxies and processes, to tor using a special protocol called ExtORPort (see >USERADDR at >https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-control-ports.txt). > It looks like the bridge-stats descriptor pays attention to the USERADDR >information and the heartbeat log does not, that's all. Ah... Gotcha. Thank you for clarifying. >> After expanding my reading of your related "issues," I see that your VPS >> provider only offers up to 8 cores. Is it possible to spin-up another VPS >> environment, with the same provider, on a separate VLAN, allowing route/ >> firewall access between the two VPS environments? This way you could test >> loadbalancing a Tor Bridge over a local network using multiple virtual >> environments. > Yes, there are many other potential ways to further expand the deployment, >but I do not have much interest in that topic right now. I started the thread >for help with a non-obvious point, namely getting past the bottleneck of a >single-core tor process. I think that we have collectively found a >satisfactory solution for that. The steps after that for further scaling are >relatively straightforward, I think. Running one instance of snowflake-server >on one host and all the instances of tor on a nearby host is a logical next >step. Understand. I appreciate the work you have done and the opportunity to compare and contrast Loadbalanced Tor Bridges vs Loadbalanced Tor Relays. Please update the tor-relays mailing-list with any new findings related to subversion of the onion keys rotation. Excellent Work! Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
