Hi,
relayor has been made for relay operators to help
them install and manage tor relays with minimal effort.
https://github.com/nusenu/ansible-relayor
Changes since v18.1.1
------------------------------
- torrc:
enable tor's Sandbox feature by default on Ubuntu (where it was previously disabled as a workaround for #160 )
don't set tor RelayBandwidthBurst if the input field is empty
- increase tor_alpha_version 0.3.4.x -> 0.4.0.x
- increase min ansible version 2.6.2 -> 2.7.8
- add support for OpenBSD 6.4
- add support for FreeBSD 12 (drop 10.x)
- README: mark CentOS/Fedora as currently broken due to upstream package issues #185
- test-kitchen:
add OpenBSD support
add guard-alpha test-suite
kind regards,
nusenu
--
https://twitter.com/nusenu_https://mastodon.social/@nusenu
Hi all,
So I am looking to add some reachable ports to my OBFS4 bridge at
https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032E
CF14E5B9E9A
As this list is public, I guess I should not provide the port numbers that
tor and obfs4 are running on. However, would adding reachable ports like 80,
443, 8080 be doable?
I know that these ports that might not bind very well as lots of other types
of traffic use them, however I saw the ticket at
https://trac.torproject.org/projects/tor/ticket/7875
And this raises a concern about bridges being reachable for users who are
connecting from behind firewalls, etc (hence the reason why they need to use
a bridge), it seems like a good idea to have bridges reachable on ports that
aren't likely to be blocked by network administrators or ISPS.
Let me know what you think.
--Keifer
Dear Tor friends and relay operators,
Tomorrow (23.02.2019) a relay operators meetup will take place at Block cafe,
Berlin.
When: Saturday, February 23rd, 2019
Time: 15:00 / 3:00 PM
Where: Block Cafe, Rua Latino Coelho 63, 1st floor, 1050-133, Lisbon, Portugal
Event link: https://privacylx.org/en/events/tormeetup3/
Hope to see many of you there!
Cheers,
~Vasilis
--
Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162
Hi tor-relays@ mailing list,
I have a Tor relay "NeelTorRelay2":
https://metrics.torproject.org/rs.html#details/D5B8C38539C509380767D4DE20DE…
This relay is hosted on a 300 mbps Verizon FiOS (FTTH/GPON) connection.
My server is a HPE ProLiant MicroServer Gen10 (quad-core AMD X3421
variant) running FreeBSD, and my router is a Linksys WRT1900AC running
OpenWrt.
For some reason, the Advertised Bandwidth is not going above ~19.5
MiB/s.
If my relay is pushing 10MB/s (80mbps) at a given time, the CPU usage is
around 20%, so I don't think its the CPU.
My question is that is this lower Advertised Bandwidth speeds normal for
a relay hosted on a connection behind a consumer level router and it's
NAT table (even despite OpenWrt)? Could it be Verizon's DPI/QoS now that
Net Neutrality is repealed? Would using a non-consumer router (like
Ubiquiti or pfSense) help?
Thank You,
Neel Chauhan
===
https://www.neelc.org/
Neel Chauhan neel at neelc.org at Mon Feb 18 18:05:47 UTC 2019
>
>I feel it's my Linksys WRT1900AC because consumer routers aren't
>designed for the traffic high-bandwidth Tor relays handle, even after
>flashing things like OpenWrt.
The router is probably dropping packets and is
problem. Also consumer grade switches generally
cannot handle FiOS without dropping tons of packets.
A one TCP connection speedtest will not trigger
overload the way a 7000 connection Tor router does.
Dealt with this here by attaching the Linux server
directly to FiOS and having it act as the outside
router. The relay would run much better but I fried
the mainboard with a PCIx NIC overload; swapped in
an incredibly ancient system formerly collecting dust
on a shelf. Too busy/lazy to put up the newer
box waiting to take it's place.
On Mon, 18 Feb 2019 09:06:05 -0500
Neel Chauhan <neel(a)neelc.org> wrote:
> Verizon gives both 300 mbps upload and download speeds. Uploads are more
> heavily oversubscribed on FiOS, primarily because GPON gives 2.5gbps
> downloads and 1.25gbps uploads.
But then again the upload will be barely utilized by typical residential
Internet users.
Still my recommendation is to test your bandwidth in multiple ways first,
be it speedtest.net, or (better yet) https://github.com/sivel/speedtest-cli,
or iperf3 servers, if you can find any near your location.
If tests show that you do get near 300 Mbit both directions, the next step
would be to just set up two instances of Tor, as I suggested before in your
thread[1]. Actually fun to see my prediction from back then coming true
precisely (with regard to getting only 200 Mbit).
[1] https://www.mail-archive.com/tor-relays@lists.torproject.org/msg15819.html
Running two instances is the universal solution which should improve Tor's
bandwidth utilization on almost any connection.
--
With respect,
Roman
Thank you for the answer. I try to get a new IP from the Trabia support.
Olaf
Am 12.02.19 um 21:51 schrieb David Goulet:
> On 12 Feb (21:35:29), Olaf Grimm wrote:
>> inet 178.175.148.15
> Thanks Olaf!
>
> That IP was flagged as rewritting bitcoin addresses on Jan 21st, 2019.
>
> It appears you re-used a malicious IP from I.C.S. Trabia-Network S.R.L.
>
> Do you have an easy way to request a new IP for that Exit node or it is kind
> of a pain?
>
> Un-blacklisting a relay that is still not considered expired from our reject
> rule set can be a laborious process because essentially, we have to make a
> case to the directory authorities and they decide if they remove the rule or
> not based on our arguments ;).
>
> So changing the IP would be definitely the easiest way else we can try to
> convince the dirauth :).
>
> Sorry for the inconvenience!
> David
>
>> Am 12.02.19 um 21:34 schrieb David Goulet:
>>> On 12 Feb (21:30:10), Olaf Grimm wrote:
>>>> Hello !
>>>>
>>>> I provisioning a new exit since two hours. It is a totally new relay in
>>>> a VM. My other relays at the same provider are ok. Why I see "BadExit"
>>>> in Nyx??? Now my first bad experience with my 11 relays...
>>>>
>>>> fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD
>>>> Nickname Hydra10
>>> This relay is not yet on Relay Search:
>>>
>>> http://rougmnvswfsmd4dq.onion/rs.html#search/CCDC4A28392C7448A34E98DF872213…
>>>
>>> I'm guessing it is quite new.
>>>
>>> That fingerprint is *not* set as a BadExit so this means you might have gotten
>>> the IP address of an old BadExit.
>>>
>>> Can you share the address so I can look it up?
>>>
>>> Thanks!
>>> David
>>>
>>>> At all exits I have the same firewall rules and torrc configs:
>>>>
>>>> ufw status
>>>> Status: active
>>>>
>>>> To Action From
>>>> -- ------ ----
>>>> 22/tcp ALLOW Anywhere
>>>> 9001/tcp ALLOW Anywhere
>>>> 9030/tcp ALLOW Anywhere
>>>> 80/tcp ALLOW Anywhere
>>>> 443/tcp ALLOW Anywhere
>>>> 1194/tcp ALLOW Anywhere
>>>> 53/tcp ALLOW Anywhere
>>>> 53/udp ALLOW Anywhere
>>>> 1194/udp ALLOW Anywhere
>>>> 22/tcp (v6) ALLOW Anywhere (v6)
>>>> 9001/tcp (v6) ALLOW Anywhere (v6)
>>>> 9030/tcp (v6) ALLOW Anywhere (v6)
>>>> 80/tcp (v6) ALLOW Anywhere (v6)
>>>> 443/tcp (v6) ALLOW Anywhere (v6)
>>>> 1194/tcp (v6) ALLOW Anywhere (v6)
>>>> 53/tcp (v6) ALLOW Anywhere (v6)
>>>> 53/udp (v6) ALLOW Anywhere (v6)
>>>> 1194/udp (v6) ALLOW Anywhere (v6)
>>>>
>>>> Please take a look what happens.
>>>>
>>>> Olaf
>>>> _______________________________________________
>>>> tor-relays mailing list
>>>> tor-relays(a)lists.torproject.org
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays(a)lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>
Hello !
I provisioning a new exit since two hours. It is a totally new relay in
a VM. My other relays at the same provider are ok. Why I see "BadExit"
in Nyx??? Now my first bad experience with my 11 relays...
fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD
Nickname Hydra10
At all exits I have the same firewall rules and torrc configs:
ufw status
Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
9001/tcp ALLOW Anywhere
9030/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
1194/tcp ALLOW Anywhere
53/tcp ALLOW Anywhere
53/udp ALLOW Anywhere
1194/udp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
9001/tcp (v6) ALLOW Anywhere (v6)
9030/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
1194/tcp (v6) ALLOW Anywhere (v6)
53/tcp (v6) ALLOW Anywhere (v6)
53/udp (v6) ALLOW Anywhere (v6)
1194/udp (v6) ALLOW Anywhere (v6)
Please take a look what happens.
Olaf
Hi,
due to some recent and ongoing events related
to a malicious entity running tor relays
I'll start to pursue an idea that I had
for some time: require non-empty ContactInfo
(non-empty does not mean valid email address)
This is primarily a non-technical policy discussion
which will take place on tor-dev@.
If you want to help right away and currently
don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you
please let me know (off-list is also fine if you prefer).
thanks,
nusenu
--
https://twitter.com/nusenu_https://mastodon.social/@nusenu