- tor-relays - lists.torproject.org

torrc, unit files, confusion
by Martin Gebhardt 19 Feb '22

19 Feb '22

Hello together, I've gotten myself stuck in a situation that I can't get out of. The following: I have a working relay. You can find the config for it in the attachment [1]. I want to move parts of the config. So I use %include. I don't do anything else than moving parts of the working config to other files. There are no changes at all. But, tor does not start anymore.In the attachment [2] you can find the config with %include. The folder structure is the following: ├── info.html ├── rc.d │ ├── contact.rc │ ├── family.rc │ └── nickname.rc ├── torrc └── torsocks.conf No matter what I do, I can't get it to enable debug logs when I start tor from the unit file. This is unchanged, but I attached it anyway [3]. Anyway, I start tor as root, then everything works [4]. I have no idea where something should be wrong with the permissions. I have also recursively set the permission of /etc/tor/ to the user debian-tor, but it doesn't help. When I do the following: cat rc.d/* >> torrc && sed -i /include/d torrc && systemctl restart tor Everything works fine again. My system: Linux privacy 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux Tor version 0.4.6.9. Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.33 as libc. Tor compiled with GCC version 10.2.1 Maybe I'm still too tired to figure it out. But please, can someone give me some advice where to look further? Or at least tell me how to get a debug log when I start tor from the systemd-unit. Then I would surely get further. Thanks for your attention and help. -- Martin

3 3

New relay has a problem - Re-used IP blocked in consensus?
by Olaf Grimm 18 Feb '22

18 Feb '22

Hello Tor community! I have some identical new relays, but only one of them has a problem. My intention was an IPv6 problem, so there ist IPV6 diabled at all. Fingerprint: 3F1AE2170CAD31B5694BD9052A2A29E5793BDC1F IP: 107.189.14.123 Ports open: 22, 80, 9001 Test from outside by scanner: ok UFW firewall open ports set to: 22, 80, 9001 torrc: No IPv6 configuration enabled. The same configuration about all relays. With Nyx I can see built circuits, but the relay does not appear in the metrics, but other relays already show strong traffic. Debian system updates are possible, the HTTP frontpage is displayed at the given IP address, DNS 'unbound' ok because updates are possible. Unbound is set to 127.0.0.1 only. Here some logs from Nyx (copy like displayed): 11:18:41 [INFO] find_my_address(): Unable to find our IP address. 11:18:41 [INFO] address_can_be_used(): Address '::1' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses. 11:18:41 [INFO] tor_getaddrinfo(): (Sandbox) getaddrinfo succeeded. 11:18:41 [INFO] get_address_from_interface(): Could not get local interface IP address. 11:18:41 [INFO] get_interface_address6_via_udp_socket_hack(): connect() failed: Cannot assign requested address 11:18:41 [INFO] address_can_be_used(): Address '::' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses. 11:18:41 [INFO] get_address_from_config(): No Address option found in configuration. 11:18:39 [INFO] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 0 delayed; 6795 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress. I can not find what is wrong, but I see "::" what is IPv6. In Debian /etc/sysctl.conf IPv6 is disabled. net.ipv6.conf.all.disable_ipv6 = 1 Can you help me? Please check the IP in the consensus. Blocked? Olaf

3 2

Help a newbie
by chuck＠relay-security.org 15 Feb '22

15 Feb '22

I have a problem. This relay was running fine until I changed the nickname. After making the change, I ran “tor --verify-config” just to make sure, and then ran “sudo systemctl restart tor@default” I see it running, but the syslog shows: Feb 14 23:31:46 tor1 tor[592]: Feb 14 23:31:46.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) Feb 14 23:31:47 tor1 tor[592]: Feb 14 23:31:47.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) Feb 14 23:31:47 tor1 tor[592]: Feb 14 23:31:47.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) Feb 14 23:31:48 tor1 tor[592]: Feb 14 23:31:48.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) and on and on .… What have I done wrong? The fqdn is https://tor1.relay-security.org

1 0

Tor installation from Source
by nikoloskid＠pm.me 12 Feb '22

12 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, My relay is running on Raspberry OS so the updates are a little late for some packages, so my relay is running on obsolote version 0.3.5.15, I installed Tor from source and tor --version gives me Tor version 0.4.6.10. Tor is running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.28 as libc. Tor compiled with GCC version 8.3.0but tor(a)default.service is still running on 0.3.5.15 (I have restarted the service multiple times)... Regards, Daniel Nikoloski Sent with ProtonMail Secure Email. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBzBAEBCAAGBQJiBMpiACEJEAutNI6WgEWAFiEE/jRLdx96gF2z0p05C600 jpaARYCzgQf5AXlzmz1cV38y+/4DMFGMwV74+2acsiAhw8dml1/In34debY1 JgoP6CP+GugKMPAq7JQPvhRF2eVrTYdSN9h0OFrZE3OT45YZWR7uU38MzXd0 NorjBu9lALsE321ocL80igKd+0nXgOofQoWyelaLMRc1YCP8BQLXqv7JLAee 0eZLaHyX8u3OdgyE/ejpbb+7tKzXSkSQZ7vh6e0BEcmQZFXfzEbTuS6jzGQk x8OOYZmF7t4Q1m54NffydyXbQv7hUPYaRFwyMLwdonRl51GFATr+G6vMQqkf QsxxvRQflJ0ANv0cw9oUieMCYXyzrb3oNf9avOucHP477CG6UjwV3A== =m7jC -----END PGP SIGNATURE-----

3 2

Legal bases
by Martin Gebhardt 10 Feb '22

10 Feb '22

Hello all, I would like to read about experiences with local laws of various countries. So far I run my exits in Austria, Germany and the Netherlands. I have found a provider for me that also covers the following countries and has no problem with Tor exits: - Poland - Australia - Singapore - France My goal is to have a unified website for each country, where you can find links to official websites of the countries with "traffic passing " laws. For AT, DE and NL these are known to me. For the other countries not. Now before I start searching and messing around with translators, I hope someone here has experience in one or more of these countries and can provide with paragraphs. I am grateful for any hint. -- Martin

1 0

Re: [tor-relays] snowflake vs bridges (vs node)
by Fran 08 Feb '22

08 Feb '22

Thanks meskio, this helped a lot to clarify things. So I thought of trying to run a bride and a snowflakeproxy on one VM with individual IP addressing in v4 and v6 for each by adding secondary addresses to to the WAN interface. But after compiling the go binary I fail to find out how to tell snowflake which IP to bind to/use. For the bridge this can be achieved with: Address <IPv4> Address <IPv6> OutboundBindAddress <IPv4> OutboundBindAddress <IPv6> (and maybe to be save also set OutboundBindAddressPT, OutboundBindAddressExit and OutboundBindAddressOR) But for snowflake I'm missing the options: Usage of ./proxy: -broker string broker URL (default "https://snowflake-broker.torproject.net/") -capacity uint maximum concurrent clients -keep-local-addresses keep local LAN address ICE candidates -log string log filename -nat-retest-interval duration the time interval in second before NAT type is retested, 0s disables retest. Valid time units are "s", "m", "h". (default 24h0m0s) -relay string websocket relay URL (default "wss://snowflake.bamsoftware.com/") -stun string broker URL (default "stun:stun.stunprotocol.org:3478") -summary-interval duration the time interval to output summary, 0s disables retest. Valid time units are "s", "m", "h". (default 1h0m0s) -unsafe-logging prevent logs from being scrubbed -verbose increase log verbosity Could be solved with VRFs/namespaces but would involve bridging, veths...too snowflaky for me (same goes for containers). So I guess I'll just keep the bridges and make then relays one day. Thanks for all who helped! best fran On 2/7/22 11:12, meskio wrote > Yes, there are many differencies. snowflake does make the traffic look like > webrtc (like a video conference) and obfs4 makes the traffic look like random > noise. Also the clients use different mechanisms to discover the relays. > > If you run both in the same IP address and the censor has a way to discover one > but not the other both of them will be blocked at once. So you are making it > easier for the censor to discover them and block them. That is why we don't want > people to run both in the same IP address.

2 1

cases where relay overload can be a false positive
by s7r 08 Feb '22

08 Feb '22

Hello, One of my relays (guard, not exit) started to report being overloaded since once week ago for the first time in its life. The consensus weight and advertised bandwidth are proper as per what they should be, considering the relay's configuration. More than this, they have not changed for years. So, I started to look at it more closely. Apparently the overload is triggered at 5-6 days by flooding it with circuit creation requests. All I can see in tor.log is: [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [68382 similar message(s) suppressed in last 482700 seconds] [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [7882 similar message(s) suppressed in last 60 seconds] This message is logged like 4-5 or 6 time as 1 minute (60 sec) difference between each warn entry. After that, the relay is back to normal. So it feels like it is being probed or something like this. CPU usage is at 65%, RAM is at under 45%, SSD no problem, bandwidth no problem. Metrics port says: tor_relay_load_tcp_exhaustion_total 0 tor_relay_load_onionskins_total{type="tap",action="processed"} 52073 tor_relay_load_onionskins_total{type="tap",action="dropped"} 0 tor_relay_load_onionskins_total{type="fast",action="processed"} 0 tor_relay_load_onionskins_total{type="fast",action="dropped"} 0 tor_relay_load_onionskins_total{type="ntor",action="processed"} 8069522 tor_relay_load_onionskins_total{type="ntor",action="dropped"} 273275 So if we account the dropped ntor circuits with the processed ntor circuits we end up with a reasonable % (it's >8 million vs <300k). So the question here is: does the computed consensus weight of a relay change if that relay keeps sending reports to directory authorities that it is being overloaded? If yes, could this be triggered by an attacker, in order to arbitrary decrease a relay's consensus weight even when it's not really overloaded (to maybe increase the consensus weights of other malicious relays that we don't know about)? Also, as a side note, I think that if the dropped/processed ratio is not over 15% or 20% a relay should not consider itself overloaded. Would this be a good idea? Sending to tor-relays@ for now, if some of you think of this in any way we can open a thread about it on tor-dev@ - please let me know if I should do this.

3 5

Genereal queations about MyFamily
by Martin Gebhardt 07 Feb '22

07 Feb '22

Hello, I am running some servers in the Tor infrastructure for research reasons and my own (mainly political) interest. I have a few questions, the answer to which would help me a lot at the moment. 1. can someone explain to me how the fingerprint of a Family is created? For example, I have 7 exit relays in a Family, and can't remember how that came about. 1. 2. to simplify the torrc, would it not be advantageous to enter in "MyFamily" not all fingerprints, but only that of the Family as such? Are there already suggestions for this with the developers? If not, which Git would be the most suitable to place my suggestion? I know, then everyone could "join" a family, since another node does not explicitly also include the one in the config. But there will be a solution for that. Like with AROI from nusenu. I explore various possibilities to deanonymize. My motives are solely dedicated to the Tor project. I have configured a bridge and I know that it is also possible to restrict exits. For example via the country code. I have also done that successfully, but: 2. 1. I don't manage to configure a bridge _and_ a fixed exit. 2. 2. also here I would welcome a feature to specify the fingerprint of a family as forced exits instead of single fingerprints or countrycodes. Also here the question like in 1.2, where could I place this then best. All this does not necessarily provide an advantage in anonymization, but it makes research much easier. And before someone says that i don't need that... there is a lot that i don't need and that doesn't serve the purpose of a software, you are not forced to configure it let alone recommend it. I'm just talking about possibilities that should facilitate the research. -- Martin

3 4

snowflake vs bridges (vs node)
by Fran 07 Feb '22

07 Feb '22

Hey, I just saw, that it's possible to run snowflake[1] not only as browser plugin, but also standalone. So I am wondering what makes more sense, run a bridge with obsf4 or run a snowflake instance instead of a bridge. Or would it even make sense to install both on one server? And generally, what's more needed atm: bridge, non-exit, exit or snowflake? Thanks! fran [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

5 6

ExitNodes Directive Evaluated Dynamicly or Bootstrap Only?
by Gary C. New 07 Feb '22

07 Feb '22

All: Is the ExitNodes Directive evaluated Dynamicly or only during Bootstrap? What happens if an exit in the ExitNodes list is down when selected? 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)

1 0

Outdated GeoIP DB
by Martin Gebhardt (Die LINKE.) 06 Feb '22

06 Feb '22

Hi, in the past I had already written with someone about it. At that time the entries were not up to date. There was a Gitlab issue about this, but I can't find it now. Anyway, the data is not up to date again. Example: https://apps.db.ripe.net/db-web-ui/query?searchtext=89.58.17.76 vs https://metrics.torproject.org/rs.html#details/6A0A9C3B3381C89CCB85C64BBCF6… The IP address is currently located in Austria. But in the metrics Germany is displayed. This is a "correct" but outdated information. Since I don't know if this can have any effects on the routing, which I don't assume, but is theoretically possible, I just want to target it again.

6 6

Relay operators meetup @ FOSDEM
by Stefan Leibfarth 05 Feb '22

05 Feb '22

Greetings relay operators, the next Tor relay operators meetup will be online @ FOSDEM. Date: 2022-02-05 Time: 1500 UTC Room: https://lecture.senfcall.de/rin-2tx-xcy-g5r No need for a registration or anything else, just use the room-link above. There will be a agenda, but everyone is free to bring up additional questions or topics at the meeting itself. Looking forward to meeting you Leibi [0] https://fosdem.org/2022/fringe/

3 2

Recommended IPv6 Configuration
by t.duellmann+torrelays＠gmail.com 04 Feb '22

04 Feb '22

Dear list, I read here [1] that IPv6 is on the rise and support for it is growing. Are there any recommendations or best-practices how to configure a Tor relay with IPv6? Alternatively, could anybody who got it set up already, post their experiences and maybe even the relevant parts of their torrc? Thanks! [1] https://blog.torproject.org/state-of-ipv6-support-tor-network/

3 2

Exit relays abused to attack Google services
by UDN Tor 03 Feb '22

03 Feb '22

Google is now sending abuse reports complaining of DDoS attacks against their services. While they believe the IPs are participating in a botnet, it is clear that they are Tor exit relays. I don't know why they are sending us the report after the attacks have ended. Besides, since Google services are unusable over Tor, this should not have caused them much damage. I suspect the attacker is trying to get relays shut down by triggering Google reports that would scare off the ISPs. If you are an ISP and you have received the same report, please let me know. I'd like to know if this was global or if we've been "selected". > From: ddos-reports(a)google.com > To: abuse(a)urdn.com.ua > Subject: [#zMto] DDoS from your IPs to Google from 2022-01-28 to > 2022-01-31 > Date: Tue, 01 Feb 2022 20:22:42 +0000 > > We observed IPs under your control participating in DDoS attacks > targeting Google services, including a prolonged DDoS attack from > January 28-31 against the Google Search Console. > > The attacks were Layer 7 / HTTP request floods. Your participating > IPs are listed below, along with the stop time in UTC and targeted > Google IPs. We request that you enforce your Acceptable Use Policy > against these customers. > > +-----------------+-----------------+----------+---------------------+ > | Source | Destination | DestPort | Time_UTC | > +-----------------+-----------------+----------+---------------------+ > | 193.218.118.62 | 142.250.180.227 | 443 | 2022-01-31 15:55:01 | > | 193.218.118.90 | 142.250.180.195 | 443 | 2022-01-31 15:53:28 | > | 193.218.118.100 | 172.217.19.99 | 443 | 2022-01-31 14:43:09 | > | 193.218.118.101 | 142.250.180.227 | 443 | 2022-01-31 17:32:54 | > | 193.218.118.125 | 142.250.180.227 | 443 | 2022-01-31 15:55:28 | > | 193.218.118.145 | 142.250.180.195 | 443 | 2022-01-31 15:55:30 | > | 193.218.118.147 | 142.251.39.35 | 443 | 2022-01-31 15:41:36 | > | 193.218.118.155 | 142.250.180.195 | 443 | 2022-01-31 13:45:43 | > | 193.218.118.156 | 142.250.180.227 | 443 | 2022-01-31 15:57:52 | > | 193.218.118.158 | 142.250.180.227 | 443 | 2022-01-31 18:41:34 | > | 193.218.118.167 | 142.250.201.195 | 443 | 2022-01-31 15:56:53 | > | 193.218.118.182 | 142.251.39.3 | 443 | 2022-01-31 17:31:57 | > | 193.218.118.183 | 142.250.180.227 | 443 | 2022-01-31 17:42:40 | > | 193.218.118.231 | 142.250.180.227 | 443 | 2022-01-31 17:43:08 | > +-----------------+-----------------+----------+---------------------+ > > Note we believe some of these IPs are part of the Meris or Dvinis > botnets. If you are a residential Internet service provider, it is > possible that your customers' routers themselves have been > compromised. You should research the Meris botnet and take > appropriate actions to have them secure their CPE (customer-premises > equipment). > > -- > Security Reliability Engineering :: Google :: AS15169

4 3

reminder: tor 0.3.5 reaches end of life on 2022-02-01
by nusenu 02 Feb '22

02 Feb '22

Reminder: tor 0.3.5 reaches it's end of life on 2022-02-01 (in 3 weeks from now). Over 700 relays - about 7% of the network's guard capacity currently still run this soon unsupported tor version. https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… kind regards, nusenu -- https://nusenu.github.io _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 1

Introduction message from me :)
by Miryam Webb 02 Feb '22

02 Feb '22

Hello all, I am a new relay operator and I am glad to make your acquaintance. Currently my nodes are not processing traffic because they are being rejected by the directory nodes but I hope that gus will reply soon and that we can get this working. I have been administrating linux servers for more than 8 years but I have no experience with running tor nodes. So if you have tips and tricks a noob should know feel free to write me. :) Miryam

3 2

OVHcloud does not allow Tor exit relays on VPS/cloud services
by Neel Chauhan 02 Feb '22

02 Feb '22

Hi, I was running a pair of Tor exit relays on OVH, and when I sent an response, I got this as a reply: === As provided in our Service Specific Terms, Anonymization services, such as TOR, are not permitted on OVHcloud's VPS or Public Cloud services. We request that you immediately cease utilizing your current subscriptions as a TOR exit node. Failure to comply with this request may result in the suspension and/or termination of your servers and/or account in accordance with our Terms of Service. https://us.ovhcloud.com/legal/service-specific-terms === It seems OVH does not allow Tor exit relays on "cloud" or "VPS" subscriptions anymore. In the past when I used OVH for exits I had no issues, so they must have changed their TOS. I am assuming OVH dedicated servers are fine. I guess I'm moving the two exit relays to Terrahost. Terrahost is more expensive but I already have exits there and they are excellent. I never had a great experience with OVH. -Neel

2 1

wrong iptables rules? / no inbound traffic in nyx
by ax8eaz7z3g 27 Jan '22

27 Jan '22

Hi! I noticed that after I have set up my ip(+6)tables up to filter unwanted incoming traffic all "inbound" and "directory" connections in nyx disappeared, only lot of "outbound" connections are there. I am running exit relay (IPv4+IPv6) on ORPort 443 and DIRPort 80. Is there someone willing to check my iptable rules? I am starting to lose it... > My iptables: > -P INPUT DROP > > -P FORWARD DROP > > -P OUTPUT DROP > > -A INPUT -i lo -j ACCEPT > > -A INPUT -p tcp -m conntrack --ctstate NEW,ESTABLISHED -m tcp --dport 22 -j ACCEPT # SSH running there > > -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT # allow incoming comm to ORPort > > -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT # allow incoming comm to DIRPort > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # allow all already established incoming connections > > -A OUTPUT -o lo -j ACCEPT # allow all outgoing connections > > -A OUTPUT -o eth0 -j ACCEPT > My ip6tables: > > -P INPUT DROP > > -P FORWARD DROP > > -P OUTPUT DROP > > -N ICMPv6_IN > > -N ICMPv6_OUT > > -A INPUT -i lo -j ACCEPT > > -A INPUT -p tcp -m conntrack --ctstate NEW,ESTABLISHED -m tcp --dport 22 -j ACCEPT # SSH running there > > -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT # allow incoming comm to ORPort > > -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT # allow incoming comm to DIRPort > > -A INPUT -p ipv6-icmp -j ICMPv6_IN #pass all icmpv6 related traffic to new chain > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # allow all already established incoming connections > > -A OUTPUT -o lo -j ACCEPT > > -A OUTPUT -p ipv6-icmp -j ICMPv6_OUT #pass all icmpv6 related traffic to new chain > > -A OUTPUT -o eth0 -j ACCEPT # allow all outgoing connections > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT > > -A ICMPv6_IN -j DROP > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT > > -A ICMPv6_OUT -j DROP Thank you all for any replies! Have a nice day. Bye

2 2

We need bridges with iat-mode set to 1 and especially 2 as well!
by juckiuscaesar＠web.de 27 Jan '22

27 Jan '22

5 9

tor prometheus metrics -> expected label value, got "INVALID"
by Fran 25 Jan '22

25 Jan '22

Hej, I just found out about the integrated prometheus exporter in tor - yay, thanks for that! I can scrape it with curl: $ curl http://<ip>:9035/metrics # HELP tor_hs_rdv_num_total Total number of rendezvous circuit created # TYPE tor_hs_rdv_num_total counter tor_hs_rdv_num_total{onion=<onionv3adr>} 4 # HELP tor_hs_app_write_bytes_total Total number of bytes written to the application # TYPE tor_hs_app_write_bytes_total counter tor_hs_app_write_bytes_total{onion=<onionv3adr>,port=80} 15211 # HELP tor_hs_intro_num_total Total number of introduction received # TYPE tor_hs_intro_num_total counter tor_hs_intro_num_total{onion=<onionv3adr>} 4 # HELP tor_hs_rdv_established_count Total number of established rendezvous circuit # TYPE tor_hs_rdv_established_count gauge tor_hs_rdv_established_count{onion=<onionv3adr>} 1 # HELP tor_hs_app_read_bytes_total Total number of bytes read from the application # TYPE tor_hs_app_read_bytes_total counter tor_hs_app_read_bytes_total{onion=<onionv3adr>,port=80} 319667 # HELP tor_hs_intro_established_count Total number of established introduction circuit # TYPE tor_hs_intro_established_count gauge tor_hs_intro_established_count{onion=<onionv3adr>} 18 Which looks like proper data for me. Unfortunately prometheus thinks otherwise. In the prometheus webGUI under "/targets" it complains: > expected label value, got "INVALID" The Prometheus config part is: - job_name: tor_metrics metrics_path: /metrics static_configs: - targets: - <server1>:9035 - <server2>:9035 Servers are running Debian 11, Prometheus 2.32.1 and tor 0.4.6.9-1~d11.bullseye+1 I searched the relays mailinglist and tried to find something in the internet, unfortunately not very successfully. Any ideas? Thanks a lot! fran

2 3

All relays rejected
by lists＠redpanda.bz 24 Jan '22

24 Jan '22

Hi @all, i operate family https://yui.cat/family/BD0630FF0D6E61A906A4D69340B5B1F4FC805498/ and all of my nodes are getting rejected. I have a valid contact info set in my torrc, as MyFamily for all the nodes i operate and all the nodes are running on tor 0.4.6.9 but i recieve: http status 400 ("Fingerprint and/or ed25519 identity is marked rejected -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to bad-relays(a)lists.torproject.org mentioning your fingerprint(s)?") response from dirserver I sent an email already to the bad-relays list but maybe anyone of you got an idea?

2 1

Terraform to deploy Tor Relays
by Andrew Smith 19 Jan '22

19 Jan '22

Hi I wanted to share a project that I've been working on which allows deploying of Tor relays through terraform. The code and documentation is here: https://github.com/andrewmichaelsmith/terrator The focus is on running on cloud hosting providers, currently supported cloud services are digitalocean, vultr and heztner. It works - I'm using it to run some tor relays right now. There are some limitations (documented on github) though and it is still very much a work in progress. As a bit of background, after reading the call to deploy more bridges <https://blog.torproject.org/tor-censorship-in-russia/> I got thinking how useful it could be to deploy a number of bridges by simply editing a config file and pushing 'go'. After a bit of tinerking - torraform <https://github.com/andrewmichaelsmith/terrator> was born. Personally I have this hooked up to Github and Terraform Cloud (both free), meaning I can simply edit 1 file in a git repo to create new relays. Keen to hear feedback or questions! Thanks -- Andy Smith http://andrewmichaelsmith.com | @bingleybeep

2 2

IPV6 address keeps changing every 2-3 days
by Quentin Campbell 19 Jan '22

19 Jan '22

Hi, I'm running a non-exit relay on a home British Telecom broadband connection (FTTC, 20Mb up/80Mb down). Its IP addresses (IPV4 & IPV6) are allocated dynamically. The IPV4 address can remain the same for weeks. However the IPV6 address seems less stable and lasts no more than 2 or 3 days before changing. A consquence of this is that Tor Metrics (atlas) shows a lot of downtime for the node. When I see that the node is down I restart the (UBUNTU) NetworkManager although the host should pick up the new address eventually without doing that? I would like to run a stable node with as little downtime as possible. Any suggestions on how I might improve things; in particular can I automate the checking and restart of the network/TOR whenever the IPV6 address changes? Do I really need to do this? On that last point, I thought that TOR nodes handled more gracefully the issue of dynamic address changes? Is there any source of info on this for dynamic IPV6 addresses? Thanks, Quentin

3 2

Tor related talks @ rC3
by nusenu 18 Jan '22

18 Jan '22

in chronological order: ------------------------------------------------------ title: Towards a more Trustworthy Tor Network when: 2021-12-28, 17:00 CET where: https://streaming.media.ccc.de/rc3/csh primary target audience: - Tor user - Tor relay operators - onion service operators - and everyone that cares about Tor ------------------------------------------------------ title: The Tor Project - State of the Onion when: 2021-12-28, 18:00 CET where: https://streaming.media.ccc.de/rc3/csh ------------------------------------------------------ -- https://nusenu.github.io

2 3

DNS Timeouts - I think the threshold for overload needs raising
by AMuse 17 Jan '22

17 Jan '22

Hi all! I'm operating a TOR Exit on dedicated hardware. The load average is low (0.07) and the network load is fine (120Mb/sec out of a 1Gb/sec link). Connections aren't being dropped, and for all I can see things are fine. However, on the TOR Metrics relay search, my exit consistently shows as "Overloaded" due to DNS failures. >From my logs, I never go above 2% in DNS failures and from the debugging I've done so far it looks like most of the failures are in IPv6 lookups not returning an AAAA record because the destination site has no AAAA configured. Could whoever runs the "Overloaded" flag consider upping the overload limit to 2% or so? Or, can we tune out ipv6 and ipv4 failures separately maybe? This was never an issue until I configured my relay for v6. =========== Jan 15 19:57:45.000 [notice] General overload -> DNS timeouts (65) fraction 1.0619% is above threshold of 1.0000% Jan 15 20:07:45.000 [notice] General overload -> DNS timeouts (67) fraction 1.0124% is above threshold of 1.0000% Jan 15 20:17:45.000 [notice] General overload -> DNS timeouts (71) fraction 1.1275% is above threshold of 1.0000% Jan 15 20:27:45.000 [notice] General overload -> DNS timeouts (94) fraction 1.4003% is above threshold of 1.0000% Jan 15 20:37:45.000 [notice] General overload -> DNS timeouts (72) fraction 1.2000% is above threshold of 1.0000% Jan 15 20:47:45.000 [notice] General overload -> DNS timeouts (75) fraction 1.2517% is above threshold of 1.0000% Jan 15 20:57:45.000 [notice] General overload -> DNS timeouts (70) fraction 1.1605% is above threshold of 1.0000% Jan 15 21:07:45.000 [notice] General overload -> DNS timeouts (92) fraction 1.6028% is above threshold of 1.0000% Jan 15 21:17:45.000 [notice] General overload -> DNS timeouts (73) fraction 1.3290% is above threshold of 1.0000% Jan 15 21:27:45.000 [notice] General overload -> DNS timeouts (73) fraction 1.2907% is above threshold of 1.0000% Jan 15 21:37:45.000 [notice] General overload -> DNS timeouts (65) fraction 1.0095% is above threshold of 1.0000% Jan 15 21:47:45.000 [notice] General overload -> DNS timeouts (83) fraction 1.2635% is above threshold of 1.0000%

2 2