Call for more Snowflake proxies!
Dear relay operators, The Snowflake network is currently overloaded and we need more Snowflake proxies. If you have spare bandwidth or available servers, please consider running Snowflake proxies. As online censorship continues to increase around the world -- particularly with the recent Internet restrictions in Iran[1] --, we are seeing a significant increase on snowflake usage. We urgently need more Snowflake proxies to help handle this surge and ensure that users can continue to access the open Internet. Please share this call with your friends, communities, hackerspaces and anyone who may be able to help! Gus ### How to help There are multiple ways to run snowflake proxies: - Option 1: Run a browser-based proxy. Click the link below, switch it ON and leave the tab open: https://embed-snowflake.torproject.org/ - Option 2: Install Snowflake browser extension: https://snowflake.torproject.org/#addonBtns - Option 3: Run Snowflake standalone proxy (recommended for relay operators): https://community.torproject.org/relay/setup/snowflake/ - Option 4: Install Orbot (iOS/Android) and enable Kindness mode. https://orbot.app/ ### FAQ for relay operators Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? A: It might not be helpful for censored users as Tor relays are frequently blocked on censored regions. Q: I'm operating a Tor bridge, can I run a Snowflake proxy on the same IP? A: It might expose your bridge IP address and censors might take this opportunity to block your bridge. Q: Can I run Snowflake proxy for a short period? A: Yes. Proxies can run for any amount of time. Even short periods help increase available capacity. Q: Do I need to share my Snowflake proxy manually? A: No. Your proxy is automatically distributed by the Snowflake broker. After setup, no further action is required. Q: Where can I see Snowflake proxy statistics? A: Snowflake proxy statistics are available from Tor Collector. You can download the data here: https://collector.torproject.org/recent/snowflakes/ [1] Censorship analysis in Iran: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issu... -- The Tor Project Community Team Lead
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. It seems like 2.10.1, at least, does not respect -outbound-address and always tries to use the default IP. Unfortunately this means I won't be able to run a Snowflake proxy for now, as the default IP is a Tor exit. If I can't find a simple workaround, I'll see if I can set up a firewall rule to NAT it, or I'll write a simple LD_PRELOAD wrapper. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaYV+HwAKCRAw+TRLM+X4 xt7zAP9YPqyjdZPnUOIZiFQKXgB82xC+MWIoKFSWZigxWePUhQD7B5AvUT/WnAFD cddraywMSKBUzeJSvRrY7q/3gSsbOAc= =EAAX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. This is the workaround I came up with, so I wrote a simple guide. It assumes you are running Debian stable with two IPv4 addresses, one of which has never been used to relay Tor traffic, and are using nftables for your firewall. The iptables version should be just as simple. Add the following postrouting chain to your nftables config, changing the secondary IPv4 and interface name to whatever you have: chain postrouting { type nat hook postrouting priority srcnat; policy accept; skuid snowflake oif eth0 ip saddr 203.0.113.9 snat to 203.0.113.9 } In order to get a not-so-outdated version on Debian stable without using bloated Docker or compiling from source, you can install the package in testing. It doesn't require many dependencies since it's a largely self- contained Go application, so there are no issues with dependency hell. Put the following in /etc/apt/preferences.d/no-default-testing.pref: Package: * Pin: release a=testing Pin-Priority: -1 Then create /etc/apt/sources.list.d/testing.list and put in: deb https://deb.debian.org/debian testing main Now you will have access to the Debian testing repository, but it won't try to update your entire system to testing. Update the apt repositories and install snowflake-proxy from testing. You have to mask the service during installation so that it won't automatically start: adduser --system --group snowflake systemctl mask snowflake-proxy.service apt update apt install snowflake-proxy/testing systemctl unmask snowflake-proxy.service By default, the systemd unit will try to use a dynamic user. You can disable that so that it uses a real user in order for nftables to work. I also add a bit of hardening and block IPv6 so that the proxy doesn't try to use the same IPv6 subnet that you use to relay traffic. Edit the service file with "systemctl edit snowflake-proxy.service" and add: [Service] User=snowflake KeyringMode=private LockPersonality=yes DevicePolicy=closed ProtectSystem=strict ProtectHome=yes ProtectClock=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes RestrictAddressFamilies=AF_INET MemoryDenyWriteExecute=yes SystemCallFilter=@system-service # this can be tighter AppArmorProfile=snowflake_proxy # so can this Now create a trivial AppArmor profile for extra security: #include <tunables/global> profile snowflake_proxy { #include <abstractions/base> #include <abstractions/openssl> #include <abstractions/nameservice> /usr/bin/snowflake-proxy mr, } And finally, apply the changes and start the proxy: systemctl daemon-reload systemctl reload apparmor.service nftables.service systemctl enable --now snowflake-proxy.service If everything went right, you should be running a hardened and fairly up-to-date snowflake proxy on your Debian Tor relay, without using the same IP address that you use to relay Tor traffic. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaYaDUQAKCRAw+TRLM+X4 xl2MAP0d9uVIO/rS2JtZsJE8zWh5HiVGhxuaVqsAXvf8UMBeFwEA4OUunTcQEalc P/XJoa+6YxHuUDVZNHUcDdO2cr0ODgI= =dSMO -----END PGP SIGNATURE-----
participants (2)
-
forest-relay-contact＠cryptolab.net -
gus