Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98
Dr Gerard Bulger: > Torrc allows you to exit from a different IP. I thought it a good > idea to stop arbitrary blocking of the advertised Tor exit IP, the > captchas and blacklists that tor users suffer. When IPv6 implemented > fully we have a wide range of IPs to send from on each server. > > Perhaps it is not considered good form to do so as the internet > should know who is using Tor. > > So what is the problems for TOR security when exits set up to send > from a different IP? Is it that we do not know what the second IP > is up to in dealing with the IP4 traffic from the exit? simplified: there can be two reasons for inbound (OR) IP != exit IP: a) the exit used https://2019.www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit or some form of NAT b) the exit relay uses an tor client to route its traffic back into tor This exit was doing (b), I think you are referring to (a) which is perfectly fine. -- https://mastodon.social/@nusenu signature.asc 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] BadExit: Rerouting exit relays detected (1) 45.63.11.98
niftybunny: > Just woke up. So, whats wrong with some of my relays in this list? some "exit" relay routed its traffic back into tor by using a tor client. That tor client used exit relays - yours were among them. So nothing wrong on your side. signature.asc 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] Collaborative Bad-Abuse-Sender Blocklist
My ISP (Hurricane Electric) forwards me support tickets with abuse emails they receive, and asks that I respond to their ticket with information so they can show that they did their duty as an ISP in informing me. Because I typically get floods of this abuse-SPAM from only a few dedicated companies, I created procmail rules to autorespond to my ISP (so they can close their ticket as requested) and CC the sender of that junk every single time. I'm sure my email to them goes into a black hole, but their email to me goes into one as well, so it's just robots emailing robots. A waste of resources, but at least no longer a waste of my time. - procmailrc rule --- :0 B: * antipir...@p2p.opsecsecurity.com | (formail -r \ -A "Cc: antipir...@p2p.opsecsecurity.com" \ -A "X-Loop: tor-abuse@MYDOMAIN" \ cat /home/tormail/.procmail/opsecsecurity-autoresponse ) | $SENDMAIL -t -oi - text content - Hello; I am the operator of the server using the IP in question. That server is a Tor exit node, and keeps no records of who is using it for any particular purpose or connection. More information is available at http://74.82.47.194/ I recommend you obtain the official list of Tor nodes ( https://dist.torproject.org/tordnsel/) and use them to filter automated notices in the future, or to block exits from accesing whatever content you'd like accessed via automated ingestion of firewall rules. - On Mon, Oct 12, 2020 at 1:35 AM Tortilla wrote: > > > On 9/28/20 1:54 PM, Matt Corallo wrote: > > > >> Different folks have different views on abuse reports, and that's > >> perfectly OK. But "taking it up with list XYZ" isn't > >> going to change that (see discussion on NANOG a few months ago on this > >> very topic =D) - people are always going to have > >> their own views on who's responsibility it is to solve "abuse" (under > >> their current definition). > > What are you defining it as here? I can't see that there is going to be > much disagreement that abuse such as what these reports are probably about > can only be solved at the hosting provider or ISP level where it > originates. No one else has the ability to do anything about it. The > problem you are identifying is that there are a lot of over-zealous or > poorly written automated scripts that like to notify abuse sources without > much intelligence in regard to rate limiting or response handling, etc. I > think if you create a thoughtful message to include in your rejection > text, it is absolutely within reason to try and let them know that they > are becoming part of the problem if they don't engage with you. > > Of course, it's important to note in this context that there's still a lot > of education that has to happen about what Tor is and/or reminding > operators of those automated systems that they should skip Tor relays. > > >> My personal abuse > >> policy is "I reach try to help you, but if you keep sending the same > >> automated stuff over and over and don't reply when > >> I reach out, I drop your mails". > > It's hard to create a globally applicable blocklist for something like > this of any size, since by definition, you have to try to work with them > manually before adding anyone to the list. I certainly don't blame you for > keeping and sharing such a list, though. > > On Fri, October 9, 2020 7:13 pm, Mike Perry wrote: > > > > Absolutely. I suspect the problem is ideological. The abuse resolution > > camp seems to be largely subscribe to the "force ISPs to identify > > abusers and ban them" model. They do not want to hear about mitigation > > strategies or alternatives, other than their banhammer and abuse notice > > spamming approaches. Making a banlist of banhammer spammers like that is > > a brilliant move. > > What is this problematic ideology you are pointing out? What is your > alternative? Why do you think it's so terrible to alert ISPs and hosting > providers about abuse originating from their systems? I find those alerts > immensely helpful as opposed to finding out some time later that a system > I manage is on some RBL or other block list. Not that many want to share > their intelligence gathering (especially spamtrap data), so getting alerts > can be highly valuable and quite welcome to a lot of operators. > > Just because there are some systems that send out notices relentlessly > with poor rate limiting and no knowledge of Tor relays/exits does not mean > the model itself is wrong-headed. It just means some people wrote some > naive notification systems (and as Matt found, they may be poor at actual > engagement or do not provide a means to opt out). ISPs and hosting > providers can and should be notified about abuse activity and they should > be held responsible for shutting down abusive actors on their networks. > Whether or not the recipient of the abuse mitigates its effects is beside > the point. > > > I grew so tired of my perso
Re: [tor-relays] Relay JPsi2 not getting into consensus anymore
>The provider said it was due to Spectre mitigations and the only way for me to fix this would be to switch to a newer (more expensive) plan... What? Your provider lied to you / scammed you, Spectre/Meltdown etc. mitigations have nothing to do with applications freezing or having to get a faster downstream/upstream speed.. at worst there's a 5-10% performance hit if you don't have the newest CPU microcode installed and an OS that makes use of the new insturctions (use the latest linux kernel and intel-ucode if you can). 2020-10-11 16:48 GMT, Random Tor Node Operator : > Hi all, > > some weeks ago, my relay JPsi2 > (F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521) started experiencing moderate > stability problems. It would freeze after a few hours or days. The > provider said it was due to Spectre mitigations and the only way for me > to fix this would be to switch to a newer (more expensive) plan... > > Some time later I did so and reinstalled it with Ubuntu 18.04 and placed > the old keys into the new installation. It seems they are now expected > to be in /var/lib/tor/.tor/keys, as opposed to /var/lib/tor/keys as I > was used to in Ubuntu 16.04. > > However, it does not seem to be making it into the consensus anymore. > Only the authority nodes moria1, dizum, and longclaw vote for Running. > The others don't. > > So far I haven't been able to figure out the reason for that, so any > help is appreciated. > > Here is part of the output of journalctl -u tor and the torrc file: > > > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] Heartbeat: It seems like we are not in the cached > consensus. > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] Heartbeat: Tor's uptime is 8 days 0:00 hours, with > 0 circuits open. I've sent 54.04 MB and received 163.30 MB. > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] While bootstrapping, fetched this many bytes: > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 9368438 (server descriptor fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 1060775 (consensus network-status fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 13332 (authority cert fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 2762395 (microdescriptor fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] While not bootstrapping, fetched this many bytes: > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 111548029 (server descriptor fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 100899 (server descriptor upload) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 15307429 (consensus network-status fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 1785 (authority cert fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] 942746 (microdescriptor fetch) > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] Average packaged cell fullness: 96.710%. TLS write > overhead: 31% > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] Circuit handshake stats since last time: 1/1 TAP, > 0/0 NTor. > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] Since startup we initiated 0 and received 0 v1 > connections; initiated 0 and received 2 v2 connections; initiated 0 and > received 114 v3 connections; initiated 0 and received 1899 v4 > connections; initiated 46 and received 5694 v5 connections. > Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 > 15:04:32.000 [notice] DoS mitigation since startup: 0 circuits killed > with too many cells. 0 circuits rejected, 0 marked addresses. 0 > connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. > Oct 11 18:14:03 j60204.servers. > > > # cat /etc/tor/torrc > OfflineMasterKey 1 > SOCKSPort 0 > SOCKSPolicy reject * > RunAsDaemon 1 > ControlPort 9051 > HashedControlPassword > 16:28CD63819CB35660601EB9CED4BC2A4252D3DB80488DFD4F22CA4AE930 > ORPort 9001 > ORPort [2a00:1158:3::1ba]:9001 > Nickname JPsi2 > RelayBandwidthRate 12500 KB > RelayBandwidthBurst 12500 KB > ContactInfo 0xF1ADC390 Random Tor Node Operator (dot) de> bitcoin:1LBoEppezy2HauE957HzfFn9UGywK6aboB > DirPort 9030 > MyFamily $B198C0B4B8C551F174FBB841A172616E3DB3124D, > $F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 > IPv6Exit 0 > ExitPolicy reject *:* > ExitPolicy reject6 *:* > > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listi
Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98
Torrc allows you to exit from a different IP. I thought it a good idea to stop arbitrary blocking of the advertised Tor exit IP, the captchas and blacklists that tor users suffer. When IPv6 implemented fully we have a wide range of IPs to send from on each server. Perhaps it is not considered good form to do so as the internet should know who is using Tor. So what is the problems for TOR security when exits set up to send from a different IP? Is it that we do not know what the second IP is up to in dealing with the IP4 traffic from the exit? Gerry -Original Message- From: tor-relays On Behalf Of li...@for-privacy.net Sent: 11 October 2020 23:13 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98 On 11.10.2020 22:41, Roger Dingledine wrote: > Right, in this particular case, we already run a scanner which > provides public output: it's the tordnsel scanner, and check out > https://check.torproject.org/exit-addresses Damn it, the boy was hardworking. ExitNode 385527185E26937D05E0933DD29FF1699056CAF3 Published 2020-10-11 11:54:00 LastStatus 2020-10-11 17:00:00 ExitAddress 185.220.102.252 2020-10-11 17:52:50 ExitAddress 45.154.35.218 2020-10-11 17:13:21 ExitAddress 45.63.11.98 2020-10-11 09:19:06 ExitAddress 51.158.111.157 2020-10-10 23:51:28 ExitAddress 45.154.35.219 2020-10-10 20:14:28 ExitAddress 185.220.101.207 2020-10-10 18:10:02 ExitAddress 185.140.53.7 2020-10-10 15:04:52 ExitAddress 23.129.64.205 2020-10-10 09:14:15 ExitAddress 23.129.64.100 2020-10-10 06:10:30 ExitAddress 185.220.100.240 2020-10-10 03:41:38 ExitAddress 23.129.64.207 2020-10-09 21:04:35 ExitAddress 23.129.64.209 2020-10-09 19:31:42 ExitAddress 23.129.64.212 2020-10-09 15:18:55 ExitAddress 185.107.47.215 2020-10-09 12:02:09 ExitAddress 45.154.35.216 2020-10-09 09:11:20 ExitAddress 162.247.74.7 2020-10-09 08:10:41 ExitAddress 45.154.35.214 2020-10-09 04:27:16 ExitAddress 130.225.244.90 2020-10-09 03:34:52 ExitAddress 46.165.245.154 2020-10-08 22:09:32 ExitAddress 185.220.102.248 2020-10-08 21:13:44 ExitAddress 45.154.35.211 2020-10-08 15:17:28 ExitAddress 45.154.35.213 2020-10-08 14:52:41 ExitAddress 185.140.53.9 2020-10-08 12:42:16 ExitAddress 145.239.92.26 2020-10-08 11:34:41 ExitAddress 185.140.53.5 2020-10-08 09:39:55 ExitAddress 51.195.150.250 2020-10-08 05:42:51 ExitAddress 185.220.102.247 2020-10-08 04:38:46 ExitAddress 51.83.139.56 2020-10-08 02:41:35 ExitAddress 216.239.90.19 2020-10-07 22:10:28 ExitAddress 35.0.127.52 2020-10-07 21:46:15 ExitAddress 185.220.102.241 2020-10-07 20:04:33 ExitAddress 45.154.35.220 2020-10-07 17:28:29 ExitAddress 209.141.39.33 2020-10-07 15:49:11 ExitAddress 185.220.101.10 2020-10-07 12:39:45 ExitAddress 185.220.101.200 2020-10-07 05:12:35 ExitAddress 51.195.149.132 2020-10-06 19:26:01 ExitAddress 45.154.35.212 2020-10-06 18:39:37 ExitAddress 179.43.167.226 2020-10-06 12:55:24 ExitAddress 185.220.102.242 2020-10-06 09:04:52 ExitAddress 162.247.74.201 2020-10-05 11:44:18 ExitAddress 45.154.35.210 2020-10-05 09:59:58 ExitAddress 51.75.144.43 2020-10-05 01:24:36 ExitAddress 185.220.100.250 2020-10-04 12:52:37 ExitAddress 94.142.244.16 2020-10-04 09:26:13 ExitAddress 45.154.35.215 2020-10-04 08:15:17 ExitAddress 185.220.102.243 2020-10-03 20:13:45 ExitAddress 5.79.109.48 2020-10-03 16:56:19 ExitAddress 54.36.108.162 2020-10-02 18:11:45 ExitAddress 209.141.61.129 2020-10-01 21:48:30 ExitAddress 18.27.197.252 2020-10-01 18:26:32 ExitAddress 51.178.43.104 2020-10-01 15:39:56 ExitAddress 185.220.100.252 2020-10-01 07:57:36 ExitAddress 185.220.102.8 2020-10-01 06:29:39 ExitAddress 51.81.83.151 2020-09-30 21:55:17 ExitAddress 185.220.102.253 2020-09-30 17:52:13 ExitAddress 37.120.152.116 2020-09-30 13:25:01 ExitAddress 162.247.74.200 2020-09-30 11:02:05 ExitAddress 185.220.100.241 2020-09-30 10:44:36 ExitAddress 45.129.56.200 2020-09-30 07:52:31 ExitAddress 171.25.193.77 2020-09-29 17:15:03 ExitAddress 185.220.101.205 2020-09-28 22:13:13 ExitAddress 198.251.89.136 2020-09-28 15:27:51 ExitAddress 193.218.118.140 2020-09-28 12:39:45 ExitAddress 185.220.101.199 2020-09-28 05:45:20 ExitAddress 85.248.227.165 2020-09-28 00:42:28 ExitAddress 185.220.101.148 2020-09-27 18:58:16 https://metrics.torproject.org/rs.html#search/185.220. niftybunny, Zwiebelfreunde, Digitalcourage & F3Netze help each other but have their machines in different IX. They don't throw their IPs from the separate ASNs onto one machine. ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! ___ 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] Collaborative Bad-Abuse-Sender Blocklist
> On 9/28/20 1:54 PM, Matt Corallo wrote: > >> Different folks have different views on abuse reports, and that's >> perfectly OK. But "taking it up with list XYZ" isn't >> going to change that (see discussion on NANOG a few months ago on this >> very topic =D) - people are always going to have >> their own views on who's responsibility it is to solve "abuse" (under >> their current definition). What are you defining it as here? I can't see that there is going to be much disagreement that abuse such as what these reports are probably about can only be solved at the hosting provider or ISP level where it originates. No one else has the ability to do anything about it. The problem you are identifying is that there are a lot of over-zealous or poorly written automated scripts that like to notify abuse sources without much intelligence in regard to rate limiting or response handling, etc. I think if you create a thoughtful message to include in your rejection text, it is absolutely within reason to try and let them know that they are becoming part of the problem if they don't engage with you. Of course, it's important to note in this context that there's still a lot of education that has to happen about what Tor is and/or reminding operators of those automated systems that they should skip Tor relays. >> My personal abuse >> policy is "I reach try to help you, but if you keep sending the same >> automated stuff over and over and don't reply when >> I reach out, I drop your mails". It's hard to create a globally applicable blocklist for something like this of any size, since by definition, you have to try to work with them manually before adding anyone to the list. I certainly don't blame you for keeping and sharing such a list, though. On Fri, October 9, 2020 7:13 pm, Mike Perry wrote: > > Absolutely. I suspect the problem is ideological. The abuse resolution > camp seems to be largely subscribe to the "force ISPs to identify > abusers and ban them" model. They do not want to hear about mitigation > strategies or alternatives, other than their banhammer and abuse notice > spamming approaches. Making a banlist of banhammer spammers like that is > a brilliant move. What is this problematic ideology you are pointing out? What is your alternative? Why do you think it's so terrible to alert ISPs and hosting providers about abuse originating from their systems? I find those alerts immensely helpful as opposed to finding out some time later that a system I manage is on some RBL or other block list. Not that many want to share their intelligence gathering (especially spamtrap data), so getting alerts can be highly valuable and quite welcome to a lot of operators. Just because there are some systems that send out notices relentlessly with poor rate limiting and no knowledge of Tor relays/exits does not mean the model itself is wrong-headed. It just means some people wrote some naive notification systems (and as Matt found, they may be poor at actual engagement or do not provide a means to opt out). ISPs and hosting providers can and should be notified about abuse activity and they should be held responsible for shutting down abusive actors on their networks. Whether or not the recipient of the abuse mitigates its effects is beside the point. > I grew so tired of my personal email sever constantly ending up in > DNSRBLs for no reason (even with DKIM and SPF), that after 20 years of > DIY email, I was forced to moved to paid provider. I hear personal frustration rather than pointing out any problem. Keeping an email server clear of RBLs is real work, but also not that hard if you try (make sure you aren't renting in a cheap neighborhood where spammers are allowed to flourish, don't run it on the same IP as a Tor node (especially if you exit port 25), enforce good password policy, rate limit or monitor your outgoing mail flow, etc.). I doubt anyone "forced" you... rather, you didn't have the expertise or time and felt the tradeoff was worth paying someone else to take on that work. > This model is broken, its assumptions are contrary to our values What, that abuse should never be pointed out and we "just deal with it" and let it proliferate? Are "our values" that everyone should have perfectly hardened systems against all possible forms of attack and ignore all responsibility of the originating side... because anyone should be free to do what they want with their device on the network?? Tor is of great value, but you have to see that it is in a unique position and that the standard Tor operator's response of "it didn't originate here and I don't know where it did, so no one can help you with this" is a bitter pill to swallow for people who are trying to chase down abusive actors. That's the way it is - a trade-off we have to accept for a certain freedom and anonymity on the net, but you are conflating ill-informed and ill-constructed notification bots acting on Tor nodes (and your unfortunate experience tryin
Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98
Just woke up. So, whats wrong with some of my relays in this list? nifty > On 12. Oct 2020, at 00:13, li...@for-privacy.net wrote: > > On 11.10.2020 22:41, Roger Dingledine wrote: > >> Right, in this particular case, we already run a scanner which provides >> public output: it's the tordnsel scanner, and check out >> https://check.torproject.org/exit-addresses > > Damn it, the boy was hardworking. > > ExitNode 385527185E26937D05E0933DD29FF1699056CAF3 > Published 2020-10-11 11:54:00 > LastStatus 2020-10-11 17:00:00 > ExitAddress 185.220.102.252 2020-10-11 17:52:50 > ExitAddress 45.154.35.218 2020-10-11 17:13:21 > ExitAddress 45.63.11.98 2020-10-11 09:19:06 > ExitAddress 51.158.111.157 2020-10-10 23:51:28 > ExitAddress 45.154.35.219 2020-10-10 20:14:28 > ExitAddress 185.220.101.207 2020-10-10 18:10:02 > ExitAddress 185.140.53.7 2020-10-10 15:04:52 > ExitAddress 23.129.64.205 2020-10-10 09:14:15 > ExitAddress 23.129.64.100 2020-10-10 06:10:30 > ExitAddress 185.220.100.240 2020-10-10 03:41:38 > ExitAddress 23.129.64.207 2020-10-09 21:04:35 > ExitAddress 23.129.64.209 2020-10-09 19:31:42 > ExitAddress 23.129.64.212 2020-10-09 15:18:55 > ExitAddress 185.107.47.215 2020-10-09 12:02:09 > ExitAddress 45.154.35.216 2020-10-09 09:11:20 > ExitAddress 162.247.74.7 2020-10-09 08:10:41 > ExitAddress 45.154.35.214 2020-10-09 04:27:16 > ExitAddress 130.225.244.90 2020-10-09 03:34:52 > ExitAddress 46.165.245.154 2020-10-08 22:09:32 > ExitAddress 185.220.102.248 2020-10-08 21:13:44 > ExitAddress 45.154.35.211 2020-10-08 15:17:28 > ExitAddress 45.154.35.213 2020-10-08 14:52:41 > ExitAddress 185.140.53.9 2020-10-08 12:42:16 > ExitAddress 145.239.92.26 2020-10-08 11:34:41 > ExitAddress 185.140.53.5 2020-10-08 09:39:55 > ExitAddress 51.195.150.250 2020-10-08 05:42:51 > ExitAddress 185.220.102.247 2020-10-08 04:38:46 > ExitAddress 51.83.139.56 2020-10-08 02:41:35 > ExitAddress 216.239.90.19 2020-10-07 22:10:28 > ExitAddress 35.0.127.52 2020-10-07 21:46:15 > ExitAddress 185.220.102.241 2020-10-07 20:04:33 > ExitAddress 45.154.35.220 2020-10-07 17:28:29 > ExitAddress 209.141.39.33 2020-10-07 15:49:11 > ExitAddress 185.220.101.10 2020-10-07 12:39:45 > ExitAddress 185.220.101.200 2020-10-07 05:12:35 > ExitAddress 51.195.149.132 2020-10-06 19:26:01 > ExitAddress 45.154.35.212 2020-10-06 18:39:37 > ExitAddress 179.43.167.226 2020-10-06 12:55:24 > ExitAddress 185.220.102.242 2020-10-06 09:04:52 > ExitAddress 162.247.74.201 2020-10-05 11:44:18 > ExitAddress 45.154.35.210 2020-10-05 09:59:58 > ExitAddress 51.75.144.43 2020-10-05 01:24:36 > ExitAddress 185.220.100.250 2020-10-04 12:52:37 > ExitAddress 94.142.244.16 2020-10-04 09:26:13 > ExitAddress 45.154.35.215 2020-10-04 08:15:17 > ExitAddress 185.220.102.243 2020-10-03 20:13:45 > ExitAddress 5.79.109.48 2020-10-03 16:56:19 > ExitAddress 54.36.108.162 2020-10-02 18:11:45 > ExitAddress 209.141.61.129 2020-10-01 21:48:30 > ExitAddress 18.27.197.252 2020-10-01 18:26:32 > ExitAddress 51.178.43.104 2020-10-01 15:39:56 > ExitAddress 185.220.100.252 2020-10-01 07:57:36 > ExitAddress 185.220.102.8 2020-10-01 06:29:39 > ExitAddress 51.81.83.151 2020-09-30 21:55:17 > ExitAddress 185.220.102.253 2020-09-30 17:52:13 > ExitAddress 37.120.152.116 2020-09-30 13:25:01 > ExitAddress 162.247.74.200 2020-09-30 11:02:05 > ExitAddress 185.220.100.241 2020-09-30 10:44:36 > ExitAddress 45.129.56.200 2020-09-30 07:52:31 > ExitAddress 171.25.193.77 2020-09-29 17:15:03 > ExitAddress 185.220.101.205 2020-09-28 22:13:13 > ExitAddress 198.251.89.136 2020-09-28 15:27:51 > ExitAddress 193.218.118.140 2020-09-28 12:39:45 > ExitAddress 185.220.101.199 2020-09-28 05:45:20 > ExitAddress 85.248.227.165 2020-09-28 00:42:28 > ExitAddress 185.220.101.148 2020-09-27 18:58:16 > > https://metrics.torproject.org/rs.html#search/185.220. > niftybunny, Zwiebelfreunde, Digitalcourage & F3Netze help each other but have > their machines in different IX. They don't throw their IPs from the separate > ASNs onto one machine. ;-) > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you freedom! > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay JPsi2 not getting into consensus anymore
Hi all, some weeks ago, my relay JPsi2 (F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521) started experiencing moderate stability problems. It would freeze after a few hours or days. The provider said it was due to Spectre mitigations and the only way for me to fix this would be to switch to a newer (more expensive) plan... Some time later I did so and reinstalled it with Ubuntu 18.04 and placed the old keys into the new installation. It seems they are now expected to be in /var/lib/tor/.tor/keys, as opposed to /var/lib/tor/keys as I was used to in Ubuntu 16.04. However, it does not seem to be making it into the consensus anymore. Only the authority nodes moria1, dizum, and longclaw vote for Running. The others don't. So far I haven't been able to figure out the reason for that, so any help is appreciated. Here is part of the output of journalctl -u tor and the torrc file: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: Tor's uptime is 8 days 0:00 hours, with 0 circuits open. I've sent 54.04 MB and received 163.30 MB. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 9368438 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1060775 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 13332 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 2762395 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While not bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 111548029 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 100899 (server descriptor upload) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 15307429 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1785 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 942746 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Average packaged cell fullness: 96.710%. TLS write overhead: 31% Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Circuit handshake stats since last time: 1/1 TAP, 0/0 NTor. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 2 v2 connections; initiated 0 and received 114 v3 connections; initiated 0 and received 1899 v4 connections; initiated 46 and received 5694 v5 connections. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Oct 11 18:14:03 j60204.servers. # cat /etc/tor/torrc OfflineMasterKey 1 SOCKSPort 0 SOCKSPolicy reject * RunAsDaemon 1 ControlPort 9051 HashedControlPassword 16:28CD63819CB35660601EB9CED4BC2A4252D3DB80488DFD4F22CA4AE930 ORPort 9001 ORPort [2a00:1158:3::1ba]:9001 Nickname JPsi2 RelayBandwidthRate 12500 KB RelayBandwidthBurst 12500 KB ContactInfo 0xF1ADC390 Random Tor Node Operator bitcoin:1LBoEppezy2HauE957HzfFn9UGywK6aboB DirPort 9030 MyFamily $B198C0B4B8C551F174FBB841A172616E3DB3124D, $F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 IPv6Exit 0 ExitPolicy reject *:* ExitPolicy reject6 *:* signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
