رفتن به محتوا

نودهای Relay

زمانی که IP سرور خروجی مسدود می‌شود، کاربران دسترسی را از دست می‌دهند. relay به آن‌ها یک نقطه ورود خانگی می‌دهد که مسدود کردن آن سخت‌تر است:

کلاینت → Relay (IP خانگی) → سرور خروجی (خارج) → اینترنت

سانسور‌کنندگان ترافیک را به IP خانگی می‌بینند. relay TCP خام را به خروجی فوروارد می‌کند؛ رمزگذاری انتهایی بین کلاینت و خروجی است، بنابراین relay هرگز plaintext را نمی‌بیند.

relay Realm را اجرا می‌کند، یک TCP forwarder کوچک و بدون کپی. روی درگاه 443 (قابل تنظیم) گوش می‌دهد و به listener Reality خروجی فوروارد می‌کند. Docker و پنلی روی relay اجرا نمی‌شود.

Relays ترافیک Reality را حمل می‌کند. XHTTP، WSS و Hysteria2 روی آدرس و دامنه خود خروجی می‌مانند و در subscription به عنوان جایگزین‌ها می‌مانند.

اولین استقرار خروجی، سپس relay آن را به آن اشاره کنید:

Terminal window
meridian relay add 203.0.113.10 --exit 198.51.100.10

Meridian relay را به توپولوژی اضافه می‌کند و اعمال می‌کند:

  1. سرور relay را آماده می‌کند (بسته‌ها، BBR، سخت‌سازی SSH، firewall که تنها SSH و درگاه relay را باز می‌کند)
  2. Realm را نصب می‌کند (نسخه‌پین، SHA256-verified) به عنوان سرویس systemd
  3. relay را به listener Reality خروجی اشاره می‌کند
  4. relay را در subscription هر کلاینت منتشر می‌کند
پرچمپیش‌فرضتوضیح
--exit/-e EXIT(برای deploy مورد نیاز)سرور خروجی IP یا نام
--name NAME(خودکار)نام دوستانه برای relay (مثلاً ru-moscow)
--port/-p PORT443درگاه گوش‌کننده روی سرور relay
--sni HOSTهدف خروجیهدف پنهان‌سازی Reality برای این relay؛ برای استفاده از خروجی حذف کنید
--user/-u USERrootکاربر SSH روی relay
--ssh-port PORT22درگاه SSH روی سرور relay
--yes/-yتأیید prompts را پرش کنید
Terminal window
meridian relay add 203.0.113.10 --exit 198.51.100.10 --name ru-moscow \
--port 443 --sni dl.google.com --user ubuntu --ssh-port 2222 --yes

چگونه کلاینت‌ها متصل می‌شوند

Section titled “چگونه کلاینت‌ها متصل می‌شوند”

کلاینت‌های موجود relay را در بازخوانی subscription بعدی خود دریافت می‌کنند و صفحات اتصال آن را فهرست می‌کند. کلاینت‌های جدید آن را خودکار می‌گیرند:

Terminal window
meridian client add alice # relay شامل است
Terminal window
meridian relay list # تمام relays
meridian relay list --exit 198.51.100.10 # relays برای یک خروجی

hopهای relay را بررسی کنید — هر سرویس Realm در حال اجرا است، هر hop را به حالت بعدی می‌رساند و ورود عمومی اتصالات را می‌پذیرد — سپس ترافیک واقعی را از طریق کل مسیر آزمایش کنید:

Terminal window
meridian check 203.0.113.10
meridian test

بررسی همچنین هر leg را اندازه‌گیری می‌کند: از هر hop آن آدرس camouflage خروجی را از طریق hop بعدی دانلود می‌کند، SNI‌های هم را که کلاینت‌ها ارسال می‌کنند ارسال می‌کند و وقت اتصال، زمان تا اولین بایت و چند بایت به دست آمد را گزارش می‌کند. transfer که بین تقریباً 8 و 32 KB منجمد شود امضای throttling روی آن leg است و به‌عنوان هشدار گزارش می‌شود؛ معمول‌ترین fix relay host روی provider دیگر است (شبکهٔ دیگر، یا ASN). اگر صفحهٔ خانگی سایت camouflage کوچک‌تر از 32 KB باشد، بررسی leg نتیجه غیرقطعی است تا اینکه پاس نشود.

برای بازنشستگی relay، زنجیرهای را از طریق آن بردارید. Meridian نشان می‌دهد که چه چیزی حذف خواهد شد، تأیید می‌خواهد و سرویس Realm، قوانین firewall و نقاط ورود منتشر شده را تمیز می‌کند؛ کلاینت‌های موجود relay را در بعدی تازه‌سازی اشتراک خود از دست می‌دهند:

Terminal window
meridian relay remove 203.0.113.10

چند relay را به یک خروجی الحاق کنید، برای نمونه در شهرها یا شبکه‌های مختلف:

Terminal window
meridian relay add 203.0.113.10 --exit 198.51.100.10 --name ru-moscow
meridian relay add 203.0.113.11 --exit 198.51.100.10 --name ru-spb

کلاینت‌ها هر relay را در subscription خود دریافت می‌کنند. برای زنجیره‌های relay با بیش از یک hop، از meridian setup استفاده کنید.

در برخی محدودیت‌های اینترنت موبایل در روسیه، operators تنها لیست تأیید‌شده‌ای از سایت‌ها و آدرس‌ها را عبور می‌دهند. گزارش‌ها بسته‌ به operator، region و هفته متفاوت است و هیچ operator لیست خود را منتشر نمی‌کند. Meridian whitelists را تشخیص نمی‌دهد یا track نمی‌کند؛ این بخش آنچه را شما می‌توانید امروز تنظیم کنید و آنچه manual می‌ماند را پوشش می‌دهد.

آنچه deployers گزارش می‌دهند

Section titled “آنچه deployers گزارش می‌دهند”
  • شبکه‌ها متفاوت هستند. برخی به نظر تنها نام سرور (SNI) را که اتصال اعلام می‌کند نگاه می‌کند. دیگران همچنین IP مقصد را بررسی می‌کند. جایی که تنها نام بررسی می‌شود، یک مسیر Reality مستقیم با نام مجاز می‌تواند عبور کند. جایی که IP همچنین بررسی می‌شود، اولین hop باید بر روی لیست آدرس باشد.
  • آدرس‌های cloud داخلی معمول‌ترین اولین hop است. نه هر آدرس از یک provider فهرست‌شده است: افراد یک subnet از محدوده provider کنندهٔ یکی فهرست‌شده را توصیف می‌کند در حالی که دیگری از همان provider نیست. Providers همچنین ممکن است مشتریان خصوصی را محدود کند، محدود کنید که چند بار شما می‌تواند سرور را دوباره ایجاد کنید، یا bandwidth را shape کنید.
  • آدرس‌های CDN خارجی عموماً روی شبکه‌های موبایل مجاز نیستند. domain mode را از طریق Cloudflare به‌عنوان fallback برای اتصالات خانگی رفتار کنید، نه به‌عنوان whitelist answer.
  • relay-to-exit link همچنین می‌تواند مختل شود. relay که به کاربران می‌رسد همچنان می‌تواند اتصال خود را به exit خارجی از دست بدهد.

سرور کوچک را در یک provider داخلی اجاره کنید که آدرس آن در whitelist شبکه موبایل کاربران شما مجاز باشد. لیست‌های نگهداری‌شدهٔ جامعه‌ای از محدوده‌های مجاز وجود دارند، اما تنها test از یک اتصال موبایل در حالی محدودیت‌ها فعال است ثابت می‌کند. سپس آن را به‌عنوان relay اضافه کنید و یک نام مجاز بدهید:

Terminal window
meridian relay add 203.0.113.10 --exit 198.51.100.10 --name ru-mobile --sni allowed.example.com

با --sni، تنها این relay’s entry در subscription آن نام را اعلام می‌کند. Meridian نام را listener Reality خروجی اضافه می‌کند (کلیدهای یکسان) و relay خود listener روی خروجی می‌دهد. تنها آن نام را مسیریابی می‌کند تا Reality، همه چیز دیگر را به سایت camouflage ارسال می‌کند و تنها از آخرین hop relay قابل دسترس است. camouflage target خروجی خود و entries دیگری آن تغییر نمی‌کند. نام نیاز ندارد قابل دسترس از خروجی باشد، زیرا خروجی همچنان camouflage target خود را ارائه می‌دهد. prober که relay را بدون کلید معتبر می‌رسد بنابراین بجای دریافت proxy answer به آن target فوروارد می‌شود.

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

Terminal window
meridian check 203.0.113.10
meridian test

meridian test از ماشین خود نمی‌تواند بگوید چه شبکهٔ موبایل whitelist‌شده مجاز است. بر روی دستگاهی واقعی روی آن شبکه امتحان کنید.

--sni روی meridian deploy و meridian node add hدف camouflage برای مسیر Reality مستقیم exit را تنظیم می‌کند. هدف باید سایتی باشد که exit می‌تواند با TLS 1.3 به آن دسترسی داشته باشد، و deploy ترافیق واقعی از طریق آن بررسی کرده و متوقف می‌شود اگر هیچ کدام عبور نکند. قبل از deploy، candidate را با meridian check IP --sni HOST بررسی کنید. بر روی شبکه‌ای که تنها نام‌ها را بررسی می‌کند، نام مجاز ممکن است مسیر مستقیم را عبور دهد، اما آیا نام کار می‌کند وابسته به operator است، بنابراین هر یک را تست کنید.

آنچه Meridian انجام نمی‌دهد

Section titled “آنچه Meridian انجام نمی‌دهد”
  • آن بگوید آیا IP relay بر روی هر operator’s list است یا محدودیت‌ها فعال هستند.
  • Fronting را تنظیم کنید از طریق CDN داخلی. Domain mode برای Cloudflare built و tested است.
  • relay تنها Reality را حمل می‌کند. XHTTP، WSS و Hysteria2 روی exit می‌مانند.
  • از طریق خدمات calling یا messaging تابع شخص سوم tunnel نمی‌کند.

سرویس دیگری از درگاه گوش‌کننده روی relay استفاده می‌کند. با ss -tlnp sport = :443 بررسی کنید و آن را متوقف کنید یا درگاه دیگری با --port 8443 انتخاب کنید.

مطمئن شوید درگاه relay در firewall cloud provider یا security group باز است، نه تنها در UFW.

relay باید به درگاه Reality خروجی برسد. meridian test را برای بررسی مسیر انتهایی اجرا کنید و meridian check EXIT را برای بررسی خروجی خود اجرا کنید.

روی سرور relay، سرویس‌های forwarder را فهرست کنید و لاگ خود را بخوانید. میزبان‌های relay نام‌های خنثی استفاده می‌کند (netfwd-* units، /etc/netfwd/ configs) تا هیچ چیزی روی آن‌ها Meridian، Realm یا relay را نام‌برد:

Terminal window
systemctl list-units 'netfwd-*'
journalctl -u 'netfwd-*' --no-pager -n 20