راه‌اندازی پراکسی Snowflake روی VPS و کمک به کاربران Tor

پراکسی Snowflake چیست و چه کاری نمی‌کند؟

پراکسی Snowflake برنامهٔ کوچکی است که روی VPS شما (سرور مجازی اختصاصی، virtual private server) اجرا می‌شود و به کاربرانی که پشت سانسور هستند کمک می‌کند به شبکهٔ Tor برسند. کاربر داخل ایران در Tor Browser گزینهٔ Snowflake را انتخاب می‌کند. مرورگر او یک اتصال WebRTC (Web Real-Time Communication، همان فناوری تماس تصویری در مرورگر) به پراکسی شما باز می‌کند. پراکسی ترافیک را به بریج Snowflake پروژهٔ Tor می‌رساند و از آنجا ترافیک وارد مدار عادی Tor می‌شود.

پراکسی Snowflake رلهٔ خروجی (exit) نیست. هر بسته‌ای که از آن رد می‌شود به زیرساخت خود پروژهٔ Tor می‌رود، نه به سایتی که کاربر باز کرده. سایت مقصد هرگز IP سرور شما را نمی‌بیند. محتوای ترافیک هم برای شما خوانا نیست، چون داخل WebRTC رمزنگاری شده و داخل آن هم رمزنگاری خود Tor هست. پراکسی فقط بسته‌ها را جابه‌جا می‌کند.

همین تفاوت دلیل این است که Snowflake به‌راحتی روی یک VPS معمولی جا می‌شود، حتی سروری که کار دیگری هم انجام می‌دهد. اگر فرق بریج، رلهٔ میانی و خروجی برایتان روشن نیست، اول راهنمای بریج‌های Tor و pluggable transportها را بخوانید. اگر می‌خواهید ظرفیت بیشتری به خود شبکهٔ Tor بدهید، اجرای رلهٔ guard یا middle روی VPS کار جداگانه‌ای است که کنار Snowflake هم اجرا می‌شود.

چرا این کار را از خارج از ایران انجام می‌دهیم؟

کاربری که به پراکسی شما وصل می‌شود IP سرور را می‌بیند. این بخشی از طراحی WebRTC است: دو طرف باید مستقیم با هم حرف بزنند. هر کسی می‌تواند نقش کاربر را بازی کند، از جمله خود سانسورچی. پس فرض کنید IP پراکسی شما دیر یا زود در فهرست کسانی قرار می‌گیرد که شبکه را کنترل می‌کنند.

برای VPS‌ای که در آلمان یا هلند اجاره کرده‌اید این موضوع مشکلی نیست. شما خارج از حوزهٔ قضایی آن سانسورچی هستید و Tor در این کشورها قانونی و عادی است. برای کسی که داخل ایران زندگی می‌کند وضع فرق دارد. اجرای پراکسی از خانه یا از سروری داخل کشور یعنی آن شخص IP خودش را به‌عنوان کمک‌کنندهٔ Tor اعلام می‌کند. پس صریح می‌گوییم: این راهنما برای کسی است که بیرون از شبکهٔ سانسورشده است و می‌خواهد به آدم‌های داخل کمک کند.

این موضوع یک پیامد عملی هم برای خود شما دارد. اگر روی همان VPS برای خانواده‌تان VPN (شبکهٔ خصوصی مجازی) راه انداخته‌اید، ممکن است مسدودشدن IP پراکسی آن VPN را هم از کار بیندازد، چون هر دو یک IP دارند. اگر این اتفاق افتاد، راهنمای کارهایی که وقتی VPN مسدود شد می‌شود کرد گزینه‌ها را توضیح می‌دهد. اگر VPN خانواده برایتان مهم‌تر است، Snowflake را روی یک VPS جدا اجرا کنید.

پیش از نصب به چه چیزهایی نیاز دارید؟

پروژهٔ Tor در صفحهٔ «standalone Snowflake proxy» تنها شرط لازم را اتصال به اینترنت می‌داند. دو چیز را هم توصیه می‌کند:

• اتصال ۲۴ ساعته. پراکسی‌ای که مدام خاموش و روشن می‌شود اتصال کاربرانش را قطع می‌کند.
• سروری بدون NAT (ترجمهٔ نشانی شبکه، network address translation) یا با NAT بدون محدودیت، که روی آن UDP (user datagram protocol) ورودی در کل محدودهٔ پورت‌های موقت هسته باز باشد.

یک VPS با IP عمومی شرط دوم را خودبه‌خود دارد، به شرطی که فایروال را درست تنظیم کنید. به دامنه و گواهی TLS (transport layer security) نیازی نیست. هیچ پورت TCP ورودی هم لازم نیست. نصب خود Tor هم لازم نیست، چون پراکسی Snowflake برنامه‌ای مستقل است.

کدام پورت‌ها را باید در فایروال باز کنید؟

بیشتر افراد همین بخش را اشتباه می‌کنند. WebRTC برای هر کاربر یک پورت UDP تصادفی انتخاب می‌کند. این پورت از محدودهٔ پورت‌های موقت (ephemeral) هسته برداشته می‌شود. محدودهٔ سرور خودتان را ببینید:

cat /proc/sys/net/ipv4/ip_local_port_range

روی Ubuntu 24.04 خروجی معمولاً دو عدد 32768 و 60999 است. مستندات Tor می‌گوید UDP ورودی باید در کل این محدوده باز باشد، یا در محدوده‌ای که خودتان با پرچم -ephemeral-ports-range تعیین می‌کنید.

چرا این مهم است؟ پراکسی هنگام شروع نوع NAT خودش را می‌سنجد و به broker (سروری که کاربران را به پراکسی‌ها وصل می‌کند) گزارش می‌دهد. اگر پورت‌ها بسته باشند، پراکسی خودش را «restricted» تشخیص می‌دهد. در این حالت broker فقط کاربرانی را به آن می‌فرستد که NAT ساده‌ای دارند. کاربرانی که پشت NATهای سخت‌گیر هستند، که در بسیاری از شبکه‌های موبایل رایج است، دقیقاً همان‌هایی هستند که بیشترین نیاز را به یک پراکسی روی سرور دارند.

دو انتخاب دارید. انتخاب اول: کل محدودهٔ هسته را باز کنید. با UFW (Uncomplicated Firewall) این یک خط است:

sudo ufw allow 32768:60999/udp comment 'snowflake'

انتخاب دوم: یک محدودهٔ کوچک‌تر به پراکسی بدهید و فقط همان را باز کنید. هر اتصال کاربر یک پورت مصرف می‌کند، پس محدودهٔ خیلی کوچک تعداد کاربران هم‌زمان را محدود می‌کند. در این راهنما برای مثال از 30000:40000 استفاده می‌کنیم:

sudo ufw allow 30000:40000/udp comment 'snowflake'
sudo ufw status numbered

در خروجی ufw status باید خطی با 30000:40000/udp و ALLOW IN ببینید. اگر UFW هنوز فعال نیست، پیش از ufw enable حتماً پورت SSH را باز کنید، وگرنه دسترسی خودتان به سرور قطع می‌شود. جزئیات این کار در راهنمای مقدماتی فایروال UFW روی VPS آمده است.

بسیاری از ارائه‌دهندگان VPS یک فایروال شبکهٔ جدا هم در پنل خود دارند. آن فایروال پیش از UFW روی بسته‌ها اثر می‌گذارد. اگر آنجا UDP ورودی بسته باشد، قانون UFW هیچ اثری ندارد.

راه اول: نصب بستهٔ snowflake-proxy با systemd

پروژهٔ Tor در صفحهٔ «Debian» این راه را برای Debian 12 و توزیع‌های مشتق از آن آورده است. در همان صفحه هشدار داده: «Packages might be outdated and so this setup might not work». یعنی بسته‌ها ممکن است قدیمی باشند و این روش کار نکند. پس پیش از نصب ببینید مخزن توزیع شما چه نسخه‌ای دارد:

sudo apt update
apt-cache policy snowflake-proxy

تا مهر ۱۴۰۵ (اکتبر ۲۰۲۶)، مخزن universe در Ubuntu 24.04 و مخزن Debian 12 هر دو نسخهٔ 2.5.1 را دارند. در همین زمان تازه‌ترین نسخه‌ای که پروژهٔ Tor به‌صورت image داکر منتشر کرده v2.14.1 است. یعنی بسته چندین نسخه عقب‌تر است. اگر با این فاصله کنار می‌آیید، دستورهای صفحهٔ Debian پروژهٔ Tor این‌ها هستند:

sudo apt install -y snowflake-proxy
sudo systemctl enable --now snowflake-proxy
sudo systemctl status snowflake-proxy

در خروجی status باید active (running) ببینید. فایل unit این بسته فقط ExecStart=/usr/bin/snowflake-proxy را بدون هیچ پرچمی اجرا می‌کند. برای اینکه پراکسی از محدودهٔ پورتی که باز کرده‌اید استفاده کند، یک فایل override بسازید. خط خالی ExecStart= لازم است، چون مقدار قبلی را پاک می‌کند. بدون آن systemd دو خط ExecStart می‌بیند و سرویس را اجرا نمی‌کند:

sudo mkdir -p /etc/systemd/system/snowflake-proxy.service.d
printf '[Service]\nExecStart=\nExecStart=/usr/bin/snowflake-proxy -ephemeral-ports-range 30000:40000\n' \
  | sudo tee /etc/systemd/system/snowflake-proxy.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart snowflake-proxy
systemctl cat snowflake-proxy

خروجی systemctl cat باید فایل override را زیر فایل اصلی نشان دهد. لاگ را با دستوری که مستندات Tor آورده ببینید:

sudo journalctl -u snowflake-proxy -n 50

اگر کل محدودهٔ هسته را باز کرده‌اید، به override نیازی ندارید.

راه دوم: فایل docker compose پروژهٔ Tor

پروژهٔ Tor در صفحهٔ «Docker» همین روش را توصیه می‌کند. image آن مستقیم از خود پروژه می‌آید، پس از بستهٔ توزیع تازه‌تر است. دستورهای نصب Docker در آن صفحه این‌ها هستند:

sudo apt install -y curl
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

اگر Docker را قبلاً نصب کرده‌اید یا روش دیگری را ترجیح می‌دهید، راهنمای نصب Docker روی VPS را ببینید. سپس فایل compose رسمی را بگیرید. پیش از اجرا آن را بخوانید، چون قرار است روی سروری اجرا شود که شاید سرویس‌های دیگری هم دارد:

mkdir -p ~/snowflake && cd ~/snowflake
curl -fsSL -o docker-compose.yml "https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/raw/main/docker-compose.yml?ref_type=heads"
cat docker-compose.yml

در این فایل دو سرویس هست: snowflake-proxy و watchtower. سرویس پراکسی با network_mode: host اجرا می‌شود. یعنی کانتینر از شبکهٔ خود سرور استفاده می‌کند و سوکت‌های UDP آن همان سوکت‌های سرور هستند. این برای WebRTC لازم است، چون باز کردن هزاران پورت UDP از راه ports: عملی نیست.

نکتهٔ مهم برای کاربران UFW: مشکل معروف دور زدن UFW توسط پورت‌های منتشرشدهٔ Docker فقط برای پورت‌هایی است که با ports: منتشر می‌شوند. در حالت network_mode: host پورتی منتشر نمی‌شود و Docker قانون DNAT (تغییر نشانی مقصد، destination NAT) اضافه نمی‌کند. پس همان قانون UFW بخش قبل روی پراکسی اثر دارد. اگر کسی فایل را به حالت bridge با ports: تغییر دهد، این دیگر صادق نیست.

برای اینکه پراکسی از محدودهٔ 30000:40000 استفاده کند، به سرویس snowflake-proxy یک خط command: اضافه کنید. image پراکسی خود برنامهٔ پراکسی را به‌عنوان entrypoint دارد، پس هر چه در command: بنویسید پرچم آن برنامه می‌شود. بلوک سرویس بعد از ویرایش چیزی شبیه این است. بقیهٔ خط‌های فایل را دست نزنید و تورفتگی را مثل خود فایل نگه دارید:

  snowflake-proxy:
    network_mode: host
    image: thetorproject/snowflake-proxy:v2.14.1
    container_name: snowflake-proxy
    restart: unless-stopped
    command: ["-ephemeral-ports-range", "30000:40000"]

خط image: را در بخش بعد توضیح می‌دهیم. حالا فقط پراکسی را بالا بیاورید و لاگ آن را دنبال کنید. این دو دستور هم از صفحهٔ Docker پروژهٔ Tor هستند:

sudo docker compose up -d snowflake-proxy
sudo docker logs -f snowflake-proxy

با sudo docker ps بررسی کنید که ستون STATUS برای snowflake-proxy مقدار Up دارد. اگر Restarting می‌بینید، پراکسی هنگام شروع خطا می‌دهد، که معمولاً به دلیل پرچمی است که اشتباه تایپ شده. متن خطا در docker logs هست.

نسخهٔ ثابت یا به‌روزرسانی خودکار؟

فایل compose پروژهٔ Tor پراکسی را با برچسب latest و یک سرویس watchtower ارائه می‌دهد. watchtower هر روز بررسی می‌کند که image تازه‌ای منتشر شده یا نه. اگر شده باشد، آن را می‌گیرد و کانتینر را دوباره می‌سازد. مستندات Tor برای فعال کردنش اجرای docker compose up -d بدون نام سرویس را می‌گوید. این با اصل «نسخه را ثابت کن» در تضاد است. هر دو راه منطقی است، ولی باید آگاهانه انتخاب کنید.

نسخهٔ ثابت با روال به‌روزرسانی دستی. در خط image: به جای latest یک برچسب نسخه بگذارید، مثل thetorproject/snowflake-proxy:v2.14.1 که تا مهر ۱۴۰۵ تازه‌ترین نسخهٔ منتشرشده در Docker Hub پروژهٔ Tor است. فقط سرویس snowflake-proxy را اجرا کنید و watchtower را اجرا نکنید. هر ماه یک بار صفحهٔ برچسب‌های image را ببینید. اگر نسخهٔ تازه آمده، برچسب را در فایل عوض کنید و این دستورها را بزنید:

sudo docker compose pull snowflake-proxy
sudo docker compose up -d snowflake-proxy
sudo docker compose images

خروجی docker compose images باید برچسب جدید را نشان دهد. مزیت این راه این است که هیچ چیز بدون اطلاع شما عوض نمی‌شود. هزینه‌اش این است که اگر یادتان برود، پراکسی قدیمی می‌ماند. پروژهٔ Tor گاهی broker را تغییر می‌دهد و پراکسی خیلی قدیمی ممکن است دیگر کاربری نگیرد.

به‌روزرسانی خودکار با watchtower. برچسب latest را نگه دارید و کل فایل را اجرا کنید:

sudo docker compose up -d
sudo docker ps

حالا باید هر دو کانتینر snowflake-proxy و watchtower را با وضعیت Up ببینید. پیش از این کار یک نکته را در فایل بررسی کنید. watchtower به سوکت Docker (/var/run/docker.sock) دسترسی دارد، یعنی می‌تواند هر کانتینری روی سرور را متوقف و جایگزین کند. اگر در command: سرویس watchtower نام هیچ کانتینری نیامده باشد، watchtower همهٔ کانتینرهای سرور را به‌روز می‌کند، از جمله Nextcloud یا پایگاه دادهٔ شما. روی سروری که کار دیگری هم دارد، مطمئن شوید که command: آن فقط snowflake-proxy را نام می‌برد. لاگ خود watchtower را هم گاهی با sudo docker logs watchtower ببینید. اگر watchtower بی‌صدا خطا بدهد، شما فکر می‌کنید به‌روز هستید ولی نیستید.

از کجا بفهمیم پراکسی Snowflake کار می‌کند؟

اولین نشانه این است که سرویس بالا مانده باشد. systemctl is-active snowflake-proxy باید active چاپ کند، یا در docker ps وضعیت Up باشد. نشانهٔ دوم لاگ است. پراکسی هنگام شروع نوع NAT را که اندازه گرفته در لاگ می‌نویسد. با یکی از این دو دستور دنبالش بگردید، اولی برای راه بسته و دومی برای Docker:

sudo journalctl -u snowflake-proxy | grep -i nat
sudo docker logs snowflake-proxy 2>&1 | grep -i nat

روی VPS با پورت‌های باز انتظار دارید نوع NAT «unrestricted» باشد. اگر «restricted» می‌بینید، به احتمال زیاد یکی از دو فایروال، یعنی UFW یا فایروال پنل ارائه‌دهنده، UDP ورودی را می‌بندد.

پراکسی به‌طور پیش‌فرض هر یک ساعت یک خط خلاصه هم می‌نویسد که تعداد اتصال‌ها و حجم ترافیک آن بازه را نشان می‌دهد. این فاصله را پرچم -summary-interval تعیین می‌کند. برای آزمایش اول می‌توانید آن را کوتاه کنید، مثلاً -summary-interval 10m، و بعد به حالت عادی برگردانید. اینکه چند کاربر به شما برسند به broker و به وضعیت سانسور در آن روز بستگی دارد. پس از ساعت اول نتیجه نگیرید. اگر بعد از یک روز کامل هیچ اتصالی ثبت نشده، بخش اشکال‌ها را ببینید.

یک بررسی مستقیم‌تر هم هست. وقتی کاربری وصل است، پراکسی روی یکی از پورت‌های محدوده یک سوکت UDP باز دارد:

sudo ss -uanp | grep proxy

پورت‌هایی که اینجا می‌بینید باید داخل محدوده‌ای باشند که در فایروال باز کرده‌اید. اگر بیرون از آن هستند، پرچم -ephemeral-ports-range به برنامه نرسیده است.

اجرای Snowflake کنار رلهٔ Tor یا سرویس‌های دیگر

پراکسی Snowflake به پورت ثابتی گوش نمی‌دهد. پس با رلهٔ Tor یا وب‌سرور روی همان VPS برخورد پورت ندارد. چیزی که مشترک است پهنای باند و سهمیهٔ ترافیک ماهانهٔ VPS است. ترافیک Snowflake در هر دو جهت از سهمیهٔ شما کم می‌شود. اگر نگران سهمیه هستید، پرچم -capacity تعداد کاربران هم‌زمان را محدود می‌کند. مقدار پیش‌فرض صفر است، یعنی بدون محدودیت. چند روز مصرف را در پنل ارائه‌دهنده دنبال کنید و سپس تصمیم بگیرید.

اگر روی همان سرور رلهٔ guard یا middle دارید، توجه کنید که این رله‌ها در فهرست عمومی رله‌های Tor منتشر می‌شوند. پس IP آن سرور همین حالا هم برای سانسورچی شناخته‌شده است و اضافه کردن Snowflake چیز تازه‌ای دربارهٔ آن فاش نمی‌کند. بریج obfs4 حالت دیگری دارد. ارزش بریج به این است که IP آن کمتر شناخته شده باشد، ولی Snowflake روی همان IP آن را به هر کسی که نقش کاربر را بازی کند نشان می‌دهد. برای همین بهتر است پراکسی Snowflake و بریج obfs4 روی دو IP جدا باشند.

اشکال‌های رایج و علت آن‌ها

سرویس بالاست ولی NAT «restricted» گزارش می‌شود. علت تقریباً همیشه فایروال است. اول sudo ufw status را ببینید و مطمئن شوید محدودهٔ UDP درست است و با پرچم -ephemeral-ports-range یکی است. یک اشتباه رایج این است که محدودهٔ 30000:40000 در UFW باز شده ولی پرچم به پراکسی نرسیده است. در این حالت پراکسی از محدودهٔ هسته (32768 تا 60999) استفاده می‌کند و بیشتر آن بسته است. سپس فایروال پنل ارائه‌دهنده را بررسی کنید.

کانتینر مدام Restarting است. پراکسی هنگام شروع خارج می‌شود و Docker به دلیل restart: unless-stopped دوباره اجرایش می‌کند. خروجی sudo docker logs snowflake-proxy علت را می‌گوید. پرچمی که اشتباه تایپ شده، یا آرایهٔ command: که درست نوشته نشده، شایع‌ترین علت است.

بستهٔ apt نصب شد ولی بعد از یک روز هیچ اتصالی نیست. بستهٔ توزیع چندین نسخه از نسخهٔ پروژهٔ Tor عقب‌تر است و خود پروژه هشدار داده که ممکن است کار نکند. لاگ journalctl را برای خطاهای تکراری اتصال به broker بخوانید. اگر فایروال درست است و مشکل ادامه دارد، بسته را با sudo apt remove snowflake-proxy حذف کنید و راه Docker را بروید.

watchtower کانتینر دیگری را به‌روز کرد. command: سرویس watchtower نام کانتینر را محدود نکرده بود. آن را به snowflake-proxy محدود کنید، یا watchtower را کنار بگذارید و روال دستی بخش نسخهٔ ثابت را دنبال کنید.

VPN شخصی شما روی همان سرور از داخل ایران قطع شد. ممکن است IP سرور به دلیل پراکسی شناسایی و مسدود شده باشد. این را از بیرون نمی‌توان با قطعیت ثابت کرد. ولی اگر هر دو سرویس روی یک IP هستند، این احتمال را در نظر بگیرید و سرویس‌ها را جدا کنید.

همهٔ دستورهای این راهنما را خودتان روی سرور خودتان اجرا می‌کنید. پراکسی را هر لحظه می‌توانید با sudo systemctl disable --now snowflake-proxy یا sudo docker compose down متوقف کنید.

پرسش‌های متداول (FAQ)

آیا پراکسی Snowflake مثل رلهٔ خروجی Tor است؟

خیر. پراکسی Snowflake ترافیک کاربران سانسورشده را فقط به بریج Snowflake پروژهٔ Tor می‌رساند. ترافیک از آنجا وارد مدار Tor می‌شود و از یک رلهٔ خروجی دیگر بیرون می‌رود. سایت‌هایی که کاربر باز می‌کند IP سرور شما را نمی‌بینند و محتوای ترافیک هم برای شما رمزنگاری‌شده است.

چرا پراکسی Snowflake این همه پورت UDP ورودی لازم دارد؟

WebRTC برای هر کاربر یک پورت UDP تصادفی از محدودهٔ پورت‌های موقت هسته انتخاب می‌کند، که روی Ubuntu معمولاً 32768 تا 60999 است. اگر این پورت‌ها بسته باشند، پراکسی خودش را restricted تشخیص می‌دهد و کاربرانی که پشت NAT سخت‌گیر هستند به آن وصل نمی‌شوند. می‌توانید با پرچم -ephemeral-ports-range 30000:40000 محدوده را کوچک کنید و فقط همان را در UFW باز کنید.

آیا اجرای پراکسی Snowflake از داخل ایران کار درستی است؟

این راهنما برای اجرا از خارج نوشته شده است. هر کاربر، از جمله سانسورچی، می‌تواند IP پراکسی را ببیند. برای VPS در خارج این اهمیتی ندارد. ولی برای کسی که داخل ایران است یعنی IP خودش را به‌عنوان کمک‌کنندهٔ Tor اعلام کند. اگر بیرون از ایران هستید، پراکسی را روی سرور خارج اجرا کنید.

برای پراکسی Snowflake بستهٔ apt بهتر است یا Docker؟

تا مهر ۱۴۰۵، Ubuntu 24.04 و Debian 12 نسخهٔ 2.5.1 را دارند و پروژهٔ Tor خودش هشدار داده که بسته‌ها ممکن است قدیمی باشند و کار نکنند. image داکر مستقیم از پروژهٔ Tor می‌آید و تازه‌تر است. اگر Docker روی سرور دارید، راه Docker را بروید و آگاهانه بین برچسب ثابت و watchtower انتخاب کنید.