Re: [tor-relays] Why does my relay often appears offline in Metrics and should I be worry?
Hi there, > On 19. Apr 2020, at 02:25, Roger Dingledine wrote: > > On Sat, Apr 18, 2020 at 10:16:34AM +0200, Clément Février wrote: >> The issue is back. After more than 3 days, the relay appears offline. >> All flags are gone in nyx. There is a bug. > > I believe there is something wrong with your ipv6 port. indeed there is something wrong. I am voting against you because I cannot reach you via IPv6. A traceroute to you seems to die somewhere inside OVH: 11 th2-dsl1-a1.fr.eu (2001:41d0::b76) 12.944 ms be45.th2-dsl1a-n93.fr.eu (2001:41d0::b72) 13.035 ms 13.103 ms 12 2001:41d0:fde0:80::30 (2001:41d0:fde0:80::30) 12.637 ms 12.595 ms 12.549 ms 13 2001:41d0:fecf:8900:5ee2:8cff:fe99:f106 (2001:41d0:fecf:8900:5ee2:8cff:fe99:f106) 22.724 ms 22.759 ms 21.971 ms 14 2001:41d0:fecf:8900:5ee2:8cff:fe99:f106 (2001:41d0:fecf:8900:5ee2:8cff:fe99:f106) 3029.525 ms !H 3022.011 ms !H 3022.124 ms !H > So I would suggest removing the ipv6 stuff for a while and see if things > get better for you. > > And then also exploring why your ipv6 address is not consistently > routable, or not consistently reachable, or whatever else is going wrong > with it. That seems quite worthwhile to figure out. Basically, your computer isn't really online right now ;) Cheers Sebastian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why does my relay often appears offline in Metrics and should I be worry?
On Sat, Apr 18, 2020 at 10:16:34AM +0200, Clément Février wrote: > The issue is back. After more than 3 days, the relay appears offline. > All flags are gone in nyx. There is a bug. I believe there is something wrong with your ipv6 port. I see that your relay is advertising [2001:41d0:fecf:8900:216:3eff:fe8a:e4a6]:9001 and when I go to https://bridges.torproject.org/scan/ and put in "[2001:41d0:fecf:8900:216:3eff:fe8a:e4a6]" and "9001", it tells me "i/o timeout". So I would suggest removing the ipv6 stuff for a while and see if things get better for you. And then also exploring why your ipv6 address is not consistently routable, or not consistently reachable, or whatever else is going wrong with it. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (Без темы)
> TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.
> Check
> SNMP counters.
> what it can mean? also my 2 relays go offline for a few hours once a day,
> then
> are restored.
The TCP protocol builds a new connection by the client sending a SYN
packet to the server, the server responding with a SYN+ACK packet and
then the client responding with an ACK packet:
Client Server
| |
| -SYN--> |
| |
| <---SYN+ACK |
| |
| -ACK--> |
{connection established}
The server must somehow keep track of the connections during that
handshake and the naïve way of doing that is having a queue that hold
information on them. The client must do the same, by the way.
Now imagine that someone sends a ton of SYN packets to the server,
without ever having intention of making a connection and therefore not
keeping track of them. The poor server responds with SYN+ACKs and keeps
half-open connections in the queue in a hope that the client will send
the final ACK packet: but that one will never arrive. That may fill up
the queue quickly and if a normal client tries to connect, it can’t
because the queue is full. That kind of an DoS attack is based on
assymetry between the resources needed by the attacker and the victim:
the victim will dedicate its resources to half-open connections, while
the attacker just sends SYN packets without ever storing anything.
Attacker Server queue
| | [ ][ ][ ][ ][ ][ ]
| -SYN--> | [x][ ][ ][ ][ ][ ]
| <---SYN+ACK | [x][ ][ ][ ][ ][ ]
| -SYN--> | [x][x][ ][ ][ ][ ]
| <---SYN+ACK | [x][x][ ][ ][ ][ ]
| -SYN--> | [x][x][x][ ][ ][ ]
| <---SYN+ACK | [x][x][x][ ][ ][ ]
| -SYN--> | [x][x][x][x][ ][ ]
| <---SYN+ACK | [x][x][x][x][ ][ ]
| -SYN--> | [x][x][x][x][x][ ]
| <---SYN+ACK | [x][x][x][x][x][ ]
| -SYN--> | [x][x][x][x][x][x] full
| <---SYN+ACK | [x][x][x][x][x][x] full
' | .
| .
Honest client | .
| | .
| -SYN--> | [x][x][x][x][x][x] full
:( :(
Here the story of “Possible SYN flooding on port 80” ends. That is
what a SYN flood is.
A way to prevent that type of an attack is to not store information on
the server. Instead, the server uses the protocol in a creative way to
store the information in the SYN+ACK packet itself (in the sequence
number, as SYN cookies). A honest client must then respond with an ACK
packet that contains a predictably modified information, which can be
used to reconstruct the original one. Only then actual resources are
assigned to the connection. Of course an attacker may till simply open a
ton of connections, but this way there is a symmetry between resources
required by both sides. Yes, the server may have their resources
exhausted by the attacker, but the attacker must allocate as much
resources to the attack. That method, however, has its drawbacks and
therefore is applied only if an actual attack is suspected. That’s what
“Sending cookies” means.
What causes your nodes to go down is harder to tell. If both events
are clearly correlated, something may be actually making a large number
of connections, overloarding the nodes and making them unavailable to
honest clients. That has happened in the past, with hundreds and
hundreds of simulaneaous connections suddenly appearing from a limited
range of addresses. SYN cookies will not prevent that in any way (it’s
not their job), but the SYN flood prevention mechanism firing may be a
sign that a ton of TCP connections are being established fast.
You may try to debug that by collecting information on connections to
you node. E.g. by executing `ss` (possibly `netstat` on some systems)
periodically (for example each 15s) to count connections to the node
(and only them), counting them and logging that information over many
days, including some unwanted events you have described, and then see if
you see any correlation.
BTW: using Latin script and English for the title will increase
chances of getting attention. Otherwise people may even simply filter
out your messages “visually”, assuming it’s spam. :)
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] Why does my relay often appears offline in Metrics and should I be worry?
On 09/04/2020 20:56, Michael Gerstacker wrote: > Am Do., 9. Apr. 2020 um 15:39 Uhr schrieb Clément Février > mailto:clem...@forumanalogue.fr>>: > > Hello, > > I often check my relay trough Metrics, but it often appears as offline > after some time, from couple of hours to few days. I think it has this > behavior since December 20. However, my relay seems to run normally. I > have the usual number of connections when I check in Nyx. I don't see > anything in the log. > But, in Nyx, I don't see the flags that I see when it appears as online > in Metrics. > What I do is to restart the service, but I'm not sure if it's what I'm > suppose to do. > > > I had the same problem some days ago but only once. > The relay was shown as offline on Metrics and all flags in nyx were gone. > I did not saw anything strange in the logfile and a reboot did not > solved the problem. > > The next morning everything was back to normal. > > I switched it from a non-exit to an exit the day before and was still > messing around with the Exit policy so i thought it was related to this. > > Fingerprint: > DAA806E9529D77EF94685FC0E513386EF65B83F8 The issue is back. After more than 3 days, the relay appears offline. All flags are gone in nyx. There is a bug. How to be notified when there is a issue with our relay? Clèm ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Got my first abuse
On 17.04.2020 21:13, Kolja Sagorski wrote: No, it was in a datacenter. Here the case https://www.lawblog.de/index.php/archives/2018/02/13/strafbare-beihilfe-durch-einen-tor-server/ That was only 2 years ago. :-( I live in Bonn, the same state. And I still have things somewhere on old HD's that were legal before 9/11. (Sprengstoff e.V.) It is probably not bad to be prepared. Can someone recommend lawyers to me. Please email. Does anyone know a German IRC channel or similar, where German exit operators exchange ideas? One could possibly found an association like Torservers.net. The address could be the C4 (Chaos Computer Club Cologne) or our Freifunk Treff in Bonn. -- ╰_╯ 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
Re: [tor-relays] Help with torrc for Bridge
On 17.04.2020 11:46, ylms wrote: Hello Marco On 4/17/20 11:32 AM, li...@for-privacy.net wrote: On 17.04.2020 11:05, i forget: On 17.04.2020 10:03, ylms wrote: ORPort 443 + ORPort [YOUR:V6:IP]:443 So I should use ORPort twice, once for IPv4 and once for IPv6? Yes. IPv4 only Port & IPv6 with brackets: [YOUR:V6:IP]:Port ## If you have multiple network interfaces, specify one for outgoing traffic to use. OutboundBindAddress IPv4 OutboundBindAddress [YOUR:IP:V6] OK, I will add that. What is the option "OutboundBindAddressOR" for? Should I use that too? Normally not needed. Make all outbound non-exit (relay and other) connections originate from the IP address specified. This option overrides OutboundBindAddress for the same IP version. OutboundBindAddress OutboundBindAddressOR OutboundBindAddressExit is only useful when you have multiple network interfaces or IP's. SocksPort 0 BridgeRelay 1 ## uncomment if you don't want torproject.org to know your bridge #PublishServerDescriptor 0 no, I want the relay to be distributed by the various services that torprojects.org is offering. It's a good thing. Just wanted to point out the option. ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:80 ## The ServerTransportListenAddr line is dual stack friendly. ServerTransportListenAddr obfs4 [::]:80 So I'll add another line for IPv6 here too. You only need it once. Change 0.0.0.0:80 to [::]:80. You then have IPv4 and IPv6. ServerTransportListenAddr obfs4 [::]:80 ExtORPort auto CookieAuthentication 1 ExitPolicy reject *:* ExitPolicy reject6 *:* ClientUseIPv6 1 Not used. For Clients. you're right, somehow I must have copied that over from somewhere. #%include /etc/tor/torrc_family ^^^Not needed for Tor Bridge OK. //End of torrc ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- ╰_╯ 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] (Без темы)
TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters.what it can mean? also my 2 relays go offline for a few hours once a day, then are restored. С уважением,Станислав ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Got my first abuse
On 04/17/2020 02:02 AM, Volker Mink wrote: > you call it dumb. > other call i coursageous. > it was worth a try. i have decent internet connection at home and could > provide > a reliable and fast exit for close to a year. > TOR needs brave people. Well, that does provide residential IPs. And there's quite the demand for VPN services with them, because they're less likely blocked. And so more useful for streaming Disney+ or whatever. But with Tor, all relay IPs are (so far) published, so it doesn't help at all. > *Gesendet:* Freitag, 17. April 2020 um 04:08 Uhr > *Von:* "Ralph Seichter" > *An:* tor-relays@lists.torproject.org > *Betreff:* Re: [tor-relays] Got my first abuse > * Volker Mink: > > > I was running an exit at my home connection for close to one year. I > > removed it because normal internet usage became absolutely anoying. > > Capchas and DOS-Protections nearly everywhere. No streaming-portal > > was running. And lots of complaints from my provider. > > Which fully confirms that running a Tor exit at home is usually a dumb > move, police involvement or not. > > -Ralph > ___ > 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 > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 100% CPU at random rate
Thanks Gisle and petrarca for confirming that. I thought this is because
of my messed-up OS only.
I linked this thread to the trac's ticket #33554 to for more info on
that.
On 17.04.2020 21:27, Gisle Vanem wrote:
>> My problem is, and long time has been, the following. Every 30-40-60-120
>> minutes (it varies) I suddenly see CPU consumption jumps to 100% because
>> of tor process, so I need to stop/start it to settle things down. Also,
>> when I start Tor after a period of inactivity, say, a few hours or
>> night, I cannot start it reliably for the first time, ever. It goes up
>> to "Bootstrapped 95% (circuit_create): Establishing a Tor circuit" log
>> message and... 100% CPU. After the second start, I get 100% CPU with
>> 50/50 probability, and after the 3rd, it finally is OK, most of the
>> time. Then, this 30-40-60-120 minutes cycle begins... It happens with
>> this "Bootstrapped 95% ..." message or a bit before that.
>
> I've seen the same and patched like this:
>
> --- a/lib/thread/compat_winthreads.c 2020-01-24 21:59:07
> +++ b/lib/thread/compat_winthreads.c 2020-04-09 08:55:04
> @@ -170,6 +170,8 @@
>do {
> DWORD res;
> res = WaitForSingleObject(cond->event, ms);
> +
> +SleepEx(1, TRUE);
> EnterCriticalSection(>lock);
> if (cond->n_to_wake &&
> cond->generation != generation_at_start) {
>
> -
>
> That always did the trick.
>
> I reported it here:
> https://trac.torproject.org/projects/tor/ticket/33411
>
> --gv
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
