Re: [tor-relays] TorWeather replacement
Thanks for all the feedback and nice ideas. Unfortunatelly it turns out that the data source I intended to use (onionoo) is less reliable than expected. To give you an example: When onionoo had a bad day, it only covered 17 instead of the expected 24 consensuses, which makes it unsuitable for an hourly monitoring granularity. In the past the natural next choice was to use stem for anything that onionoo wasn't able to do cover but since Damian is no longer maintaining stem (he no longer is at tpo), things look a bit grim there too. btw: I'm wondering if anyone is going to fork stem and continue maintaining it, it would be too bad to see stem die slowly over time. The most likely way forward with the weather replacement is probably to accept and document the onionoo reliability issues and simply don't claim to provide hourly granularity. I would still consider it to be useful even when it does not provide hourly granularity, but feel free to share your opinion if you agree/disagree. kind regards, nusenu -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New relay has a problem - Additional info about net config
Hey Olaf, I'd try the following: - restart tor - restart whole server - try setting: Address 107.189.14.123 in torrc. I have no experience with nyx and if it displays logs from tor or if some unicorns are in between, so maybe take a look if the logs written by tor itself differ from the nyx ones. The "Address '::1'" is surprising when not having IPv6 enabled at all (which is also supported by the "ip a" output). Best, fran On 2/12/22 22:03, Olaf Grimm wrote: Here info about netconfig. In the INFO messages is a part of 'Could not get local interface IP address." A mystical thing. root@localhost:~# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:16:03:e5:d6:a0 brd ff:ff:ff:ff:ff:ff altname enp0s3 altname ens3 inet 107.189.14.123/24 brd 107.189.14.255 scope global dynamic eth0 valid_lft 2583814sec preferred_lft 2583814sec root@localhost:~# Am 12.02.22 um 20:43 schrieb Olaf Grimm: 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] torrc, unit files, confusion
On Wednesday, February 16, 2022 8:07:21 AM CET Martin Gebhardt wrote: > 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 > Your '/lib/systemd/system/tor@default.service' is default like on all my Debian systems. Did you specify the whole path in '%include'? I have: # Include MyFamily & ContactInfo %include /etc/tor/torrc.all # Include Exit Policy %include /etc/tor/torrc.exit For me it is like this, the instances from the subfolders use the configs above. /etc/tor(root:root mode=drwxr-xr-x) ├── torrc.all ├── torrc.exit ├── instances ├── 00 ├── torrc ├── 01 ├── torrc ... To rule out a bug, change 'rc.d' to 'rcd'. Without dot in folder name. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reduced exit and not IPv4 exit traffic at all
On Wednesday, February 16, 2022 1:45:51 PM CET yl wrote: > how can I used a reduced exit policy and don't allow any IPv4 exit traffic? I don't think IPv6 only works. AFAIK, exits must have at least port 80,443 and 53 open on IPv4. > The following line in the top of all the ExitPolicy lines in torrc seems > not to work. > ExitPolicy reject 0.0.0.0:* What are you putting them for? All private addresses are rejected by default. > What is the order I needed here, first "reject" and then accept or the > other way around? No, as always, first come first served. > Reduced Exit policy like here: > https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy You can also take it like this. I would also delete port 22, then there would be fewer abuse mails. Before changing exit policies, read 'man torrc' carefully. SERVER OPTIONS ExitPolicy* and IPv6Exit. > But then I thought, why not disable IPv4 exit traffic, there is so many > IPv6 resources that a IPv6 only Exit should still be fine. Unfortunately, the IPv6 traffic on my relays is often close to 0 for months. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reduced exit and not IPv4 exit traffic at all
Hi , I would try the following: ExitPolicy accept [::]:20-21 # FTP, SSH, telnet ExitPolicy accept [::]:23 # FTP, SSH, telnet ExitPolicy accept [::]:43 # WHOIS [..] ExitPolicy reject *:* I would recommend that you block outgoing email ports instead of trying to block out all IPv4 traffic. I've never had any problems with ISPs and I ban outgoing email and SSH. I'm not happy with it, but it's better than being discredited by ISPs. On 2/16/22 13:45, yl wrote: Hello all, how can I used a reduced exit policy and don't allow any IPv4 exit traffic? The following line in the top of all the ExitPolicy lines in torrc seems not to work. ExitPolicy reject 0.0.0.0:* What is the order I needed here, first "reject" and then accept or the other way around? Reduced Exit policy like here: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy Webtropia was a bit unhappy lately when UCEprotect listed the whole /24 for some reason I still don't understand. But then I thought, why not disable IPv4 exit traffic, there is so many IPv6 resources that a IPv6 only Exit should still be fine. Thanks yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays OpenPGP_0x5472B866EA6CD3DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reduced exit and not IPv4 exit traffic at all
Afaik this is not possible. To get the exit flag you need both IPv4 and IPv6 or only IPv4, but IPv6 only relays are not possible. Greetings On 16.02.2022 13:45, yl wrote: Hello all, how can I used a reduced exit policy and don't allow any IPv4 exit traffic? The following line in the top of all the ExitPolicy lines in torrc seems not to work. ExitPolicy reject 0.0.0.0:* What is the order I needed here, first "reject" and then accept or the other way around? Reduced Exit policy like here: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy Webtropia was a bit unhappy lately when UCEprotect listed the whole /24 for some reason I still don't understand. But then I thought, why not disable IPv4 exit traffic, there is so many IPv6 resources that a IPv6 only Exit should still be fine. Thanks yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reduced exit and not IPv4 exit traffic at all
Hello, On 2/18/22 13:40, newslet...@unicorncloud.org wrote: Afaik this is not possible. To get the exit flag you need both IPv4 and IPv6 or only IPv4, but IPv6 only relays are not possible. I believe this changed with the last version, but I am not sure. I want to use IPv4 and IPv6, I just don't want to allow (reject) all exit to IPv4 and guess that muss be possible somehow? Regards yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] torrc, unit files, confusion
On 16.02.22 08:07, Martin Gebhardt wrote: > In the attachment [2] you can find the config with %include. There is no difference between attachment 1-torrc und 2-torrc. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reduced exit and not IPv4 exit traffic at all
On Wednesday, February 16, 2022 1:45:51 PM CET yl wrote: how can I used a reduced exit policy and don't allow any IPv4 exit traffic? tor's man page has the information on how to specify any IPv4: *4 to denote all IPv4 addresses, and *6 to denote all IPv6 addresses. I don't think IPv6 only works. AFAIK, exits must have at least port 80,443 and 53 open on IPv4. You can run a relay that does allow exiting to IPv6 and not IPv4 but it will not get the exit flag. kind regards, nusenu -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] torrc, unit files, confusion
Hi, The problem is solved. There is a conflict between the recursive function of %include and the AppArmor profile. This can be traced here in line 27: https://gitlab.torproject.org/tpo/core/debian/tor/-/blob/debian-main/debian/tor.apparmor-profile.abstraction Because the list was down for a few days, I opened the topic in the forum. If you are interested, you can see the way to solution here: https://forum.torproject.net/t/torrc-unit-files-confusion/2217 -- Martin On 2/18/22 15:24, li...@for-privacy.net wrote: On Wednesday, February 16, 2022 8:07:21 AM CET Martin Gebhardt wrote: 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 Your '/lib/systemd/system/tor@default.service' is default like on all my Debian systems. Did you specify the whole path in '%include'? I have: # Include MyFamily & ContactInfo %include /etc/tor/torrc.all # Include Exit Policy %include /etc/tor/torrc.exit For me it is like this, the instances from the subfolders use the configs above. /etc/tor(root:root mode=drwxr-xr-x) ├── torrc.all ├── torrc.exit ├── instances ├── 00 ├── torrc ├── 01 ├── torrc ... To rule out a bug, change 'rc.d' to 'rcd'. Without dot in folder name. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays OpenPGP_0x5472B866EA6CD3DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
