unreplied conntrack sessions
nusenu wrote:
If your hoster suspends your server if you exceed 10k concurrent connections I'm afraid it is probably not suitable for an exit relay
The response from the hoster was:
Your server should not have over 20,000 unreplied connections. This is a sign of abuse.
What about the exit node causes such abormally high conntrack sessions? Q -- 0101100101000001010010000101010101000001010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101
On 31 Jan 2018, at 05:54, Quintin <tor-admin@portaltodark.world> wrote:
nusenu wrote:
If your hoster suspends your server if you exceed 10k concurrent connections I'm afraid it is probably not suitable for an exit relay
The response from the hoster was:
Your server should not have over 20,000 unreplied connections. This is a sign of abuse.
What about the exit node causes such abormally high conntrack sessions?
It is normal for exits to have over 10,000 connections: * 7000 to relays, and * 3000 or more to websites. At the moment, there are extra clients on the network adding some load. For details and mitigations, see: https://lists.torproject.org/pipermail/tor-relays/2018-January/014328.html https://lists.torproject.org/pipermail/tor-relays/2018-January/014100.html T
Does the exits/relays keep the circuit connections open? On Tue, Jan 30, 2018 at 11:45 PM teor <teor2345@gmail.com> wrote:
On 31 Jan 2018, at 05:54, Quintin <tor-admin@portaltodark.world> wrote:
nusenu wrote:
If your hoster suspends your server if you exceed 10k concurrent connections I'm afraid it is probably not suitable for an exit relay
The response from the hoster was:
Your server should not have over 20,000 unreplied connections. This is a sign of abuse.
What about the exit node causes such abormally high conntrack sessions?
It is normal for exits to have over 10,000 connections: * 7000 to relays, and * 3000 or more to websites.
At the moment, there are extra clients on the network adding some load.
For details and mitigations, see: https://lists.torproject.org/pipermail/tor-relays/2018-January/014328.html https://lists.torproject.org/pipermail/tor-relays/2018-January/014100.html
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- 0101100101000001010010000101010101000001010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101
On 31 Jan 2018, at 05:54, Quintin <tor-admin@portaltodark.world> wrote:
nusenu wrote:
If your hoster suspends your server if you exceed 10k concurrent connections I'm afraid it is probably not suitable for an exit relay
The response from the hoster was:
Your server should not have over 20,000 unreplied connections. This is a sign of abuse.
with "unreplied connections" they might actually mean connection _attempts_ and not actual connections (I assume they talk about outbound and not inbound traffic). And they might take it as a sign for "you are probably running a portscanner" (which usually results in lots of connection attempts - TCP SYN packets without replies). It is probably still the best solution to change provider - if you are still considering it.
What about the exit node causes such abormally high conntrack sessions?
It is normal for exits to have over 10,000 connections: * 7000 to relays, and
we are about to fall bellow 6k concurrently running relays https://metrics.torproject.org/networksize.html -- https://mastodon.social/@nusenu twitter: @nusenu_
It is probably still the best solution to change provider - if you are still considering it.
Yep, changing provider is 98% complete. I have a new instance running at online.net since last night: https://atlas.torproject.org/#details/45A9735BE83ECE864B23621B8D266E6A1AEA96... Q -- 0101100101000001010010000101010101000001010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101
Yep, changing provider is 98% complete. I have a new instance running at online.net since last night:
The new instances is running well:
https://atlas.torproject.org/#details/45A9735BE83ECE864B23621B8D266E6A1AEA96... I like being able to enable IPv6 as well. Q -- 0101100101000001010010000101010101000001010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101
participants (3)
-
nusenu -
Quintin -
teor