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

دو نام، دو نوع انتقال

به وب‌سایت یک رکورد پروکسی‌شده بدهید تا ترافیک HTTP و HTTPS آن از Cloudflare عبور کند. به VPN یک رکورد فقط DNS بدهید که مستقیماً به ورودی عمومی VPN حل شود، و بگذارید کلاینت از پورت UDP یا TCP که برای آن پیکربندی شده استفاده کند.

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

مرجع پورت‌های شبکه در Cloudflare فهرست می‌کند که پروکسی وب معمولی کدام پورت‌ها را می‌پذیرد. آن فهرست درباره HTTP و HTTPS روی همان پورت‌هاست، نه درباره پروتکل‌های دلبخواهی که تصادفاً یک شماره را شریک می‌شوند.

پورت همان پروتکل نیست

انتقال OpenVPN به TCP 443 آن را به HTTPS تبدیل نمی‌کند. پروکسی هنوز در آغاز اتصال انتظار یک درخواست HTTP دارد، و کلاینت OpenVPN به جای آن یک پیام کنترل دودویی می‌فرستد. اتصال به گونه‌ای شکست می‌خورد که شبیه مسدودسازی شبکه است، چون هیچ چیز مفیدی به گزارش نمی‌رسد.

اگر واقعاً لازم است محصولی از Cloudflare در مسیر داده VPN قرار گیرد، محصولی را ارزیابی کنید که پشتیبانی از پروتکل مورد نیاز شما را مستند کرده باشد. فرض نکنید ابر نارنجی یک تونل عمومی TCP یا UDP است، چون این یک پروکسی معکوس برای ترافیک وب با کار مشخص است.

رکورد فقط DNS پاسخ خسته‌کننده‌ای است که کار می‌کند، و همان چیزی است که باید اول به سراغش رفت.

یک ماشین هنوز به دو شنونده نیاز دارد

نام‌های جداگانه اجازه نمی‌دهند دو فرایند هم‌زمان همان نشانی، پورت و انتقال را بگیرند. اگر سرور وب از قبل TCP 443 را روی همه نشانی‌ها گرفته باشد، یک نمونه OpenVPN هم نمی‌تواند آن را بدون ترتیبی عامدانه بگیرد.

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

گواهی‌ها از اتصالی که از آن محافظت می‌کنند پیروی می‌کنند

اتصال TLS مرورگر به Cloudflare و اتصال Cloudflare به مبدأ شما دو رابطه جدا با دو گواهی جدا هستند. مرورگر گواهی لبه را می‌بیند. مبدأ گواهی خودش را به Cloudflare ارائه می‌دهد، و گواهی Cloudflare Origin CA دقیقاً برای همان رابطه دوم در نظر گرفته شده است.

Cloudflare در حالت Full (strict) به آن گواهی مبدأ اعتماد می‌کند و آن یک گواهی مرورگر با اعتماد عمومی نیست. اگر کسی نام میزبان فقط DNS را مستقیم باز کند و هشدار بگیرد، این پیامد انتظارشده یک مسیر اعتماد تغییرکرده است، نه شاهدی بر توقف رمزنگاری.

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

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

مواجهه از نام پیروی می‌کند

رکورد VPN فقط DNS نشانی‌ای را که به آن اشاره می‌کند منتشر می‌کند. اگر آن نشانی همان مبدأ وب هم باشد، مبدأ پنهان نیست، و توصیف آن به‌عنوان پنهان چون نام دیگر پروکسی‌شده است، خطایی است که تا کسی آن را اسکن نکند باقی می‌ماند.

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

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

ترتیب کار: نام پروکسی‌شده برای سایت، نام فقط DNS برای VPN، شنونده‌های جدا، گواهی برای هر رابطه، و سپس یک آزمون که ثابت می‌کند هر نام فقط به سرویسی می‌رسد که باید.

مقالات مرتبط