پرش به محتویات

Hysteria Realms

Hysteria Realms یک حالت نظیر‌به‌نظیر (P2P) است که به سرور Hysteria اجازه می‌دهد بدون داشتن IP عمومی یا فوروارد پورت اجرا شود. یک سرویس کوچک قرار ملاقات (rendezvous) سرور و کلاینت را به یکدیگر معرفی می‌کند، سپس دو طرف با «پانچ کردن» (UDP hole punching) یک اتصال QUIC مستقیم برقرار می‌کنند. پس از باز شدن مسیر، سرویس rendezvous از مسیر خارج می‌شود — تمام ترافیک مستقیماً بین کلاینت و سرور جریان می‌یابد.

چه زمانی به این نیاز دارید؟

  • میزبانی از یک شبکهٔ خانگی پشت NAT.
  • میزبانی از کافه، هتل یا هات‌اسپات همراه که کنترلی روی روتر ندارید.
  • آزمایش‌های سریع وقتی راه‌اندازی یک VPS با پورت باز بیش از حد لازم است.
  • هر محیطی پشت CGNAT که اصلاً نمی‌توانید پورت ورودی بگیرید.

هنوز به یک مسیر UDP خروجی فعال به سرور rendezvous و شبکهٔ طرف مقابلتان نیاز دارید — چیزی که تقریباً همهٔ NATها اجازه می‌دهند.

چگونه کار می‌کند

  1. سرور Hysteria یک realm (یک نام به انتخاب شما) را در سرویس rendezvous ثبت می‌کند و آدرس‌های UDP‌ای که از طریق STUN کشف کرده را اعلام می‌کند.
  2. کلاینت با همان آدرس realm از rendezvous درخواست اتصال می‌کند. rendezvous آدرس‌های سرور را به کلاینت برمی‌گرداند و آدرس‌های کلاینت را به سرور می‌فرستد.
  3. هر دو طرف به‌صورت همزمان بسته‌های UDP به سمت یکدیگر می‌فرستند و در NAT خود سوراخ ایجاد می‌کنند.
  4. به محض باز شدن مسیر، QUIC handshake معمول Hysteria روی این اتصال مستقیم انجام می‌شود.

سرویس rendezvous فقط نقش معرفی را دارد. هیچ ترافیکی از طریق آن منتقل نمی‌شود.

آدرس realm

کلاینت و سرور هر دو با یک URI یک realm را شناسایی می‌کنند:

realm://<token>@<rendezvous-host>[:port]/<realm-name>
  • realm:// — برای ارتباط با rendezvous از HTTPS استفاده می‌کند (پورت پیش‌فرض ۴۴۳). توصیه‌شده.
  • realm+http:// — از HTTP ساده استفاده می‌کند (پورت پیش‌فرض ۸۰). فقط برای توسعه.
  • <token> — توکن bearer مشترک سرور rendezvous.
  • <realm-name> — نام realm انتخابی شما. کلاینت و سرور باید نام یکسانی استفاده کنند.

مثال: realm://[email protected]/my-server

URL از چند پارامتر اختیاری در query string نیز پشتیبانی می‌کند:

  • stun=<host:port> — سرورهای STUN را بازنویسی می‌کند. این پارامتر را تکرار کنید تا چند سرور مشخص کنید (مثلاً ?stun=stun1.example.com:3478&stun=stun2.example.com:3478). در صورت تعیین، بر realm.stunServers در فایل YAML اولویت دارد.
  • lport=<1-65535> — سوکت UDP محلی را به یک پورت مبدأ مشخص متصل می‌کند. برای باز کردن مسیر در فایروال یا گرفتن یک نگاشت NAT قابل پیش‌بینی‌تر مفید است. به‌طور پیش‌فرض از یک پورت تصادفی استفاده می‌شود.

انتخاب سرور rendezvous

می‌توانید از یک rendezvous عمومی استفاده کنید یا خودتان میزبانی کنید.

rendezvous عمومی (realm.hy2.io)

پروژهٔ Hysteria یک rendezvous عمومی روی realm.hy2.io با توکن public اجرا می‌کند:

realm://[email protected]/<your-realm-name>

هیچ تضمینی نیست. این یک سرویس رایگان و در حد توان است. ممکن است از کار بیفتد، محدودیت‌هایش تغییر کند، مسدود شود یا بدون اطلاع قبلی ناپدید شود. برای هیچ کار مهمی به آن اتکا نکنید.

همهٔ realmها توسط کاربران اجرا می‌شوند. پروژهٔ Hysteria هیچ سرور پروکسی ثبت‌شده روی realm.hy2.io را اداره، تأیید یا بررسی نمی‌کند و هرگز نخواهد کرد. هر کسی می‌تواند یک realm با هر نامی ثبت کند. فقط به realmهایی متصل شوید که اپراتور آن‌ها را می‌شناسید و به او اعتماد دارید — realm یک غریبه می‌تواند ترافیک شما را لاگ کند، MITM انجام دهد یا به‌سادگی یک تله (هانی‌پات) باشد. به هر نام realm که خودتان راه‌اندازی نکرده‌اید با همان شک‌وشبهه‌ای نگاه کنید که به یک ارائه‌دهندهٔ VPN ناشناس.

از آنجا که توکن مشترک است، هر کسی که نام realm شما را بداند یا حدس بزند می‌تواند آدرس IP سرور شما را کشف کند. نمی‌تواند از پروکسی شما استفاده کند (احراز هویت داخلی Hysteria همچنان برقرار است)، اما می‌داند کجا هستید. برای اینکه حدس زدن غیرعملی شود:

  • یک نام طولانی و تصادفی انتخاب کنید — با آن مثل یک راز رفتار کنید. مثل my-cabin-1f3a8c2e9b که خیلی سخت‌تر از home حدس زده می‌شود.
  • از نام‌هایی که شما را شناسایی می‌کنند (نام کاربری، نام میزبان و …) پرهیز کنید.

اگر هر یک از این‌ها برایتان مهم است، خودتان rendezvous را میزبانی کنید.

محدودیت‌های فعلی

نام realm باید بین ۶ تا ۶۴ کاراکتر باشد، با حرف یا رقم شروع شود و فقط شامل حروف، اعداد، - یا _ باشد. هر IP کلاینت می‌تواند هم‌زمان حداکثر ۲ realm فعال داشته باشد. این محدودیت‌ها ممکن است بدون اطلاع قبلی تغییر کنند؛ اگر به مقادیر متفاوت نیاز دارید، خودتان میزبانی کنید.

میزبانی شخصی

سرور rendezvous متن‌باز است و راه‌اندازی آن آسان است: https://github.com/apernet/hysteria-realm-server

برای هر کاربرد production، انتخاب درست یک نمونهٔ شخصی با یک توکن خصوصی و قوی است:

  • فقط کلاینت‌ها و سرورهایی که توکن را می‌دانند می‌توانند ثبت‌نام یا متصل شوند.
  • کنترل uptime، محدودیت‌ها و لاگ با شماست.
  • مصرف حافظه کم است (چند کیلوبایت برای هر realm).

برای راه‌اندازی و گزینه‌های استقرار به README پروژه مراجعه کنید.

پیکربندی سرور

برای اجرای سرور Hysteria در حالت realm، فیلد listen را به یک URI realm تنظیم کنید. سرور با TCP خروجی به rendezvous وصل می‌شود، realm را ثبت می‌کند و منتظر اتصال‌ها می‌ماند — به هیچ پورت ورودی نیاز ندارد.

listen: realm://[email protected]/your-realm-name

سایر فیلدهای سرور (auth، tls، obfs، bandwidth و غیره) بدون تغییر باقی می‌مانند. گزینه‌های تنظیم STUN، پانچ و heartbeat در پیکربندی کامل سرور مستند شده‌اند.

اگر سانسور مبتنی بر DPI نگرانی شماست، obfs را فعال کنید. در حالت realm سرور به‌جای پورت ۴۴۳ روی یک پورت UDP تصادفی گوش می‌دهد و خودِ ترافیک HTTP/3 روی یک پورت غیراستاندارد می‌تواند یک سیگنال شناسایی باشد.

پیکربندی کلاینت

server را به همان URI realm که سرور با آن ثبت‌نام کرده تنظیم کنید:

server: realm://[email protected]/your-realm-name
auth: your-hysteria-password

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

کلاینت ابتدا STUN discovery انجام می‌دهد، از rendezvous می‌خواهد او را به سرور معرفی کند، اتصال را پانچ می‌کند و سپس QUIC handshake معمول Hysteria — شامل تأیید TLS و احراز هویت با رمز عبور — انجام می‌شود. توکن realm جایگزین رمز سرور Hysteria نیست.

TLS

در حالت realm، کلاینت نام DNS‌ای ندارد که گواهی سرور را با آن تأیید کند — به IP‌ای متصل می‌شود که rendezvous برگردانده. بدون پیکربندی، کلاینت نام میزبان rendezvous را به‌عنوان SNI استفاده می‌کند که معمولاً با یک گواهی معمولی هم‌خوانی ندارد. سه گزینه دارید:

۱. گواهی self-signed با pinSHA256. روی سرور hysteria cert را اجرا کنید — کلید و گواهی تولید می‌کند و بلوک‌های tls آمادهٔ کپی برای server.yaml (cert/key) و client.yaml (insecure: true + pinSHA256) را چاپ می‌کند. pin تضمین می‌کند که کلاینت فقط همان گواهی خاص را بپذیرد، بنابراین SNI و بررسی CA دیگر مهم نیستند.

۲. گواهی واقعی CA + override برای tls.sni. برای دامنه‌ای که در اختیار دارید گواهی از طریق DNS-01 ACME بگیرید (HTTP-01 / TLS-ALPN-01 بدون IP عمومی کار نمی‌کنند)، آن را روی سرور بگذارید و در کلاینت tls.sni را برابر همان دامنه قرار دهید.

۳. گواهی برای نام میزبان rendezvous. فقط زمانی عملی است که هم rendezvous و هم سرور را خودتان میزبانی می‌کنید — گواهی سرور Hysteria را برای همان نام میزبان rendezvous صادر کنید. در این حالت SNI پیش‌فرض کلاینت بدون هیچ override تطبیق پیدا می‌کند.

سازگاری با NAT

پانچ UDP روی بیشتر شبکه‌های خانگی و موبایل کار می‌کند، اما نه روی همه.

نوع NAT در هر یک از دو طرف کار می‌کند؟
IP عمومی، بدون NAT (مثل یک VPS معمولی با پورت باز) بله
Full cone / endpoint-independent («باز») بله
Restricted cone، port-restricted cone («متوسط») بله
متقارن (Symmetric، «سخت‌گیر») گاهی

برای NATهای متقارن ما چند ترفند به کار می‌بریم که در بسیاری از موارد واقعی موفق می‌شوند، اما تضمینی نیست. اگر هر دو طرف پشت NAT متقارن باشند، احتمال موفقیت بیشتر کاهش می‌یابد.

برخی استقرارهای carrier-grade NAT (CGNAT) رفتار مشابه NAT متقارن دارند و ناپایدار خواهند بود. اگر Realms روی شبکهٔ شما کار نمی‌کند، محتمل‌ترین دلیل وجود NAT متقارن دست‌کم در یک طرف است — به یک سرور با IP عمومی برگردید.

سرورهای STUN

هم سرور و هم کلاینت برای کشف آدرس‌های UDP عمومی خود به STUN نیاز دارند تا rendezvous بتواند آن‌ها را به یکدیگر معرفی کند. اگر چیزی پیکربندی نکنید، Hysteria از یک فهرست کوچک داخلی از سرورهای عمومی STUN استفاده می‌کند:

  • stun.nextcloud.com:3478
  • stun.sip.us:3478
  • global.stun.twilio.com:3478

این‌ها توسط اشخاص ثالث اجرا می‌شوند و به‌صورت داوطلبانه ارائه می‌شوند. ممکن است از کار بیفتند، محدودیت نرخ اعمال کنند یا در شبکهٔ شما مسدود شوند. برای هر چیزی فراتر از استفادهٔ آزمایشی، Hysteria را از طریق realm.stunServers در سرور و realm.stunServers در کلاینت به سرورهای STUN خودتان (یا قابل‌اعتماد) متصل کنید.

گزارش مشکلات اتصال

Realms اجزای متعددی دارد (STUN، rendezvous، NAT punching، TLS، QUIC handshake)، بنابراین گزارش «وصل نمی‌شود» بدون لاگ تقریباً قابل پیگیری نیست. هنگام ثبت issue، هم کلاینت و هم سرور را با HYSTERIA_LOG_LEVEL=debug اجرا کنید و خروجی کامل هر دو طرف را ضمیمه کنید:

HYSTERIA_LOG_LEVEL=debug ./hysteria server -c server.yaml
HYSTERIA_LOG_LEVEL=debug ./hysteria client -c client.yaml

برای پروتکل‌های دیگر

Realms در اصل یک چارچوب عمومی برای پانچ UDP است — پروتکل rendezvous، کشف STUN و منطق پانچ هیچ وابستگی‌ای به Hysteria ندارند. Hysteria فقط اولین کاربر آن است.

هم سرور rendezvous و هم کتابخانهٔ پانچ سمت کلاینت/سرور با مجوزهای اپن‌سورس آزاد منتشر شده‌اند. از نویسندگان دیگر ابزارها و پروتکل‌های مبتنی بر UDP دعوت می‌کنیم همین پروتکل را پیاده‌سازی کنند تا هر کلاینت سازگار بتواند از طریق هر rendezvous سازگار به هر سرور سازگار برسد — دوست داریم این به یک استاندارد де‌فاکتو کوچک تبدیل شود. PR، issue و سؤالات یکپارچه‌سازی در GitHub خوش‌آمد است.