پروژه StormDNS 🔐

| نسخه فارسی | English Version |

📢 کانال تلگرام / Telegram Channel: https://t.me/nulllroute1970

پروژه StormDNS یک پروژهٔ علمی-تحقیقاتی برای انتقال داده‌های TCP از طریق درخواست‌ها و پاسخ‌های DNS است. این پروژه در هدف کلی شبیه پروژه‌هایی مانند DNSTT یا SlipStream است، اما از نظر ساختار و روش پیاده‌سازی تفاوت‌های بنیادین دارد و رویکرد متفاوتی را دنبال می‌کند. پیاده‌سازی این سیستم بر پایهٔ سازگاری با انواع شبکه‌ها و رزولورها و نیز توانایی تحمل محدودیت‌های شدید طراحی شده است، تا در بدترین شرایط ممکن بالاترین میزان انتقال داده و بیشترین پایداری را فراهم کند.

📊 مقایسه StormDNS با پروژه‌های مشابه:

ویژگی SlipStream DNSTT StormDNS
نوع پروتکل DNS Tunnel پیشرفته DNS Tunnel کلاسیک DNS Tunnel / VPN پیشرفته
پروتکل انتقال QUIC KCP + Noise پروتکل اختصاصی + ARQ
سربار هدرهای انتقالی 🟠 ~24B 🔴 ~59B 🟢 ~5–7B (≈88% کمتر از DNSTT، ≈71% کمتر از SlipStream)
نوع رمزنگاری TLS 1.3 (در QUIC) Noise (Curve25519) AES / ChaCha20 / XOR (در صورت استفاده از XOR: امنیت نسبی ولی بدون سربار اضافی)
معماری یکپارچه (QUIC همه‌چیز را پوشش می‌دهد) چندلایه (KCP + SMUX + Noise) طراحی اختصاصی سبک، بهینه برای DNS
کارایی (سرعت) 🟡 بالا (تا ~5× سریع‌تر از DNSTT) 🔴 متوسط 🟢 سازگار با شرایط بسیار بد؛ سریعتر از بقیه در شرایط مشابه
پایداری در Packet Loss 🟡 خوب 🟠 متوسط 🟢 بسیار بالا (Multipath + ARQ)
استفاده از چند DNS resolver بله (multipath) بله — پیشرفته (multi-resolver + duplication)
تحمل سانسور شدید خوب متوسط بسیار قوی (هدف اصلی پروژه)
پیچیدگی راه‌اندازی متوسط ساده ساده؛ اما با پیکربندی پیشرفته قابل تنظیم و کمی پیچیده‌تر
پشتیبانی SOCKS5 بله بله بهینه‌شده برای SOCKS5 / SOCKS4
پشتیبانی Shadowsocks غیرمستقیم: در حالت TCP Forwarding از پروتکل‌های TCP پشتیبانی می‌کند
Multipath واقعی بله (QUIC multipath) بله (multi-resolver + duplication)
Adaptive routing محدود پیشرفته (مبتنی بر latency/loss)
هدف طراحی سرعت و کارایی بالا سادگی و پایداری عبور از محدودترین شبکه‌ها — پایداری، سرعت و کارایی
زبان پیاده‌سازی Rust Go Python و Go
بالانسر داخلی 🔴 🟢 (4 نوع بالانسر داخلی)
سیستم Duplication بله — افزایش ترافیک برای تضمین پایداری (قابل تنظیم)
MTU قابل پشتیبانی بهتر از DNSTT - سازگار حتی با MTU کم به دلیل سربار بسیار پایین پروتکل
سیستم Failover
سرعت دانلود 10 مگابایت در حالت لوکال 🟡 0.978 ثانیه 🔴 2.492 ثانیه 🟢 0.270 ثانیه
سرعت آپلود 10 مگابایت در حالت لوکال 🟡 3.249 ثانیه 🔴 16.207 ثانیه 🟢 1.746 ثانیه
قابلیت فشرده سازی 🟢
به سه روش مختلف قابل تنظیم
Off, ZSTD, LZ4, ZLIB
بررسی سلامت رزولورها و غیرفعال‌سازی خودکار
بازفعال‌سازی رزولورها در صورت دسترسی دوباره (پس‌زمینه)
ارائه DNS محلی در کلاینت (جلوگیری از DNS Hijacking) ✅ (با DNS Caching حرفه‌ای برای کاهش درخواست‌ها)
قابلیت DNS resolving از طریق SOCKS5 ✅ (با DNS Caching)
امکان پیکربندی حرفه‌ای و دلخواه 🟠 🟠 🟢 امکان پیکربندی دقیق تمام بخش‌ها
بی‌نیاز از نرم‌افزارهای جانبی 🟢 نیازی به نصب نرم‌افزار جانبی نیست؛ در صورت نیاز می‌توانید از SOCKS یا ابزارهای خارجی مانند Shadowsocks یا OpenVPN استفاده کنید.

❌ رفع مسئولیت (Disclaimer):

پروژه StormDNS صرفاً یک ایدهٔ علمی و آموزشی است و بر همین اساس طراحی و پیاده‌سازی شده است.


کانال اطلاع‌رسانی و پشتیبانی 📢

برای دریافت آخرین اخبار، نسخه‌ها و اطلاعیه‌های پروژه، کانال تلگرام ما را دنبال کنید: Telegram Channel


اگر از پروژه راضی‌اید، با دادن ستاره (⭐) در گیت‌هاب از ما حمایت کنید — این کار به دیده‌شدن پروژه کمک می‌کند.


حمایت مالی (اختیاری) 💸

UQDfjVk2UdpiMg-bsxqoLa0O_icuaF20D-wWJgIJwK1Ha2Ul

TR8ibZGKutPKoDm5nMbHFwGPFBuMKwjG6j

0x8c45d6bae8a5a572b2a776779fe0bcae3d3f9107

از هر نوع حمایت و بازخورد شما سپاسگزاریم — کمک‌ها برای توسعه و بهبود پروژه بسیار ارزشمند است.


ویژگی‌های کلیدی و مزایا ✨

نمای کلی و مختصر از قابلیت‌های اصلی StormDNS:

این فهرست نمای کلی و مختصری از قابلیت‌هاست؛ برای جزئیات بیشتر به بخش‌های مرتبط در همین سند مراجعه کنید.


راه‌اندازی و شروع بکار 🧑‍💻

بخش ۱: 🖥️ راه‌اندازی سرور

بخش ۱.۱: 🌐 راه‌اندازی و آماده‌سازی دامنه (پیش‌نیاز)

برای دریافت مستقیم درخواست‌های DNS روی سرور باید یک زیردامنه را به سرورتان واگذار (delegate) کنید. به‌صورت خلاصه دو رکورد بسازید: یک رکورد A برای آدرس سرور و یک رکورد NS که زیردامنه را به آن A ارجاع دهد.

گام ۱.۱.۱: 🅰️ ساخت رکورد A (آدرس سرور)

مثال: ns.example.com -> 1.2.3.4

در Cloudflare - ⚠️ نکته سریع: اگر دامنه روی Cloudflare است، در صفحه DNS روی آیکون ابر کنار رکورد A کلیک کنید تا خاکستری (DNS only) شود؛ نباید Proxied (نارنجی) باشد.

گام ۱.۱.۲: 🏷️ ساخت رکورد NS (واگذاری زیردامنه)

مثال: v.example.com -> ns.example.com

در Cloudflare - ⚠️ نکته سریع: رکورد NS را اضافه کنید؛ Cloudflare رکورد NS را پروکسی نمی‌کند، فقط مطمئن شوید رکورد ns قبلاً روی DNS only قرار دارد.

بخش ۱.۱.۳: 💡 نکتهٔ کوتاه دربارهٔ MTU

هر چه نام‌های دامنه کوتاه‌تر باشند، فضای بیشتری برای داده در هر DNS request باقی می‌ماند. برای throughput بهتر از نام‌های کوتاه استفاده کنید. اگر از Cloudflare استفاده می‌کنید، باز هم رکوردها را DNS only نگه دارید.


بخش ۱.۲: 🐧 نصب سریع سرور لینوکس

گام ۱.۲.۱: نصب خودکار (اسکریپت)

اگر قصد دارید سرور را روی یک سیستم لینوکسی راه‌اندازی کنید، ساده‌ترین راه استفاده از اسکریپت نصب خودکار است. کافی است دستور زیر را در ترمینال سرور وارد کنید:

bash <(curl -Ls https://raw.githubusercontent.com/nullroute1970/StormDNS/main/server_linux_install.sh)

این اسکریپت مراحل نصب و پیکربندی را خودکار انجام می‌دهد. بعد از پایان نصب، سرور اجرا می‌شود و کلید رمزنگاری در لاگ ترمینال نمایش داده می‌شود و همچنین در فایل encrypt_key.txt کنار فایل اجرایی ذخیره می‌گردد — این کلید را در جای امن نگه دارید.

آرگومان‌های خط فرمان اسکریپت

اسکریپت نصب از آرگومان‌های زیر پشتیبانی می‌کند که می‌توانید آن‌ها را مستقیماً با همان دستور bash <(curl ...) به کار ببرید:

گزینه توضیح
-v <VERSION>, --version <VERSION> نصب نسخهٔ مشخصی از StormDNS با تگ موردنظر (مثلاً v1.2.3) به جای آخرین نسخه.
-u, --uninstall حذف کامل StormDNS: متوقف کردن و پاک کردن سرویس stormdns در systemd، حذف تنظیمات کرنل/محدودیت‌ها و پاک‌سازی فایل اجرایی، server_config.toml و encrypt_key.txt در دایرکتوری جاری.
-h, --help نمایش راهنما و خروج.

مثال‌ها:

# نصب یک نسخه‌ی خاص:
bash <(curl -Ls https://raw.githubusercontent.com/nullroute1970/StormDNS/main/server_linux_install.sh) --version v1.2.3

# حذف StormDNS (دستور را در همان دایرکتوری‌ای اجرا کنید که StormDNS را نصب کرده‌اید):
bash <(curl -Ls https://raw.githubusercontent.com/nullroute1970/StormDNS/main/server_linux_install.sh) --uninstall

توجه: برای حذف، دستور را در همان دایرکتوری اجرای نصب اولیه اجرا کنید تا اسکریپت بتواند فایل اجرایی، فایل پیکربندی و کلید رمزنگاری را پیدا و پاک کند.

گام ۱.۲.۲: نکات مهم پس از نصب

sudo ufw allow 53/udp
sudo ufw reload

برای firewalld:

sudo firewall-cmd --add-port=53/udp --permanent
sudo firewall-cmd --reload

بخش ۲: 🚀 نصب و راه‌اندازی (کلاینت و سرور)

شما می‌توانید این پروژه را به دو روش نصب و اجرا کنید:

  1. استفاده از فایل‌های کامپایل‌شدهٔ آماده (مناسب اکثر کاربران)
  2. اجرای مستقیم از روی سورس با Go (مناسب توسعه دهندگان)

بخش ۲.۱: استفاده از نسخه‌های کامپایل‌شده (✅ روش پیشنهادی)

برای راحتی شما، فایل‌های اجرایی کلاینت و سرور از قبل در releaseها منتشر می‌شوند. کافی است نسخه مناسب سیستم‌عامل خود را دانلود و از حالت فشرده خارج کنید.

💡 نکته: بسته‌های release معمولاً شامل فایل اجرایی و فایل‌های نمونه‌ی کانفیگ هستند.

لینک‌های دانلود کلاینت (Client) 📥

سیستم‌عامل (OS) پردازنده (Architecture) مناسب برای سیستم‌های... لینک دانلود مستقیم
ویندوز (Windows) 🪟 AMD64 (64-bit) ویندوز ۱۰ و ۱۱ دانلود نسخه ویندوز ⬇️
ویندوز (Windows) 🪟 x86 (32-bit) سیستم‌های قدیمی ۳۲ بیتی ویندوز دانلود نسخه ویندوز x86 ⬇️
ویندوز (Windows) 🪟 ARM64 دستگاه‌های ویندوزی مبتنی بر ARM دانلود نسخه ویندوز ARM64 ⬇️
مک‌اواس (macOS) 🍎 ARM64 مک‌های جدید (سری M1 / M2 / M3) دانلود نسخه مک (Apple Silicon) ⬇️
مک‌اواس (macOS) 🍎 AMD64 مک‌های اینتل دانلود نسخه مک اینتل ⬇️
لینوکس (Linux) 🐧 AMD64 (64-bit) توزیع‌های جدید (اوبونتو ۲۲.۰۴+، دبیان ۱۲+) دانلود نسخه لینوکس (جدید) ⬇️
لینوکس (Linux) 🐧 x86 (32-bit) سیستم‌های قدیمی ۳۲ بیتی لینوکس دانلود نسخه لینوکس x86 ⬇️
لینوکس (Legacy) 🐧 AMD64 (64-bit) توزیع‌های قدیمی (اوبونتو ۲۰.۰۴، دبیان ۱۱) دانلود نسخه لینوکس (سازگاری بالا) ⬇️
لینوکس (Legacy) 🐧 ARM64 سیستم‌های ARM64 قدیمی‌تر که سازگاری بیشتری می‌خواهند دانلود نسخه لینوکس Legacy ARM64 ⬇️
لینوکس (ARM) 🐧 ARM64 سرورهای ARM، رزبری‌پای و بردهای مشابه دانلود نسخه لینوکس (ARM) ⬇️
لینوکس (ARM) 🐧 ARMv7 بردهای ARM ۳۲ بیتی و دستگاه‌های قدیمی‌تر دانلود نسخه لینوکس ARMv7 ⬇️
لینوکس (ARM) 🐧 ARMv6 بردهای ARM قدیمی‌تر و سیستم‌های سبک لینوکسی دانلود نسخه لینوکس ARMv6 ⬇️
لینوکس (ARM) 🐧 ARMv5 دستگاه‌های ARM خیلی قدیمی و سیستم‌های embedded دانلود نسخه لینوکس ARMv5 ⬇️
لینوکس (Linux) 🐧 RISCV64 بردها و سرورهای لینوکسی مبتنی بر RISC-V دانلود نسخه لینوکس RISCV64 ⬇️
لینوکس (MIPS) 🐧 MIPS سیستم‌ها و روترهای لینوکسی MIPS با endian بزرگ دانلود نسخه لینوکس MIPS ⬇️
لینوکس (MIPS) 🐧 MIPSLE سیستم‌ها و روترهای لینوکسی MIPS با endian کوچک دانلود نسخه لینوکس MIPSLE ⬇️
لینوکس (MIPS) 🐧 MIPS64 سیستم‌های ۶۴ بیتی MIPS با endian بزرگ دانلود نسخه لینوکس MIPS64 ⬇️
لینوکس (MIPS) 🐧 MIPS64LE سیستم‌های ۶۴ بیتی MIPS با endian کوچک دانلود نسخه لینوکس MIPS64LE ⬇️
ترموکس / اندروید 📱 ARM64 گوشی‌های اندرویدی جدید با Termux دانلود نسخه ترموکس ARM64 ⬇️
ترموکس / اندروید 📱 ARMv7 گوشی‌های قدیمی‌تر با محیط ۳۲ بیتی Termux دانلود نسخه ترموکس ARMv7 ⬇️

لینک‌های دانلود سرور (Server) 📤

(اگر نمی‌خواهید از اسکریپت نصب خودکار لینوکس استفاده کنید.)

سیستم‌عامل (OS) پردازنده (Architecture) مناسب برای سیستم‌های... لینک دانلود مستقیم
ویندوز (Windows) 🪟 AMD64 (64-bit) ویندوز سرور، ویندوز ۱۰ و ۱۱ دانلود سرور ویندوز ⬇️
ویندوز (Windows) 🪟 x86 (32-bit) سیستم‌های قدیمی ۳۲ بیتی ویندوز دانلود سرور ویندوز x86 ⬇️
ویندوز (Windows) 🪟 ARM64 دستگاه‌های ویندوزی مبتنی بر ARM دانلود سرور ویندوز ARM64 ⬇️
لینوکس (Linux) 🐧 AMD64 (64-bit) سرورهای اوبونتو ۲۲.۰۴+، دبیان ۱۲+ دانلود سرور لینوکس (جدید) ⬇️
لینوکس (Linux) 🐧 x86 (32-bit) سیستم‌های قدیمی ۳۲ بیتی لینوکس دانلود سرور لینوکس x86 ⬇️
لینوکس (Legacy) 🐧 AMD64 (64-bit) سرورهای قدیمی (اوبونتو ۲۰.۰۴، دبیان ۱۱) دانلود سرور لینوکس (سازگاری بالا) ⬇️
لینوکس (Legacy) 🐧 ARM64 سیستم‌های ARM64 قدیمی‌تر که سازگاری بیشتری می‌خواهند دانلود سرور لینوکس Legacy ARM64 ⬇️
لینوکس (ARM) 🐧 ARM64 سرورهای ARM دانلود سرور لینوکس (ARM) ⬇️
لینوکس (ARM) 🐧 ARMv7 سرورهای ARM ۳۲ بیتی و دستگاه‌های embedded دانلود سرور لینوکس ARMv7 ⬇️
لینوکس (ARM) 🐧 ARMv6 بردهای ARM قدیمی‌تر و سیستم‌های سبک لینوکسی دانلود سرور لینوکس ARMv6 ⬇️
لینوکس (ARM) 🐧 ARMv5 دستگاه‌های ARM خیلی قدیمی و سیستم‌های embedded دانلود سرور لینوکس ARMv5 ⬇️
لینوکس (Linux) 🐧 RISCV64 بردها و سرورهای لینوکسی مبتنی بر RISC-V دانلود سرور لینوکس RISCV64 ⬇️
لینوکس (MIPS) 🐧 MIPS سیستم‌ها و روترهای لینوکسی MIPS با endian بزرگ دانلود سرور لینوکس MIPS ⬇️
لینوکس (MIPS) 🐧 MIPSLE سیستم‌ها و روترهای لینوکسی MIPS با endian کوچک دانلود سرور لینوکس MIPSLE ⬇️
لینوکس (MIPS) 🐧 MIPS64 سیستم‌های ۶۴ بیتی MIPS با endian بزرگ دانلود سرور لینوکس MIPS64 ⬇️
لینوکس (MIPS) 🐧 MIPS64LE سیستم‌های ۶۴ بیتی MIPS با endian کوچک دانلود سرور لینوکس MIPS64LE ⬇️
مک‌اواس (macOS) 🍎 ARM64 مک‌های جدید (سری M1 / M2 / M3) دانلود سرور مک (Apple Silicon) ⬇️
مک‌اواس (macOS) 🍎 AMD64 مک‌های اینتل دانلود سرور مک اینتل ⬇️
ترموکس / اندروید 📱 ARM64 محیط‌های جدید اندروید / Termux دانلود سرور ترموکس ARM64 ⬇️
ترموکس / اندروید 📱 ARMv7 محیط‌های قدیمی‌تر اندروید / Termux ۳۲ بیتی دانلود سرور ترموکس ARMv7 ⬇️

بخش ۲.۲: 🪟 آماده‌سازی و اجرای کلاینت در ویندوز

⚠️ نکته: شما باید لیست رزولورهایی که قابلیت انتقال اطلاعات به سرور شما را دارند پیدا کنید و در این فایل قرار دهید.

> ⚠️ نکته مهم: روش پیدا کردن لیست Resolver ها در انتهای این مقاله بهش اشاره شده است.

بخش ۲.۳: 🐧 آماده‌سازی و اجرا در لینوکس

sudo apt update
sudo apt install unzip nano screen -y

سپس فایل را استخراج کنید:

unzip StormDNS_Client_Linux_AMD64.zip
ls
chmod +x StormDNS_Client_Linux_AMD64
nano client_config.toml

⚠️ نکته: شما باید لیست ریزالورهایی که قابلیت انتقال اطلاعات به سرور شما را دارند پیدا کنید و در این فایل قرار دهید.

بخش ۲.۳.۱: اجرای کلاینت در پس‌زمینه

بخش ۲.۳.۱.۱: استفاده از screen برای اجرای در پس‌زمینه
screen -S StormDNS
./StormDNS_Client_Linux_AMD64

برای خروج از صفحه screen و برگشت به ترمینال اصلی، کلیدهای Ctrl + A را فشار دهید و سپس D را بزنید. برای بازگشت به صفحه screen و دیدن لاگ‌ها یا متوقف کردن برنامه، دستور زیر را وارد کنید:

screen -r StormDNS
بخش ۲.۳.۱.۲: تبدیل به سرویس systemd

همچنین میتوانید نسخه کلاینت را به سرویس systemd تبدیل کنید تا همیشه در پس‌زمینه اجرا باشد، برای اینکار فایل سرویس زیر را ایجاد کنید:

sudo nano /etc/systemd/system/stormdns-client.service

و محتوای زیر را در آن قرار دهید (مطمئن شوید مسیر فایل اجرایی درست است):

[Unit]
Description=StormDNS Client Service
After=network.target
[Service]
Type=simple
ExecStart=/path/to/StormDNS_Client_Linux_AMD64 -config /path/to/client_config.toml
Restart=on-failure
[Install]
WantedBy=multi-user.target

سپس سرویس را فعال و اجرا کنید:

sudo systemctl daemon-reload
sudo systemctl enable stormdns-client
sudo systemctl start stormdns-client

همچنین برای دیدن لاگ‌ها می‌توانید از دستور زیر استفاده کنید:

sudo journalctl -u stormdns-client -f

بخش ۲.۴: 🍎 آماده‌سازی و اجرا در مک

⚠️ نکته: شما باید لیست ریزالورهایی که قابلیت انتقال اطلاعات به سرور شما را دارند پیدا کنید و در این فایل قرار دهید.


بخش ۲.۵: 🐈‍⬛ پارامترهای خط فرمان (Command-line) برای کلاینت و سرور

هر دو باینری از این پارامترها پشتیبانی می‌کنند:

پارامتر توضیح
-config مسیر فایل تنظیمات
-log مسیر فایل لاگ اختیاری
-version نمایش نسخه و خروج

نمونه:

./stormdns-server -config server_config.toml -log server.log
./stormdns-client -config client_config.toml -log client.log

بخش ۳: 🛠️ ساختار فایل‌های تنظیمات (Config)

بخش ۳.۱: 📂 فایل‌های مهم پروژه

فایل کاربرد
client_config.toml تنظیمات اصلی کلاینت
server_config.toml تنظیمات اصلی سرور
client_resolvers.txt لیست resolverها
encrypt_key.txt کلید مشترک سمت سرور
client_config.toml.simple نمونه کانفیگ کامل کلاینت
server_config.toml.simple نمونه کانفیگ کامل سرور

بخش ۳.۲: 🧾 فایل لیست رزولورها (client_resolvers.txt)

فرمت قابل قبول در client_resolvers.txt:

نمونه:

8.8.8.8
1.1.1.1:53
9.9.9.0/24
208.67.222.0/24:5353

بخش ۳.۴: 📖 پیکربندی کلاینت (client_config.toml)

⚠️ نکته مهم: فایل client_config.toml فقط بخشی از پیکربندی کلاینت است. لیست resolverها داخل فایل جداگانه‌ی client_resolvers.txt خوانده می‌شود و اگر آن فایل وجود نداشته باشد، کلاینت بالا نمی‌آید.

۳.۴.۱) بخش 🔐 هویت تونل، حالت کار و امنیت

پارامتر مقدار نمونه در client_config.toml.simple مقادیر مجاز / رفتار واقعی توضیح کامل
PROTOCOL_TYPE "SOCKS5" فقط "SOCKS5" یا "TCP" تعیین می‌کند کلاینت روی سیستم شما چه نوع سرویس محلی بالا بیاورد.
SOCKS5 یعنی یک پراکسی استاندارد برای مرورگر، تلگرام، برنامه‌ها و ابزارهای عمومی.
TCP یعنی کلاینت فقط یک forwarder ساده‌ی TCP باشد و برای استفاده‌های خاص مناسب‌تر است.
اگر مقدار اشتباه بدهید، برنامه با خطا متوقف می‌شود.
DOMAINS ["v.domain.com"] باید حداقل یک دامنه داشته باشد دامنه یا دامنه‌هایی که کلاینت در queryهای DNS استفاده می‌کند.
این مقدار باید دقیقاً با DOMAIN در سمت سرور یکی باشد.
کد دامنه‌ها را normalize می‌کند: حروف را کوچک می‌کند، فاصله‌ها را حذف می‌کند و . انتهایی را برمی‌دارد.
اگر خالی باشد، کلاینت اصلاً load نمی‌شود.
DATA_ENCRYPTION_METHOD 1 0=None، 1=XOR، 2=ChaCha20، 3=AES-128-GCM، 4=AES-192-GCM، 5=AES-256-GCM روش رمزنگاری payloadهای تونل است.
این مقدار باید با سرور یکسان باشد؛ اگر متفاوت باشد، پکت‌ها decode نمی‌شوند و عملاً ارتباط کار نمی‌کند.
0 فقط برای تست و دیباگ مناسب است.
1 سربار کمی دارد ولی از نظر امنیت ضعیف‌تر است.
مقادیر 2 تا 5 امن‌ترند ولی کمی سربار CPU/packet اضافه می‌کنند.
ENCRYPTION_KEY "" رشته غیرخالی کلید مشترک بین کلاینت و سرور است.
در کلاینت اجباری است و اگر خالی باشد، فایل config معتبر حساب نمی‌شود.
باید محتوای آن دقیقاً با فایل encrypt_key.txt سرور یکسان باشد.

۳.۴.۲) بخش 🧦 پراکسی محلی و دسترسی برنامه‌ها

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
LISTEN_IP "127.0.0.1" IP معتبر آدرس bind سرویس محلی کلاینت است.
اگر روی 127.0.0.1 باشد فقط خود همان سیستم می‌تواند از پراکسی استفاده کند.
اگر روی بعضی سیستم‌ها یا برنامه‌ها اتصال‌ها بیشتر با localhost یا IPv6 loopback انجام می‌شود، گذاشتن localhost می‌تواند انتخاب بهتری برای استفاده‌ی فقط محلی باشد.
اگر روی 0.0.0.0 بگذارید، دستگاه‌های دیگر داخل شبکه هم می‌توانند به آن وصل شوند؛ این حالت بدون احراز هویت توصیه نمی‌شود.
LISTEN_PORT 18000 0..65535 پورتی که پراکسی یا forwarder محلی روی آن گوش می‌دهد.
اگر این پورت قبلاً توسط برنامه دیگری اشغال شده باشد، کلاینت موقع startup خطا می‌دهد.
SOCKS5_AUTH false true/false فقط مربوط به پراکسی محلی خود کلاینت است، نه سرور.
اگر true باشد، هر برنامه‌ای که بخواهد از SOCKS5 کلاینت استفاده کند باید username/password بدهد.
اگر false باشد، هرکسی که به LISTEN_IP:LISTEN_PORT دسترسی داشته باشد می‌تواند از پراکسی استفاده کند.
SOCKS5_USER "master_dns_vpn" حداکثر 255 بایت نام کاربری پراکسی محلی است.
فقط وقتی مهم است که SOCKS5_AUTH = true باشد.
اگر auth روشن باشد و این فیلد خالی باشد، config نامعتبر می‌شود.
SOCKS5_PASS "master_dns_vpn" حداکثر 255 بایت رمز عبور پراکسی محلی است.
مثل نام کاربری، فقط در حالت auth معنی دارد.
برای امنیت واقعی، اگر پراکسی را روی 0.0.0.0 می‌گذارید حتماً مقدار قوی بگذارید.

۳.۴.۳) بخش 📛 DNS محلی و کش DNS

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
LOCAL_DNS_ENABLED false true/false اگر true باشد، کلاینت یک DNS محلی هم بالا می‌آورد تا درخواست‌های DNS برنامه‌های شما را از داخل تونل مدیریت کند.
این قابلیت برای جلوگیری از DNS leak و DNS hijack مفید است.
اگر false باشد، فقط پراکسی/SOCKS فعال است و DNS محلی بالا نمی‌آید.
LOCAL_DNS_IP "127.0.0.1" IP معتبر آدرسی که DNS محلی روی آن bind می‌شود.
معمولاً همان 127.0.0.1 مناسب است، مگر اینکه بخواهید دستگاه‌های دیگر هم از DNS شما استفاده کنند.
LOCAL_DNS_PORT 53 0..65535 پورت DNS محلی است.
اگر روی سیستم شما پورت 53 قبلاً اشغال باشد، باید پورت دیگری انتخاب کنید و همان را در سیستم/برنامه‌ها تنظیم کنید.
LOCAL_DNS_CACHE_MAX_RECORDS 10000 اگر کمتر از 1 باشد، کد از fallback استفاده می‌کند سقف تعداد رکوردهایی است که DNS محلی در حافظه نگه می‌دارد.
عدد بزرگ‌تر یعنی cache بیشتر و درخواست کمتر به تونل، ولی RAM بیشتری مصرف می‌شود.
در کد اگر مقدار نامعتبر باشد fallback واقعی 2000 است.
LOCAL_DNS_CACHE_TTL_SECONDS 14400.0 اگر <=0 باشد، fallback اعمال می‌شود مدت‌زمانی که DNS محلی پاسخ‌ها را در cache نگه می‌دارد.
TTL بالاتر باعث کاهش queryهای تکراری می‌شود، ولی اگر مقصدها زیاد عوض شوند ممکن است اطلاعات قدیمی دیرتر refresh شوند.
fallback واقعی در کد 3600 ثانیه است.
LOCAL_DNS_PENDING_TIMEOUT_SECONDS 300.0 اگر <=0 باشد، fallback اعمال می‌شود اگر یک درخواست DNS محلی زیاد طول بکشد و جوابش برنگردد، بعد از این زمان از pending table پاک می‌شود تا حافظه و state بی‌جهت نگه داشته نشود.
fallback واقعی در کد 600 ثانیه است.
DNS_RESPONSE_FRAGMENT_TIMEOUT_SECONDS 60.0 clamp می‌شود به 1..600 ثانیه بعضی پاسخ‌های DNS تونل‌شده در چند fragment می‌رسند.
این مقدار تعیین می‌کند کلاینت تا چه مدت برای کامل شدن همه fragmentها صبر کند.
اگر خیلی کم باشد، پاسخ‌های تکه‌تکه زود drop می‌شوند؛ اگر خیلی زیاد باشد، stateهای ناقص طولانی‌تر در حافظه می‌مانند.
LOCAL_DNS_CACHE_PERSIST_TO_FILE true true/false اگر true باشد، cache DNS محلی روی فایل هم ذخیره می‌شود و بعد از restart دوباره قابل استفاده است.
این کار startup را برای domainهای تکراری سریع‌تر می‌کند.
LOCAL_DNS_CACHE_FLUSH_INTERVAL_SECONDS 60.0 اگر <=0 باشد، fallback اعمال می‌شود هر چند وقت یک‌بار cache در فایل نوشته شود.
عدد کم‌تر یعنی ریسک از دست رفتن cache کمتر است، ولی نوشتن روی دیسک بیشتر می‌شود.
fallback واقعی در کد 60 ثانیه است.

۳.۴.۴) بخش 📡 انتخاب Resolver، Duplication و سلامت مسیر

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
RESOLVER_BALANCING_STRATEGY 0 فقط 0..4 تعیین می‌کند کلاینت پکت‌هایش را روی resolverها چطور پخش کند.
0 و 2 هر دو round-robin هستند.
1 انتخاب تصادفی است.
3 سعی می‌کند روی resolverهایی برود که loss کمتری داشته‌اند.
4 بیشتر به resolverهای سریع‌تر گرایش دارد.
برای شرایط خیلی ناپایدار، معمولاً 3 یا 4 بهتر از 0 هستند.
UPLOAD_PACKET_DUPLICATION_COUNT 2 clamp به 1..8 فقط برای پکت‌های upload data (STREAM_DATA، STREAM_RESEND).
چون حجم دیتای کاربر داخل اینهاست، هر duplication به‌طور مستقیم مصرف upload را چند برابر می‌کند.
روی لینک‌هایی با آپلود محدود (مثل شرایط معمول ایران) این مقدار را کم نگه دارید (12).
DOWNLOAD_PACKET_DUPLICATION_COUNT 7 clamp به 1..8 فقط برای پکت‌های download-support (STREAM_DATA_ACK، STREAM_DATA_NACK).
اینها ACKهای کوچک ترافیک دانلود شما هستند.
duplicate کردنشان تقریباً هزینه‌ای روی آپلود ندارد ولی قابلیت اطمینان دانلود را زیاد می‌کند؛ روی شبکه‌های بد مقادیر 47 منطقی است.
UPLOAD_SETUP_PACKET_DUPLICATION_COUNT 3 clamp به [UPLOAD_PACKET_DUPLICATION_COUNT, 8] برای پکت‌های upload setup (STREAM_SYN، SOCKS5_SYN).
حجمشان کم است ولی برای زمان ایجاد اتصال جدید حیاتی هستند.
DOWNLOAD_SETUP_PACKET_DUPLICATION_COUNT 8 clamp به [DOWNLOAD_PACKET_DUPLICATION_COUNT, 8] برای پکت‌های download setup / control (PACKED_CONTROL_BLOCKS، STREAM_CLOSE_READ، STREAM_CLOSE_WRITE).
حجم کم ولی از دست رفتنشان teardown/control را مختل می‌کند؛ بالا نگه‌داشتن (48) معمولاً امن است.
STREAM_RESOLVER_FAILOVER_RESEND_THRESHOLD 2 clamp به 1..128 اگر یک stream روی resolver ترجیحی خودش پشت سر هم resend بخورد، بعد از این آستانه کلاینت resolver ترجیحی آن stream را عوض می‌کند.
این مکانیزم باعث می‌شود یک stream روی resolver بد گیر نکند.
STREAM_RESOLVER_FAILOVER_COOLDOWN 1.0 clamp به 0.1..120 ثانیه حداقل فاصله بین دو بار failover برای یک stream است.
اگر خیلی کم باشد stream مدام resolver عوض می‌کند و سیستم ناپایدار می‌شود.
اگر خیلی زیاد باشد stream دیرتر از resolver بد جدا می‌شود.
RECHECK_INACTIVE_SERVERS_ENABLED true true/false resolverهایی که در تست MTU اولیه یا در runtime غیرفعال شده‌اند، در پس‌زمینه دوباره امتحان شوند یا نه.
اگر خاموش باشد، resolverهای بد تا restart بعدی کمتر شانس بازگشت دارند.
RECHECK_INACTIVE_INTERVAL_SECONDS 60.0 clamp به 60..86400 ثانیه فاصله کلی دورهای recheck است.
یعنی health loop هر چند وقت یک‌بار به سراغ resolverهای غیرفعال برود.
RECHECK_SERVER_INTERVAL_SECONDS 2.0 clamp به 1..600 ثانیه مبنای فاصله retry برای هر resolver غیرفعال است.
وقتی recheck fail می‌شود، کد با backoff و jitter از این مقدار استفاده می‌کند.
RECHECK_BATCH_SIZE 30 clamp به 1..1024 در هر دور، چند resolver غیرفعال هم‌زمان/در یک batch بررسی شوند.
عدد خیلی بالا startup یا health loop را تهاجمی‌تر می‌کند.
AUTO_DISABLE_TIMEOUT_SERVERS true true/false اگر یک resolver در runtime فقط timeout تولید کند و هیچ success نداشته باشد، کلاینت می‌تواند موقتاً آن را از لیست فعال خارج کند.
این قابلیت برای جلوگیری از هدر رفتن packet روی resolver مرده است.
AUTO_DISABLE_TIMEOUT_WINDOW_SECONDS 90.0 clamp به 1..86400 ثانیه پنجره‌ای که در آن history timeout-only بررسی می‌شود.
اگر در این بازه فقط timeout ببینیم و شرط observation هم برقرار باشد، resolver غیرفعال می‌شود.
AUTO_DISABLE_MIN_OBSERVATIONS 3 clamp به 1..10000 حداقل چند نمونه timeout لازم است تا auto-disable تصمیم بگیرد.
برای جلوگیری از false positive، این عدد نباید خیلی کم باشد.
AUTO_DISABLE_CHECK_INTERVAL_SECONDS 4.0 clamp به 0.25..600 ثانیه هر چند وقت یک‌بار health loop وضعیت timeout-only resolverها را بررسی کند.
BASE_ENCODE_DATA false true/false اگر true باشد، payload قبل از قرار گرفتن داخل labelهای DNS به شکل base-safe encode می‌شود.
معمولاً لازم نیست، ولی بعضی resolverها با این حالت سازگارترند.
عوض کردن این گزینه روی اندازه payload اثر می‌گذارد و می‌تواند throughput را تغییر دهد.

نکته — لینک‌های با آپلود محدود (مثل ایران): چون مصرف آپلود متناسب با UPLOAD_PACKET_DUPLICATION_COUNT زیاد می‌شود ولی duplication پکت‌های ACK عملاً رایگان است، یک پروفایل خوب این است: toml UPLOAD_PACKET_DUPLICATION_COUNT = 1 # یا 2 DOWNLOAD_PACKET_DUPLICATION_COUNT = 5 # 4..7 UPLOAD_SETUP_PACKET_DUPLICATION_COUNT = 3 # 2..4 DOWNLOAD_SETUP_PACKET_DUPLICATION_COUNT = 6 # 4..8 این تنظیمات مصرف آپلود را پایین نگه می‌دارد و در عین حال پایداری دانلود و ایجاد اتصال را به‌طور پررنگ محافظت می‌کند.

۳.۴.۵) بخش 🗜️ فشرده‌سازی

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
UPLOAD_COMPRESSION_TYPE 0 0=OFF، 1=ZSTD، 2=LZ4، 3=ZLIB فشرده‌سازی داده‌هایی که از کلاینت به سرور می‌روند.
اگر داده‌ها خیلی کوچک یا خیلی تصادفی باشند، compression کمکی نمی‌کند و فقط CPU مصرف می‌شود.
برای payloadهای بزرگ‌تر یا تکراری می‌تواند مفید باشد.
DOWNLOAD_COMPRESSION_TYPE 0 0=OFF، 1=ZSTD، 2=LZ4، 3=ZLIB همان مفهوم برای جهت دانلود از سرور به کلاینت.
باید نوعی انتخاب شود که هم سمت سرور پشتیبانی کند و هم از نظر CPU برای شما مناسب باشد.
COMPRESSION_MIN_SIZE 120 اگر کمتر از 1 باشد، fallback اعمال می‌شود اگر payload از این مقدار کوچک‌تر باشد، اصلاً compression امتحان نمی‌شود.
این پارامتر برای جلوگیری از فشرده‌سازی بی‌فایده‌ی packetهای کوچک است.

۳.۴.۶) بخش 📏 MTU، تست اولیه و خروجی نتایج

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
MIN_UPLOAD_MTU 40 نباید منفی باشد حداقل MTU قابل قبول برای مسیر upload است.
اگر resolver فقط MTU کمتر از این را جواب بدهد، برای upload کنار گذاشته می‌شود.
عدد پایین‌تر پایداری را بیشتر می‌کند ولی سرعت را کم می‌کند.
MIN_DOWNLOAD_MTU 100 نباید منفی باشد همان مفهوم برای download.
اگر مقدار خیلی بالا باشد، resolverهای بیشتری از همان اول حذف می‌شوند.
MAX_UPLOAD_MTU 150 نباید از MIN_UPLOAD_MTU کوچک‌تر باشد سقف جست‌وجوی MTU برای upload در تست اولیه.
بازه‌ی خیلی بزرگ startup را طولانی‌تر می‌کند.
MAX_DOWNLOAD_MTU 500 نباید از MIN_DOWNLOAD_MTU کوچک‌تر باشد سقف جست‌وجوی MTU برای download.
اگر می‌دانید شبکه شما محدود است، کوچک‌تر کردن این مقدار startup را سریع‌تر می‌کند.
MTU_TEST_RETRIES_RESOLVERS 3 اگر کمتر از 1 باشد، fallback اعمال می‌شود تعداد retry هر probe MTU وقتی STARTUP_MODE = "resolvers" (اسکن کامل از روی client_resolvers.txt).
روی resolverهای پر loss عدد بالاتر می‌تواند مفید باشد، ولی startup را کندتر می‌کند.
MTU_TEST_TIMEOUT_RESOLVERS 2.0 اگر <=0 باشد، fallback اعمال می‌شود timeout هر probe در تست MTU وقتی STARTUP_MODE = "resolvers".
اگر شبکه شما دیرپاسخ است، این مقدار خیلی کم باعث حذف resolverهای سالم می‌شود.
MTU_TEST_PARALLELISM_RESOLVERS 100 اگر کمتر از 1 باشد، fallback اعمال می‌شود تعداد تست‌های هم‌زمان MTU وقتی STARTUP_MODE = "resolvers".
عدد بالا startup را سریع‌تر می‌کند ولی CPU و ترافیک بیشتری می‌سازد.
MTU_TEST_RETRIES_LOGS 5 اگر کمتر از 1 باشد، fallback اعمال می‌شود تعداد retry هر probe MTU وقتی STARTUP_MODE = "logs" (راه‌اندازی سریع از روی resolverهای کش‌شده در logها).
MTU_TEST_TIMEOUT_LOGS 2.0 اگر <=0 باشد، fallback اعمال می‌شود timeout هر probe در تست MTU وقتی STARTUP_MODE = "logs".
MTU_TEST_PARALLELISM_LOGS 32 اگر کمتر از 1 باشد، fallback اعمال می‌شود تعداد تست‌های هم‌زمان MTU وقتی STARTUP_MODE = "logs".

۳.۴.۷) بخش ⚙️ Workerها، queueها و زمان‌بندی runtime

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
RX_TX_WORKERS 2 clamp به 1..64 تعداد workerهای مشترک runtime برای هر دو مسیر خواندن پاسخ‌های DNS و نوشتن queryهای خروجی.
این مقدار به صورت یکسان برای RX و TX استفاده می‌شود تا تنظیمات ساده‌تر بماند.
TUNNEL_PROCESS_WORKERS 2 clamp به 1..64 تعداد workerهایی که packetهای دریافتی را decode و process می‌کنند.
اگر resolverهای زیادی دارید، این بخش روی CPU اثر زیادی دارد.
TUNNEL_PACKET_TIMEOUT_SECONDS 10.0 clamp به 0.5..120 ثانیه timeout کلی یک packet در runtime async کلاینت است.
اگر packet تا این مدت outcome نگیرد، runtime آن را timeout حساب می‌کند.
DISPATCHER_IDLE_POLL_INTERVAL_SECONDS 0.020 clamp به 0.001..1.0 ثانیه وقتی dispatcher کار خاصی ندارد، هر چند وقت یک‌بار دوباره queueها را چک کند.
عدد کوچک‌تر latency را کم می‌کند ولی CPU idle را بالا می‌برد.
TX_CHANNEL_SIZE 2048 clamp به 64..65536 ظرفیت channel ارسال packetها در runtime async.
اگر خیلی کوچک باشد زیر load سریع‌تر block می‌شود؛ اگر خیلی بزرگ باشد RAM بیشتری مصرف می‌کند.
RX_CHANNEL_SIZE 2048 clamp به 64..65536 همان مفهوم برای مسیر دریافت.
RESOLVER_UDP_CONNECTION_POOL_SIZE 128 clamp به 1..1024 برای هر resolver چند UDP connection قابل reuse نگه داشته شود.
عدد بزرگ‌تر هزینه ساخت connection را کم می‌کند ولی منابع بیشتری می‌گیرد.
STREAM_QUEUE_INITIAL_CAPACITY 256 clamp به 8..65536 ظرفیت اولیه queue هر stream برای packetهای منتظر ارسال/مدیریت است.
برای streamهای زیاد، عدد مناسب باعث realloc کمتر می‌شود.
ORPHAN_QUEUE_INITIAL_CAPACITY 64 clamp به 4..4096 ظرفیت اولیه queue packetهای orphan است؛ یعنی packetهایی که فعلاً هنوز stream مقصدشان attach نشده یا باید موقتاً جدا نگه داشته شوند.
DNS_RESPONSE_FRAGMENT_STORE_CAPACITY 512 clamp به 16..16384 ظرفیت نگهداری fragmentهای پاسخ DNS پیش از مونتاژ کامل.
SOCKS_UDP_ASSOCIATE_READ_TIMEOUT_SECONDS 30.0 clamp به 1..3600 ثانیه timeout خواندن برای UDP ASSOCIATE در حالت SOCKS است.
اگر طولانی‌تر باشد sessionهای بی‌استفاده دیرتر جمع می‌شوند.
CLIENT_TERMINAL_STREAM_RETENTION_SECONDS 45.0 clamp به 1..3600 ثانیه streamهایی که به حالت terminal رسیده‌اند، چه مدت در memory نگه داشته شوند تا ACKهای دیررس/closeهای عقب‌افتاده هنوز درست هندل شوند.
CLIENT_CANCELLED_SETUP_RETENTION_SECONDS 120.0 clamp به 1..3600 ثانیه اگر setup یک stream لغو شود، state آن تا چه مدت نگه داشته شود تا duplicate/late packetها دوباره آن را زنده نکنند.
SESSION_INIT_RETRY_BASE_SECONDS 1.0 clamp به 0.1..60 ثانیه پایه‌ی delay برای retryهای session init/reset.
SESSION_INIT_RETRY_STEP_SECONDS 1.0 clamp به 0..60 ثانیه گام افزایش delay retry در پروفایل session init.
SESSION_INIT_RETRY_LINEAR_AFTER 5 clamp به 0..1000 از چندمین تلاش به بعد الگوی retry از حالت قبلی وارد backoff خطی شود.
SESSION_INIT_RETRY_MAX_SECONDS 60.0 clamp به [SESSION_INIT_RETRY_BASE_SECONDS, 3600] سقف delay بین retryهای session init.
SESSION_INIT_BUSY_RETRY_INTERVAL_SECONDS 60.0 clamp به 1..3600 ثانیه اگر سرور پاسخ SESSION_BUSY بدهد، کلاینت قبل از تلاش مجدد این‌قدر صبر می‌کند.

۳.۴.۸) بخش 🫀 Ping / Keepalive

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
PING_AGGRESSIVE_INTERVAL_SECONDS 0.200 clamp به 0.05..30 ثانیه فاصله ping در حالتی که ارتباط تازه داغ است و می‌خواهیم RTT و liveness را با حساسیت بالا نگه داریم.
PING_LAZY_INTERVAL_SECONDS 0.750 clamp به [PING_AGGRESSIVE_INTERVAL_SECONDS, 60] وقتی ارتباط کمی آرام‌تر شد، به این فاصله می‌رسد.
PING_COOLDOWN_INTERVAL_SECONDS 2.0 clamp به [PING_LAZY_INTERVAL_SECONDS, 300] فاصله ping در فاز cooldown.
PING_COLD_INTERVAL_SECONDS 15.0 clamp به [PING_COOLDOWN_INTERVAL_SECONDS, 3600] وقتی session کاملاً idle شده، pingها با این فاصله فرستاده می‌شوند تا بار بی‌خودی کم شود.
PING_WARM_THRESHOLD_SECONDS 5.0 clamp به 0.1..600 ثانیه آستانه‌ای که runtime براساس آن تصمیم می‌گیرد هنوز warm هستیم یا نه.
PING_COOL_THRESHOLD_SECONDS 15.0 clamp به [PING_WARM_THRESHOLD_SECONDS, 1800] مرز ورود به فاز cool.
PING_COLD_THRESHOLD_SECONDS 30.0 clamp به [PING_COOL_THRESHOLD_SECONDS, 3600] مرز ورود به فاز cold و ping بسیار کم‌فاصله.
PING_WATCHDOG_TIMEOUT_SECONDS 300.0 clamp به 10..3600 ثانیه، 0 غیرفعال می‌کند اگر کلاینت traffic غیر-ping ارسال کرده باشد ولی در این مدت هیچ پاسخی از سرور دریافت نشود، session به‌اجبار ریست می‌شود. تایمر این watchdog تنها پس از اینکه همه resolverها اسکن شدند و session کاملاً عملیاتی شد شروع به کار می‌کند. این حالت zombie tunnel را که در آن همه resolverها بسته‌ها را بی‌صدا دور می‌اندازند و هیچ پیام ریست سمت سرور نمی‌رسد، بازیابی می‌کند.

۳.۴.۹) بخش 🔄 ARQ، NACK و packing

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
MAX_PACKETS_PER_BATCH 5 clamp به 1..64 حداکثر تعداد control blockهایی که کلاینت در یک batch کنار هم می‌گذارد.
برای کاهش سربار ACK و control مفید است.
ARQ_WINDOW_SIZE 600 clamp به 1..16384 اندازه پنجره ARQ است.
پنجره بزرگ‌تر throughput را بهتر می‌کند، ولی state و memory بیشتری مصرف می‌کند.
ARQ_INITIAL_RTO_SECONDS 1 clamp به 0.05..60 ثانیه RTO اولیه برای packetهای data.
اگر خیلی کم باشد resendهای بی‌مورد زیاد می‌شود.
ARQ_MAX_RTO_SECONDS 5.0 clamp به [ARQ_INITIAL_RTO_SECONDS, 120] سقف RTO برای data.
ARQ_CONTROL_INITIAL_RTO_SECONDS 0.5 clamp به 0.05..60 ثانیه RTO اولیه برای packetهای control مثل close/ack/setup.
ARQ_CONTROL_MAX_RTO_SECONDS 3.0 clamp به [ARQ_CONTROL_INITIAL_RTO_SECONDS, 120] سقف RTO control.
ARQ_MAX_CONTROL_RETRIES 300 clamp به 5..5000 چند بار packetهای control اجازه retry داشته باشند.
ARQ_INACTIVITY_TIMEOUT_SECONDS 1800.0 clamp به 30..86400 ثانیه اگر stream/ARQ مدت زیادی idle باشد، inactivity timeout از این استفاده می‌کند.
ARQ_DATA_PACKET_TTL_SECONDS 2400.0 clamp به 30..86400 ثانیه اگر یک packet data خیلی طولانی در مسیر بماند و به نتیجه نرسد، بعد از این TTL دیگر ارزش retry ندارد.
ARQ_CONTROL_PACKET_TTL_SECONDS 1200.0 clamp به 30..86400 ثانیه همان مفهوم برای packetهای control.
ARQ_MAX_DATA_RETRIES 1200 clamp به 60..100000 سقف retry packetهای data.
ARQ_DATA_NACK_MAX_GAP 64 clamp به 0..32 در کد فعلی تعیین می‌کند اگر جلوتر از rcvNxt packet رسید، تا چه فاصله‌ای gap را با NACK اعلام کنیم.
0 یعنی NACK data عملاً خاموش است.
نکته مهم: sample مقدار 64 دارد، ولی کد فعلی آن را حداکثر تا 32 clamp می‌کند.
ARQ_DATA_NACK_INITIAL_DELAY_SECONDS 0.4 clamp به 0..30 ثانیه تأخیر اولیه قبل از ارسال NACK برای پکت‌های داده گم‌شده. سرعت درخواست ارسال مجدد را کنترل می‌کند.
ARQ_DATA_NACK_REPEAT_SECONDS 0.5 clamp به 0.1..30 ثانیه برای یک sequence گمشده، NACK تکراری با چه فاصله‌ای دوباره ارسال شود.
ARQ_TERMINAL_DRAIN_TIMEOUT_SECONDS 120.0 clamp به 10..3600 ثانیه وقتی stream وارد حالت terminal شد، چقدر صبر کنیم تا bufferهای باقیمانده drain شوند.
ARQ_TERMINAL_ACK_WAIT_TIMEOUT_SECONDS 90.0 clamp به 5..3600 ثانیه بعد از closeهای terminal، چقدر برای ACK نهایی صبر کنیم.

۳.۴.۱۰) بخش 🪵 لاگ

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
LOG_LEVEL "INFO" معمولاً DEBUG, INFO, WARN, ERROR سطح لاگ کلاینت است.
DEBUG برای عیب‌یابی دقیق خوب است ولی حجم لاگ را زیاد می‌کند.
برای استفاده روزمره معمولاً INFO یا WARN مناسب‌تر است.

بخش ۳.۵: 📖 پیکربندی سرور (server_config.toml)

ℹ️ نکته: در فایل نمونه‌ی سرور یک کلید به نام CONFIG_VERSION دیده می‌شود، اما کد فعلی Go آن را در ServerConfig نمی‌خواند. به همین دلیل در جدول زیر نیاورده شده است و روی رفتار واقعی سرور اثر ندارد.

۳.۵.۱) بخش 🌐 سیاست تونل و پذیرش پروتکل

پارامتر مقدار نمونه در server_config.toml.simple مقادیر مجاز / رفتار واقعی توضیح کامل
DOMAIN ["v.domain.com"] لیست رشته دامنه یا دامنه‌هایی که این سرور آن‌ها را متعلق به تونل خودش می‌داند.
باید با DOMAINS کلاینت هماهنگ باشد، وگرنه queryها روی این سرور به‌عنوان tunnel packet درست تشخیص داده نمی‌شوند.
PROTOCOL_TYPE "SOCKS5" فقط "SOCKS5" یا "TCP" تعیین می‌کند سرور از چه نوع setup برای streamهای جدید پشتیبانی کند.
در حالت SOCKS5 سرور انتظار PACKET_SOCKS5_SYN دارد و مقصد را از payload کلاینت می‌گیرد.
در حالت TCP setup از نوع PACKET_STREAM_SYN است و سرور به FORWARD_IP:FORWARD_PORT وصل می‌شود.
MIN_VPN_LABEL_LENGTH در sample نیامده اگر <=0 باشد fallback به 3 حداقل طول label داده در تونل است.
برای جلوگیری از اشتباه گرفتن queryهای غیر تونلی با queryهای پروژه استفاده می‌شود.
اگر در README یا config سرور شما این پارامتر نیست، الان خوب است اضافه‌اش کنید چون کد از آن پشتیبانی می‌کند.
SUPPORTED_UPLOAD_COMPRESSION_TYPES [0, 1, 2, 3] فقط نوع‌های معتبر compression فهرست compressionهایی که سرور اجازه می‌دهد کلاینت برای upload درخواست کند.
اگر کلاینت نوعی بفرستد که اینجا مجاز نباشد، negotiation آن جهت رد می‌شود.
SUPPORTED_DOWNLOAD_COMPRESSION_TYPES [0, 1, 2, 3] فقط نوع‌های معتبر compression همان مفهوم برای download از سرور به کلاینت.

۳.۵.۲) بخش 📥 UDP Listener و ظرفیت ورودی

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
UDP_HOST "0.0.0.0" اگر خالی باشد همین مقدار استفاده می‌شود آدرسی که سرور DNS روی آن bind می‌شود.
0.0.0.0 یعنی روی همه interfaceها گوش بدهد.
UDP_PORT 53 1..65535 پورت UDP سرور است.
به‌طور معمول باید همان 53 باشد تا resolverها بتوانند مستقیماً به آن query بفرستند.
UDP_READERS 2 اگر <=0 باشد auto-default تعداد goroutineهای خواندن مستقیم از socket UDP.
عدد بالاتر در سرورهای پر ترافیک مفید است، ولی از یک حد به بعد فقط context switching را زیاد می‌کند.
DNS_REQUEST_WORKERS 4 اگر <=0 باشد auto-default تعداد workerهایی که requestهای ورودی را از front-door queue برمی‌دارند و به لایه session/decode می‌دهند.
MAX_CONCURRENT_REQUESTS 4096 اگر <=0 باشد fallback ظرفیت صف requestهای ورودی است.
اگر این صف پر شود، پکت‌ها drop می‌شوند و سرور rate-limited overload log می‌دهد.
SOCKET_BUFFER_SIZE 4194304 اگر <=0 باشد fallback اندازه بافر socket UDP در سطح سیستم‌عامل است.
برای burstهای ورودی زیاد مهم است.
MAX_PACKET_SIZE 65535 اگر <=0 باشد fallback اندازه بزرگ‌ترین bufferی که packet pool برای هر packet می‌گیرد.
DROP_LOG_INTERVAL_SECONDS 2.0 اگر <=0 باشد fallback حداقل فاصله بین لاگ‌های drop/overload است تا لاگ سرور در زمان فشار spam نشود.

۳.۵.۳) بخش 🧠 Deferred Session Runtime

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
DEFERRED_SESSION_WORKERS 2 clamp تا حداکثر 128 تعداد workerهای deferred session است.
این workerها کارهای ordering-sensitive و setup-heavy را برای sessionها انجام می‌دهند.
کم بودن بیش از حد آن می‌تواند setup streamها را کند کند؛ زیاد بودن بی‌مورد هم contention می‌سازد.
DEFERRED_SESSION_QUEUE_LIMIT 2048 clamp به 256..14336 ظرفیت queue deferred session برای کارهای معوق است.
اگر queue پر شود، setup یا کارهای deferred جدید ممکن است reject شوند.
SESSION_ORPHAN_QUEUE_INITIAL_CAPACITY 128 clamp به 4..4096 ظرفیت اولیه queue packetهای orphan در هر session.
STREAM_QUEUE_INITIAL_CAPACITY 256 clamp به 8..65536 ظرفیت اولیه queue هر stream در سمت سرور.
DNS_FRAGMENT_STORE_CAPACITY 512 clamp به 16..16384 ظرفیت نگهداری fragmentهای DNS query داخل تونل.
SOCKS5_FRAGMENT_STORE_CAPACITY 1024 clamp به 16..16384 ظرفیت نگهداری fragmentهای setup مربوط به SOCKS5.
پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
INVALID_COOKIE_WINDOW_SECONDS 2.0 اگر <=0 باشد fallback پنجره زمانی tracker خطاهای invalid cookie است.
برای تشخیص sessionهای خراب یا clientهایی که با cookie اشتباه سراغ سرور می‌آیند استفاده می‌شود.
INVALID_COOKIE_ERROR_THRESHOLD 10 اگر <=0 باشد fallback اگر در پنجره بالا این تعداد خطای invalid cookie دیده شود، سرور response behavior را شدیدتر می‌کند.
SESSION_TIMEOUT_SECONDS 300.0 اگر <=0 باشد fallback اگر session برای این مدت activity نداشته باشد، سرور آن را timeout و cleanup می‌کند.
SESSION_CLEANUP_INTERVAL_SECONDS 30.0 اگر <=0 باشد fallback هر چند وقت یک‌بار loop پاک‌سازی sessionها اجرا شود.
CLOSED_SESSION_RETENTION_SECONDS 600.0 اگر <=0 باشد fallback metadata session بسته تا چه مدت نگه داشته شود تا packetهای دیررس را بتوان تشخیص داد.
SESSION_INIT_REUSE_TTL_SECONDS 600.0 clamp به 1..86400 ثانیه signatureهای session init تا چه مدت برای reuse یا جلوگیری از replay ساده نگه داشته شوند.
RECENTLY_CLOSED_STREAM_TTL_SECONDS 600.0 clamp به 1..86400 ثانیه streamهای بسته‌شده تا چه مدت در جدول recently closed بمانند تا SYN دیررس دوباره آن‌ها را زنده نکند.
RECENTLY_CLOSED_STREAM_CAP 2000 clamp به 1..1000000 سقف تعداد streamهای recently closed که سرور نگه می‌دارد.
TERMINAL_STREAM_RETENTION_SECONDS 45.0 clamp به 1..86400 ثانیه streamهایی که terminal شده‌اند چه مدت قبل از sweep نهایی نگه داشته شوند.

۳.۵.۵) بخش 📛 DNS Tunnel Upstream

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
DNS_UPSTREAM_SERVERS ["1.1.1.1:53", "1.0.0.1:53"] اگر خالی باشد fallback داخلی وقتی کلاینت از داخل تونل query DNS واقعی می‌فرستد، سرور آن را به این resolverها forward می‌کند.
این بخش فقط برای DNS-over-tunnel است، نه برای خود حمل‌ونقل تونل.
DNS_UPSTREAM_TIMEOUT 4.0 اگر <=0 باشد fallback timeout هر تبادل DNS با upstream واقعی.
DNS_INFLIGHT_WAIT_TIMEOUT_SECONDS 60.0 clamp به 0.1..120 ثانیه اگر چند query یکسان هم‌زمان برسند، فقط یکی upstream lookup می‌شود و بقیه follower می‌شوند.
این مقدار می‌گوید followerها چقدر منتظر نتیجه lookup اصلی بمانند.
DNS_FRAGMENT_ASSEMBLY_TIMEOUT 300.0 اگر <=0 باشد fallback queryهای DNS تونل‌شده که چند fragment دارند تا چه مدت منتظر کامل شدن بمانند.
DNS_CACHE_MAX_RECORDS 50000 اگر کمتر از 1 باشد fallback سقف cache داخلی DNS سرور برای queryهای تونل‌شده.
DNS_CACHE_TTL_SECONDS 300.0 اگر <=0 باشد fallback TTL cache DNS داخلی سرور.

۳.۵.۶) بخش 🌐 Forwarding و SOCKS خارجی

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
SOCKS_CONNECT_TIMEOUT 120.0 اگر <=0 باشد fallback timeout اتصال outbound سرور به مقصد یا SOCKS5 خارجی.
در sample بالا گذاشته شده، ولی fallback واقعی کد 8 ثانیه است.
USE_EXTERNAL_SOCKS5 false true/false اگر true باشد، سرور به‌جای اتصال مستقیم، outboundها را از طریق SOCKS5 خارجی می‌فرستد.
این حالت بیشتر برای chaining یا مخفی کردن egress سرور مفید است.
SOCKS5_AUTH false true/false آیا SOCKS5 خارجی نیاز به username/password دارد یا نه.
SOCKS5_USER "admin" حداکثر 255 بایت نام کاربری SOCKS5 خارجی.
فقط وقتی auth روشن است معنی دارد.
SOCKS5_PASS "123456" حداکثر 255 بایت رمز عبور SOCKS5 خارجی.
اگر auth روشن باشد و این فیلد یا username خالی باشد، config نامعتبر می‌شود.
FORWARD_IP "" رشته در حالت TCP مقصد ثابت outbound است.
در حالت SOCKS5 + USE_EXTERNAL_SOCKS5=true آدرس خود پراکسی خارجی است.
FORWARD_PORT 0 0..65535 پورت endpoint بالا.
اگر USE_EXTERNAL_SOCKS5=true باشد باید مقدار معتبر و غیر صفر داشته باشد.

۳.۵.۷) بخش 🔐 امنیت

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
DATA_ENCRYPTION_METHOD 1 0..5 باید با کلاینت یکی باشد.
اگر مقدار نامعتبر بدهید، کد فعلی آن را به 1 برمی‌گرداند.
ENCRYPTION_KEY_FILE "encrypt_key.txt" مسیر نسبی یا مطلق مسیر فایل کلید رمزنگاری سرور است.
اگر نسبی باشد، نسبت به پوشه‌ی config حل می‌شود.
اگر خالی باشد fallback همان encrypt_key.txt است.

۳.۵.۸) بخش 🔄 ARQ، packing و TTLهای کنترلی

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
MAX_PACKETS_PER_BATCH 10 اگر <1 باشد fallback حداکثر تعداد control blockهایی که سرور در یک پاسخ packed می‌کند.
نکته مهم: اگر مقدار نامعتبر بدهید، fallback واقعی کد 20 است.
PACKET_BLOCK_CONTROL_DUPLICATION 1 clamp به 1..16 آخرین packed control block چند turn پشت‌سرهم تکرار شود.
1 یعنی عملاً duplication خاموش است.
در شبکه lossy برای رسیدن ACK/closeها مفید است.
STREAM_SETUP_ACK_TTL_SECONDS 400.0 clamp به 1..86400 ثانیه TTL packetهای ACK مربوط به setup stream.
STREAM_RESULT_PACKET_TTL_SECONDS 300.0 clamp به 1..86400 ثانیه TTL packetهای result مثل connect success/failure که باید به کلاینت برسند.
STREAM_FAILURE_PACKET_TTL_SECONDS 120.0 clamp به 1..86400 ثانیه TTL packetهای failure برای setup/outbound.
ARQ_WINDOW_SIZE 600 clamp به 1..16384 اندازه پنجره ARQ هر stream در سرور.
ARQ_INITIAL_RTO_SECONDS 1 clamp به 0.05..60 ثانیه RTO اولیه packetهای data.
ARQ_MAX_RTO_SECONDS 5.0 clamp به [ARQ_INITIAL_RTO_SECONDS, 120] سقف RTO data.
ARQ_CONTROL_INITIAL_RTO_SECONDS 0.5 clamp به 0.05..60 ثانیه RTO اولیه packetهای control.
ARQ_CONTROL_MAX_RTO_SECONDS 3.0 clamp به [ARQ_CONTROL_INITIAL_RTO_SECONDS, 120] سقف RTO control.
ARQ_MAX_CONTROL_RETRIES 300 clamp به 5..5000 سقف retry برای packetهای control.
ARQ_INACTIVITY_TIMEOUT_SECONDS 1800.0 clamp به 30..86400 ثانیه inactivity timeout برای streamها.
ARQ_DATA_PACKET_TTL_SECONDS 2400.0 clamp به 30..86400 ثانیه TTL packetهای data.
ARQ_CONTROL_PACKET_TTL_SECONDS 1200.0 clamp به 30..86400 ثانیه TTL packetهای control.
ARQ_MAX_DATA_RETRIES 1200 clamp به 60..100000 سقف retry packetهای data.
ARQ_DATA_NACK_MAX_GAP در sample نیامده clamp به 0..32 اگر packetهای out-of-order برسند، تا چه فاصله‌ای gap با NACK گزارش شود.
این پارامتر در کد هست و در README قبلی جا افتاده بود؛ اگر لازم دارید می‌توانید به sample config هم اضافه‌اش کنید.
ARQ_DATA_NACK_INITIAL_DELAY_SECONDS 0.4 clamp به 0..30 ثانیه تأخیر اولیه قبل از ارسال NACK برای پکت‌های داده گم‌شده. سرعت درخواست ارسال مجدد را کنترل می‌کند.
ARQ_DATA_NACK_REPEAT_SECONDS در sample نیامده clamp به 0.1..30 ثانیه برای یک sequence گمشده، NACK تکراری با چه فاصله‌ای دوباره صادر شود.
این هم در کد فعال است و باید در مستندات باشد.
ARQ_TERMINAL_DRAIN_TIMEOUT_SECONDS 120.0 clamp به 10..3600 ثانیه بعد از terminal شدن stream، سرور چقدر برای drain شدن queueها صبر کند.
ARQ_TERMINAL_ACK_WAIT_TIMEOUT_SECONDS 90.0 clamp به 5..3600 ثانیه بعد از close terminal، چقدر برای ACK نهایی صبر کند.

۳.۵.۹) بخش 🪵 لاگ

پارامتر مقدار نمونه مقادیر مجاز / رفتار واقعی توضیح کامل
LOG_LEVEL "INFO" معمولاً DEBUG, INFO, WARN, ERROR سطح لاگ سرور است.
برای تولید و استفاده روزمره معمولاً INFO کافی است.
برای بررسی دقیق session/deferred/ARQ بهتر است موقتاً DEBUG بگذارید.

بخش ۳.۶: 🧪 تست و پیدا کردن و اسکن ریزالور

پیدا کردن ریزالور و استفاده از ریزالور مناسب یکی از مهمترین بخش های پروژه های مبنتی بر تونل DNS است. در این پروژه، کلاینت خودش به‌صورت خودکار ریزالورهای سالم را پیدا می‌کند و MTU آن‌ها را تست می‌کند. شما به کمک این قابلیت کلاینت میتوانید ریزالورهای سالم را پیدا کنید، اگر قصد دارید، ریزالورهای خود را تست کنید و یا ریزالور های یک رنج را پیدا کنید، کافیست در فایل client_resolvers.txt تمام آی پی ها را به صورت خط به خط وارد کنید.

سپس از فایل client_config.toml فعلی خود یک پشتیبان بگیرید و فایل را با ویرایشگر متن باز کرده و مقادیر زیر را پیدا کرده و با مقدار های پشنهادی زیر جایگزین کنید:

MIN_UPLOAD_MTU=30
MIN_DOWNLOAD_MTU=40
MAX_UPLOAD_MTU=30
MAX_DOWNLOAD_MTU=40
MTU_TEST_PARALLELISM_RESOLVERS = 200
MTU_TEST_RETRIES_RESOLVERS = 1
MTU_TEST_TIMEOUT_RESOLVERS = 1.0

⚠️ نکته مهم: حتما باید قبل از اینکار یک سرور را راه اندازی کنید و کلید و آدرس دامنه آن را در client_config.toml وارد کنید، در غیر این صورت کلاینت نمی‌تواند تست MTU را انجام دهد و همه ریزالورها را نامعتبر تشخیص می‌دهد.

حالا برنامه را اجرا کنید و صبر کنین تست ها انجام شود، پس از پایان عملیات برنامه را ببندید. لیست ریزالورهای سالم به صورت خودکار در پوشه logs/ در قالب فایل resolver_cache_<timestamp>.log ذخیره می‌شود. هر خط شامل آدرس IP، پورت، دامنه، و مقادیر MTU است. می‌توانید آی‌پی‌ها را از این فایل کپی کرده و در client_resolvers.txt خود قرار دهید.

سپس به تنظیمات قبلی خود برگردید و از ریزالورهای سالمی که پیدا کردید استفاده کنید تا بهترین عملکرد را داشته باشید.


بخش ۳.۶: ⚡ درک بهتر از MTU و تنظیمات طلایی برای اجرای سریع

این پروژه به‌شدت به MTU مناسب وابسته است. اگر MTU را خیلی بالا بگیرید:

اگر خیلی پایین بگیرید:

پیشنهاد عملی

  1. با sample config شروع کنید.
  2. اجازه دهید کلاینت resolverها را تست کند.
  3. خروجی MTU و تعداد resolverهای معتبر را ببینید.
  4. اگر کیفیت بد است، MIN_UPLOAD_MTU و MIN_DOWNLOAD_MTU را کمی پایین‌تر بیاورید.
  5. اگر می‌خواهید startup سریع‌تر شود، بازه MIN/MAX را محدودتر و بهم نزدیک تر کنید.

بخش ۴: راهنمای استفاده در موبایل (اندروید و آیفون) 📱

از آنجایی که در حال حاضر اپلیکیشن رسمی توسط خود ما برای اندروید یا iOS ارائه نشده، می‌توانید از طریق یکی از این روش‌ها از تونل روی گوشی استفاده کنید: (شما میتوانید از کلاینت های اندروید ساخته شده توسط افراد دیگر که در بخش ۵.۱ معرفی شده‌اند هم استفاده کنید.)

روش اول: اشتراک‌گذاری پراکسی از روی کامپیوتر 📶

  1. بخش LISTEN_IP را روی 0.0.0.0 بگذارید.
  2. کلاینت را روی کامپیوتر اجرا کنید.
  3. گوشی و کامپیوتر را به یک شبکه وصل کنید.
  4. در گوشی یک پروکسی SOCKS5 با IP کامپیوتر و پورت LISTEN_PORT تنظیم کنید.

روش دوم: اجرای کلاینت روی سرور واسط 🏗️

  1. سرور اصلی را روی مقصد نهایی اجرا کنید.
  2. کلاینت را روی سرور واسط اجرا کنید.
  3. بخش LISTEN_IP را روی 0.0.0.0 بگذارید.
  4. از گوشی به SOCKS5 همان سرور واسط وصل شوید.

روش سوم: ترکیب با پنل‌های دیگر 🛠️

اگر روی یک سرور، پنل یا سرویس دیگری دارید، می‌توانید outbound آن را به SOCKS5 لوکال کلاینت StormDNS بدهید و از آن به‌عنوان مسیر خروجی استفاده کنید.

⚠️ نکات مهم امنیتی برای موبایل


بخش ۵: 🖥️ نکات و توضیحات جانبی

بخش ۵.۱: 🧩 پروژه های دیگران راجب این پروژه:

در این بخش چند پروژه مرتبط با StormDNS را معرفی می‌کنیم که توسط افراد مختلف توسعه داده شده‌اند و می‌توانند برای استفاده یا الهام گرفتن مفید باشند، البته توجه داشته باشید که این پروژه‌ها مستقل از StormDNS هستند و ممکن است با آن متفاوت باشند یا ویژگی‌های خاص خود را داشته باشند.

پیشنهاد میکنیم برای حمایت از توسعه‌دهندگان این پروژه‌ها، اگر از آن‌ها استفاده کردید یا ایده گرفتید، حتماً به مخزن گیت‌هاب آن‌ها ستاره بدهید و از آن ها حمایت کنید تا به توسعه دهنگان این پروژه ها، انگیزه بدهید و اگر مشکلی داشتید یا پیشنهادی برای بهبود داشتید، برای آن پروژه issue ایجاد کنید یا در صورت امکان pull request بزنید و در توسعه آن‌ها مشارکت کنید.

شما میتوانید با مراجعه به لینک‌های زیر این پروژه‌ها را بررسی کنید و اگر نیاز داشتید از آن‌ها استفاده کنید یا ایده بگیرید:


بخش ۵.۲: رفع مشکل اشغال بودن پورت ۵۳ (در سرور لینوکس) 🛑

در اکثر توزیع‌های لینوکس، پورت 53 توسط systemd-resolved اشغال است. اگر سرور بالا نیامد:

sudo nano /etc/systemd/resolved.conf

و این مقدار را بگذارید:

DNSStubListener=no

سپس:

sudo systemctl restart systemd-resolved

⚠️ اخطار مهم: روی یک سرور نمی‌توانید همزمان چند پروژه‌ی تونل DNS را روی پورت 53 اجرا کنید.


بخش ۶: 🛠️ معماری و نحوهٔ کار سیستم

پروژه StormDNS با ترکیب Session Multiplexing، Resolver Balancing، Packet Duplication، لایه‌ی ARQ اختصاصی و Deferred Session Runtime روی بستر UDP/DNS محدودیت‌های تونل‌های معمول را دور می‌زند.

بخش ۶.۱: 🌐 نمای کلی معماری دیاگرام

graph TD
    subgraph Client_Side ["🖥️ سیستم کاربر (Client)"]
        App["📱 برنامه‌ها (مرورگر، تلگرام و...)"]
        Proxy["🧦 پروکسی محلی SOCKS5 / TCP"]
        LDNS["📛 Local DNS (اختیاری)"]
        ResolverRuntime["⚡ Balancer + Duplication + Resolver Health"]
        ClientARQ["🔄 ARQ + Session/Stream Runtime"]
    end

    subgraph DNS_Network ["🌐 شبکه عمومی DNS"]
        R1["📡 Resolver 1"]
        R2["📡 Resolver 2"]
        RN["📡 Resolver N"]
    end

    subgraph Server_Side ["🖥️ سرور خارج از کشور (Server)"]
        UDP["📥 UDP Listener + Request Workers"]
        Sessions["🧠 Session Store + Deferred Workers"]
        ServerARQ["🔄 Server ARQ + Packed Control Blocks"]
        DNSUp["📛 DNS Upstream / Cache"]
        Out["🌐 Direct Dial یا External SOCKS5"]
    end

    App --> Proxy
    App --> LDNS
    Proxy --> ClientARQ
    LDNS --> ClientARQ
    ClientARQ --> ResolverRuntime
    ResolverRuntime --> R1
    ResolverRuntime --> R2
    ResolverRuntime --> RN
    R1 --> UDP
    R2 --> UDP
    RN --> UDP
    UDP --> Sessions
    Sessions --> ServerARQ
    Sessions --> DNSUp
    ServerARQ --> Out
    DNSUp --> UDP

بخش ۶.۲: 🔄 جریان و چرخهٔ حیات پکت‌ها

sequenceDiagram
    participant App as 📱 برنامه کاربر
    participant Client as 🖥️ کلاینت
    participant DNS as 📡 Resolverها
    participant Server as 🖥️ سرور
    participant Target as 🌐 مقصد نهایی

    App->>Client: ایجاد اتصال SOCKS5 / TCP
    Note over Client: ساخت Session/Stream<br/>رمزنگاری، ARQ، انتخاب Resolver
    Client->>DNS: ارسال DNS Query با Duplication و Balancing
    DNS->>Server: تحویل Query به NS سرور
    Note over Server: Checksum / Cookie / Session lookup<br/>Deferred setup / ARQ / Queueing
    Server->>Target: اتصال مستقیم یا از طریق SOCKS5 خارجی
    Target-->>Server: دریافت پاسخ مقصد
    Note over Server: قرار دادن دیتا در ARQ<br/>ساخت ACK و Packed Control Blocks
    Server-->>DNS: DNS Response
    DNS-->>Client: پاسخ DNS
    Note over Client: ARQ reorder / ACK consume / تحویل به برنامه
    Client-->>App: داده سالم و مرتب

بخش ۶.۳: 🧠 مفاهیم کلیدی استفاده‌شده

مفهوم (Concept) توضیح کارکرد در سیستم
Session یک اتصال کلی بین کلاینت و سرور.
Stream هر اتصال منطقی مستقل که روی Session حمل می‌شود.
Resolver Runtime انتخاب resolver، duplication، health tracking، auto-disable و recheck
ARQ ترتیب‌دهی، ACK، retransmit، timeout و terminal handling
Deferred Session Runtime کارهای ordering-sensitive مثل setup، DNS query handling و packetهای حساس
Packed Control Blocks تجمیع چند ACK یا control packet کوچک در یک block
Synced MTU MTU مشترک انتخاب‌شده بین resolverهای معتبر

بخش ۷: ⚙️ نکات فنی پیشرفته


🤝 مشارکت (Contributing)

ما از تمام مشارکت‌ها استقبال می‌کنیم. لطفاً اگر ایده، باگ یا بهبود عملکردی دارید، از طریق Issue یا Pull Request آن را مطرح کنید.

Issues

Pull Requests


📄 مجوز (License)

این پروژه تحت مجوز MIT منتشر شده است. برای جزئیات بیشتر به فایل LICENSE مراجعه کنید.


👨‍💻 توسعه‌دهنده (Developer)

توسعه‌داده‌شده با ❤️ توسط: nullroute1970


🍴 فورک (Fork)

این پروژه فورکی از MasterDnsVPN است — نسخه v2026.04.05.191930-7757d2d توسط masterking32.