- tor-relays - lists.torproject.org

Re: [tor-relays] Max number of bridge under the same IP
by gus 09 Nov '21

09 Nov '21

On Mon, Nov 08, 2021 at 07:02:13PM +0100, ML Tor wrote: > In data 8/11/2021, *gus* ha scritto: > > Hi, > > On Mon, Nov 08, 2021 at 03:24:13PM +0100, ML Tor wrote: > > Hi, > hi made a new Proxmox server for my home network. I still run a bare metal > Tor bridge, but now i would run more bridge in my home network. > > I have a public dynamic IP: what is the max number of bridge i can run > (obviously on different ORPort) under the same IP address > > > From the Tor Relay Guide: > > "Note: You can only run two Tor relays per public IPv4 address. If you > want to run more than two relays you will need more IPv4 addresses." > https://community.torproject.org/relay/relays-requirements/ > > > Too bad, so no more than two bridge on my singe ip. > > But... > > Maybe you want to run a standalone Snowflake > proxy?https://community.torproject.org/relay/setup/snowflake/ > > > Can i run my two bridge AND one Snowflake proxy? ;-) > Yes, it's fine! :) cheers, Gus > Thanks in advance, > > > -- > ML -- The Tor Project Community Team Lead

2 1

Max number of bridge under the same IP
by ML Tor 08 Nov '21

08 Nov '21

Hi, hi made a new Proxmox server for my home network. I still run a bare metal Tor bridge, but now i would run more bridge in my home network. I have a public dynamic IP: what is the max number of bridge i can run (obviously on different ORPort) under the same IP address Thanks in advance, -- ML

2 1

upgrade problem
by potlatch 06 Nov '21

06 Nov '21

Wondering if my tor.list has a typo since I can't upgrade Tor 0.4.5.9. I get error: Err:1 https://deb.torproject.org/torproject.org stretch/main amd64 tor-geoipdb all 0.4.5.10-1~d9.stretch+1 server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none I have debian 9 installed. Can someone turn on the light for me? Thanks, potlatch Sent with ProtonMail Secure Email.

2 1

known issues with deb.torproject.org repos?
by nusenu 02 Nov '21

02 Nov '21

Hi, are there known issues with the nightly master debian package builds? https://deb.torproject.org/torproject.org/dists/ and a related question: Will the stable packages remain on the 0.4.5.x LTS branch until the next LTS branch or will it at some point move to the latest stable again? (as it used to be) https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… kind regards, nusenu -- https://nusenu.github.io

2 3

Relay MIGHTYWANG consensus issues and loss of STABLE flag
by Mighty Wang 29 Oct '21

29 Oct '21

Hello fellow operators I have one pretty large relay, MIGHTYWANG which is an IP4/6 guard, dedicated hardware running on a 1Gb line uncontended. It is usually one of the top 5 relays by consensus weight but on the morning of 14th October it lost Guard status on account of losing the stable flag. I checked logs, connectivity and server health - nothing unusual, everything is generally pretty bullet proof in and around the relay and it had been running for well over a year without a reboot - just the very occasional Tor daemon restart following upgrades but no such activity prior to the 14th. So next I checked the consensus and I see that around half of the directory authorities seem to be not assigning the stable flag. See attached screenshot showing current consensus. The peering to each of those relays seems OK from what I can see (IP4 and IP6) so any idea what gives? I've got a MIGHTYWANG sitting here twiddling it's thumbs because have the directory authorities don't want to use it. Bit of a waste. I had similar things happen a few years ago with one of my old relays; again no obvious reason, just seemed to be the a random whim of the directory authorities. I've noticed a couple of other long term relays are in a similar position - is this some time of attack, deliberate action or just Tor magic? Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC

4 5

Tor respority can't be updated from securly on debian
by Keifer Bly 28 Oct '21

28 Oct '21

Hi, so I am trying to update tor to the newest version on my debian vps, only to receive this error: Reading package lists... Done E: The repository 'https://deb.torproject.org/torproject.org st retch Release' no longer has a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. Here is my sources.list file, ## Note, this file is written by cloud-init on first boot of a$ ## modifications made here will not survive a re-bundle. ## if you wish to make changes you can: ## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/clo$ ## or do the same in user-data ## b.) add sources in /etc/apt/sources.list.d ## c.) make changes to template file /etc/cloud/templates/sour$ ### # See http://www.debian.org/releases/stable/i386/release-notes$ # for how to upgrade to newer versions of the distribution. deb http://deb.debian.org/debian buster main deb-src http://deb.debian.org/debian buster main ## Major bug fix updates produced after the final release of t$ ## distribution. deb http://security.debian.org/ buster/updates main deb-src http://security.debian.org/ buster/updates main deb http://deb.debian.org/debian buster-updates main deb-src http://deb.debian.org/debian buster-updates main ## Uncomment the following two lines to add software from the $ ## repository. ## I am wondering what needs to be added here to allow tor to update? Thank you.

3 2

bridge question
by potlatch 28 Oct '21

28 Oct '21

Should torrc for bridges list MyFamily? I run several of both. potlatch Sent with ProtonMail Secure Email.

2 1

Dropped off consensus (0.4.4.5)
by Felix 23 Oct '21

23 Oct '21

Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix

5 8

Tor Bridge Question
by Josh Lawson 19 Oct '21

19 Oct '21

I work for a bank and was informed that when I connect to my employer network, it shows I am coming from a Tor IP and sets off an alert that then leads to me being on a call with an investigative team for my employers. I was running a Tor relay, but had to shut it down because of these alerts. I am not thinking of running a bridge instead, but I have a question. Are the bridge IP addresses private enough to not likely trigger an alert by bank fraud detection software? Please let me know if I am not phrasing this well. I would like to donate some bandwidth and was thinking maybe running a bridge would be less likely to set off alerts.

3 2

Overloaded state indicator on relay-search
by Silvia/Hiro 19 Oct '21

19 Oct '21

Hello all, One of our goals with our current performance work is to reduce the overload of relays in the network. The implementation of proposal 328[1] a while back made different overload indicators available to relay operators and since a couple of weeks ago those can be tracked via Onionoo[2] as well. As we know that a lot of our relay operators use relay search to check for the health of their relays, we have launched a new feature there, too, to help them know when their relays are overloaded. When a relay is in the overloaded state we show an amber dot next to the relay nickname. Currently we are counting between 50 and 80 overloaded relays and between 10 and 20 overloaded bridges. The overloaded state is reached when one or many of the possible load metrics have been triggered. When this happens we show it for 72 hours after the relay has recovered [3]. Note, though, that not all of the exposed overload metrics are triggering the overload indicator on relay search yet. If you noticed your relay is overloaded, please check the following support article to find out how you can recover to a "normal" state: https://support.torproject.org/relay-operators/relay-bridge-overloaded/ Let us known how you find this new feature. Cheers, -hiro [1] https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload… [2] https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637

13 51