این دو تکنیک کنار هم بایگانی می‌شوند چون هر دو یک واسطه دارند و هر دو شبیه پنهان‌کاری به نظر می‌رسند. اما روی اشیای متفاوتی کار می‌کنند. دامنه‌فرانتینگ درباره این است که کدام نام در کدام لایه یک درخواست HTTPS ظاهر می‌شود. VPN درباره این است که کدام بسته‌ها مسیر مشخصی را تا یک همتا طی می‌کنند. نامیدن فرانتینگ به‌عنوان نوعی VPN به طرح‌هایی می‌رسد که نمی‌توانند کار کنند و به بازبینی‌هایی که پرسش اشتباه را می‌پرسند.

دو نام، دو لایه

یک اتصال TLS می‌تواند نام سرور را در دست‌دادن خود حمل کند. وقتی اتصال برقرار شد، درخواست HTTP مرجعی را که می‌خواهد مشخص می‌کند، معمولاً در سرآیند Host. این‌ها دو فیلد هستند که در دو لحظه متفاوت توسط دو بخش متفاوت نرم‌افزار خوانده می‌شوند.

LayerWhat carries the nameWho reads it
TLS handshakeServer name indicationThe TLS terminator in front of the service
HTTP requestAuthority or Host headerThe routing layer that picks a backend
Network pathDestination address and portRouters, and the VPN peer if one is in use

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

فرانتینگ به ارائه‌دهنده بستگی دارد، نه به تکنیک

به‌عنوان یک مثال محدود، راهنمای پرسش‌های متداول Front Door Azure محافظت‌های دامنه‌فرانتینگ را مستند می‌کند. در آن یک ناهمخوانی مجاز برای دامنه‌های درون یک اشتراک و مسیرهای پیکربندی‌شده توصیف شده است، و پاسخ 421 Misdirected Request زمانی که محافظت ناهمخوانی درخواستی را مسدود می‌کند.

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

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

VPN در واقع چه چیزی را انتخاب می‌کند

در یک VPN شبکه‌ای، مسیریابی و سیاست پلتفرم ترافیک داخلی را برای تونلی به یک همتا انتخاب می‌کنند. بسته به چیدمان، این می‌تواند چند برنامه یا زیرمجموعه‌ای معین را پوشش دهد و می‌تواند پروتکل‌هایی را حمل کند که هیچ درخواست HTTP ندارند.

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

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

قابلیت مشاهده دودویی نیست

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

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

سه جعبه را رسم کنید

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

وقتی جعبه‌ها جدا شدند، پرسش‌ها پاسخ‌پذیر می‌شوند: این ارائه‌دهنده کدام نام‌ها را می‌پذیرد، کدام پروتکل‌ها به حمل نیاز دارند و کدام طرف چه چیزی را می‌تواند ببیند. نموداری که آن‌ها را ادغام می‌کند طرحی تولید می‌کند که هیچ‌کس نمی‌تواند پیاده کند و بازبینی‌ای که بر سر واژگان بحث می‌کند.

مقالات مرتبط