دامین فرانتینگ

یک دامین فرانت نام میزبان یک CDN است که اپ‌های کاربران به‌جای نود شما به آن وصل می‌شوند. CDN اتصال را می‌گیرد، از روی نام میزبانی که به آن داده شده سرور شما را پیدا می‌کند، و اتصال خودش را به نود شما باز می‌کند. در این صورت کاربران به CDN وصل می‌شوند و آدرس نود شما اصلاً لازم نیست در اشتراکشان بیاید.

فرانت‌ها زیر پیکربندی‌های هسته ← دامین فرانتینگ قرار دارند. می‌توانید تا هشت فرانت داشته باشید، و هر اینباند می‌تواند تا چهار فرانت داشته باشد.

فرانت چطور به اشتراک اضافه می‌کند

فرانت مال یک اینباند است، نه یک نود. CDN انتخاب می‌کند با کدام سرور شما صحبت کند، پس یک فرانت همه‌ی نودهایی را که آن اینباند را سرو می‌کنند پوشش می‌دهد، و برای هر اینباند یک ورودی به اشتراک کاربر اضافه می‌کند، هرگز یکی برای هر نود.

سه نود که یک اینباند را سرو می‌کنند، هر کدام با دو آدرس لینک، و دو فرانت روی آن اینباند:

3 nodes × 2 addresses = 6 direct entries
              2 fronts = 2 front entries
                         ───────────────
                         8 entries

فرانت‌ها و آدرس‌های نود با هم جمع می‌شوند؛ هرگز در هم ضرب نمی‌شوند. صفحه نشان می‌دهد هر فرانت چند ورودی اضافه می‌کند.

کدام اینباندها را می‌توان فرانت کرد

CDN خودش اتصال TLS را تمام می‌کند و درخواست‌های HTTP را به سرور شما می‌فرستد. پس اینباندی را فقط وقتی می‌توان فرانت کرد که HTTP را روی ترنسپورتی صحبت کند که CDN حملش می‌کند:

WebSocket، HTTPUpgrade، gRPC، XHTTP و HTTP/2.

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

رد می‌شود	چرا
REALITY	به کلید خود اینباند گره خورده، و CDN گواهی خودش را ارائه می‌کند. این دو با هم کار نمی‌کنند.
Hysteria، Hysteria2، TUIC	روی QUIC (UDP) کار می‌کنند؛ CDN درخواست HTTP می‌فرستد.
پرش پورت	بازه‌ی پورت مال شنونده‌ی خود نود است؛ فرانت یک نام میزبان روی یک پورت است.
TCP خام، AnyTLS، ShadowTLS، SOCKS، SSH و مشابه آن‌ها	CDN نمی‌تواند جریانی را که درخواست HTTP نیست حمل کند.
XHTTP که آپلودش را در یک هدر یا کوکی می‌فرستد	CDN محتوا را در آن جاها حمل نمی‌کند.

برای هر کدام از این‌ها، به‌جای فرانت یک آدرس دوم به نود اضافه کنید: آدرس‌های لینک نود را در نودها ببینید. پیش‌تنظیم‌های اینباند VLESS + WebSocket + TLS و VLESS + gRPC + TLS برای فرانتینگ ساخته شده‌اند.

راه‌اندازی فرانت

اول در CDN خود:

1. نام میزبان را اضافه کنید، با پراکسی از راه CDN (در Cloudflare، ابر نارنجی).
2. آن را به‌عنوان مبدأ به آدرس نود خود اشاره دهید.
3. اگر اینباند پشت CDN TLS خودش را ندارد، HTTP ساده تا مبدأ را مجاز کنید. این رایج و بی‌اشکال است: اتصال رمزنگاری‌شده‌ی کاربر با CDN است.

بعد در پنل، در پیکربندی‌های هسته ← دامین فرانتینگ، روی افزودن کلیک کنید:

فیلد
برچسب	نام فرانت است، و به نام ورودی‌هایی که می‌سازد اضافه می‌شود تا دو فرانت روی یک اینباند از هم تشخیص داده شوند.
آدرس	نام میزبان CDN که اپ‌ها به آن وصل می‌شوند. *.cdn.example.com به هر مشترک نام خودش را می‌دهد (پایین‌تر).
پورت	خالی یعنی ۴۴۳. این پورت CDN است، نه پورت اینباند.
SNI، Host	خالی یعنی نام میزبان خود فرانت فرستاده شود، که CDN همین را انتظار دارد. فقط اگر CDN شما در مبدأ نام دیگری لازم دارد پرشان کنید.
ALPN، اثر انگشت، اجازه‌ی اتصال ناامن	TLS اپ به سمت CDN. CDN گواهی معتبر دارد، پس اجازه‌ی اتصال ناامن را خاموش بگذارید.
هدر آدرس کلاینت	هدر آدرس کلاینت را ببینید.
نود مبدأ	اختیاری. پایین‌تر را ببینید.
ترتیب	جای ورودی‌های این فرانت در اشتراک.
اینباندها	اینباندهایی که به آن‌ها می‌رسد. فقط اینباندهایی که CDN می‌تواند حمل کند پیشنهاد می‌شوند.

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

ورودی فرانت آدرس، پورت، SNI، Host، ALPN و اثر انگشت را از فرانت می‌گیرد، و مسیر و بقیه‌ی چیزها را از اینباند. هر پین گواهی و بازه‌ی پرش پورت را کنار می‌گذارد، چون CDN گواهی خودش را ارائه می‌کند.

تغییرهای فرانت در دریافت بعدی اشتراک به کاربران می‌رسند؛ چیزی به نودها فرستاده نمی‌شود، به‌جز هدر آدرس کلاینت.

یک نام میزبان برای هر مشترک

آدرس را به شکل *.cdn.example.com بنویسید تا هر مشترک نام میزبان خودش را زیر آن بگیرد، مثل k7m2rq9xdp.cdn.example.com. در این صورت نام میزبانی که از کار بیفتد روی یک مشتری اثر می‌گذارد، نه همه‌ی آن‌ها.

• نام از روی اشتراک کاربر به دست می‌آید، پس هر بار که اپش به‌روز می‌شود همان است، و برای هر کاربر متفاوت است. نمی‌توان از روی آن به اشتراک رسید.
• یک رکورد DNS وایلدکارد لازم دارید، *.cdn.example.com، با پراکسی از راه CDN. بدون آن، نام‌ها برای هیچ‌کس ترجمه نمی‌شوند.
• بررسی کنید گواهی CDN شما این نام را پوشش دهد. در Cloudflare، گواهی رایگان Universal SSL دامنه‌ی example.com و یک سطح زیر آن (*.example.com) را پوشش می‌دهد، نه *.cdn.example.com را. یا وایلدکارد را مستقیم زیر zone خود بگذارید، یا از پلنی از Cloudflare استفاده کنید که برای نام‌های عمیق‌تر گواهی صادر می‌کند. CDNهای دیگر قاعده‌های خودشان را دارند.

نود مبدأ

نود مبدأ می‌گوید CDN به کدام نود می‌فرستد. ورودی اضافه نمی‌کند. پنل از آن استفاده می‌کند تا فرانت را از اشتراک کاربری که روی آن نود نیست کنار بگذارد، چون آن ورودی آن‌جا نمی‌توانست وارد شود، و تا وقتی آن نود اینباندی را که فرانت را روی آن فعال کرده‌اید سرو نمی‌کند به شما هشدار دهد. وقتی CDN شما مبدأ را انتخاب می‌کند، آن را روی هر نودی بگذارید.

فقط از راه فرانت

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

این کلید برای هر کاربر جدا اعمال می‌شود، و فقط جایی که واقعاً برای آن کاربر ورودی فرانت نوشته شده باشد. کاربری که همه‌ی فرانت‌هایش کنار گذاشته شده‌اند (مثلاً به‌خاطر نود مبدأیی که روی آن نیست) به‌جای گرفتن فایل خالی ورودی‌های مستقیم را نگه می‌دارد. اگر هیچ فرانتی روی اینباند فعال نباشد، کلید هیچ کاری نمی‌کند.

هدر آدرس کلاینت

پشت CDN، همه‌ی اتصال‌ها به نود شما از آدرس‌های CDN می‌آیند. هدر آدرس کلاینت نام هدری است که CDN آدرس واقعی کاربر را در آن می‌فرستد: CF-Connecting-IP برای Cloudflare، True-Client-IP برای Akamai، Fastly-Client-IP، یا AR-Real-IP برای ابر آروان.

وقتی تعیین شده باشد، هر اینباند XHTTP که فرانت روی آن فعال است آدرس کاربر را از آن هدر می‌خواند، تا محدودیت‌های دستگاه و آدرس و لاگ‌ها کاربر واقعی را ببینند. این آدرس فقط وقتی قابل اعتماد است که:

• CDN خودش هدر را بنویسد، نه این‌که هدری را که اپ فرستاده عبور دهد (مستندات CDN خود را بررسی کنید)؛
• نود فقط از CDN اتصال بپذیرد، چون اپی که مستقیم به نود برسد هم می‌تواند این هدر را بفرستد؛
• همه‌ی فرانت‌های روی اینباند همان هدر را نام ببرند.

تغییر این هدر تنها تغییر فرانت است که به نودها می‌رسد: اینباندهای XHTTP مربوط را آن‌جا ری‌استارت می‌کند، که اتصال‌های زنده‌شان را قطع می‌کند.

اینباندهای پشت ingress

یک ingress بر اساس نامی که در دست‌دهی TLS آمده مسیر می‌دهد. CDN با نام میزبان فرانت به نود شما وصل می‌شود، پس مسیر ingressی که آن نام میزبان را فهرست نکرده ترافیک را به fallback خودش می‌فرستد. نام میزبان فرانت را به مسیر اضافه کنید، یا پسوندی مثل .cdn.example.com که فرانت وایلدکارد را هم پوشش دهد. تا این کار را نکنید پنل هشدار می‌دهد.

مرتبط

• اینباندها: اینباندهایی که فرانت به آن‌ها می‌رسد.
• اشتراک‌ها و صفحه‌ی اشتراک: دامنه‌های اشتراک، که می‌توانند به همین شکل وایلدکارد داشته باشند.
• نودها: آدرس‌های لینک، جایگزین برای اینباندهایی که CDN نمی‌تواند حمل کند.
• از قالب تا لینک: یک اشتراک چطور سر هم می‌شود.