یک IP اختصاصی VPN وب‌سایت شما را منتشر نمی‌کند
یک نشانی خروج اختصاصی درباره تحویل ورودی چیزی نمی‌گوید. قرارداد ارسال را بررسی کنید، سمت مبدأ را کامل کنید و سپس یک پورت بالا منتشر کنید.
خرید یک IP اختصاصی از ارائه‌دهنده VPN مثل خرید یک درِ ورودی است. نشانی پایدار است، تونل برپاست و با این حال سایت برای هیچ‌کس در بیرون باز نمی‌شود. آنچه خریده‌اید یک تخصیص است، نه قاعدهٔ ارسال ورودی. هر دو در یک فروشگاه فروخته می‌شوند و در جاهای کاملاً متفاوتی پیکربندی می‌شوند.
نشانی یک تخصیص است، نه قاعدهٔ ارسال
نشانی عمومی ورودی یا نام میزبان، انتقال مجاز، پورت بیرونی تخصیص‌یافته و مقصد سمت مشتری را که ارائه‌دهنده به آن تحویل می‌دهد ثبت کنید. سپس تأیید کنید که سرور، پروتکل و ویژگی حساب که انتخاب کرده‌اید واقعاً از ارسال پشتیبانی می‌کنند و ارائه‌دهنده میزبانی روی آن را مجاز می‌داند.
واژهٔ اختصاصی، تخصیص نشانی را توصیف می‌کند. به این معنا نیست که ترافیک ورودی ناخواسته مجاز است، و افزودنی‌های مختلف یک اپراتور می‌توانند توانایی‌های متفاوتی داشته باشند. نشانی اختصاصی و محصول سرور اختصاصی دو برچسبی هستند که بیشتر از همه با هم اشتباه گرفته می‌شوند و صفحه‌های پشتیبانی معمولاً روشن می‌کنند کدام‌یک ارسال می‌کند.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
یک قرارداد نمونه چنین است: ارائه‌دهنده TCP 203.0.113.60:45000 را به سرویس HTTPS دستگاه متصل شما روی پورت 8443 تحویل می‌دهد. این توصیف نگاشتی است که شخص دیگری پیکربندی کرده، نه قاعده‌ای که بتوانید با تایپ آن در فایروال خودتان در لبهٔ آن‌ها بسازید.
سمت مبدأ را کامل کنید
اگر برنامهٔ وب روی خودِ مشتری VPN اجرا می‌شود، به یک شنونده روی پورت تحویل‌شده و اجازهٔ ورودی محلی محدود برای آن پورت نیاز دارد. اگر مشتری اتصال نگاشته‌شده را به میزبان دیگری ارسال می‌کند، به ترجمهٔ مقصد، سیاست ارسال و مسیر پاسخ نیاز دارد که رفت‌وبرگشت را تحمل کند.
قواعد دسترسی را حول نشانی مبدأیی طراحی کنید که مسیر ارائه‌دهنده واقعاً ارائه می‌کند. این همیشه بازدیدکنندهٔ اصلی نیست و همیشه سرور VPN هم نیست، و این وقتی مهم می‌شود که قاعده‌ای می‌نویسید که فقط یکی از آن نشانی‌ها با آن تطبیق می‌یابد.
ترجمهٔ پورت هم HTTP را به HTTPS تبدیل نمی‌کند. پورت عمومی و پورت محلی برنامه می‌توانند آزادانه متفاوت باشند، اما طرح، هویت گواهی و تغییرمسیرها باید با سرویسی که مردم واقعاً به آن می‌رسند هم‌خوانی داشته باشند. اگر گواهی میزبان عمومی را نام می‌برد، این نام را در هر گام حفظ کنید. ناسازگاری در اینجا به‌صورت هشدار مرورگر ظاهر می‌شود نه خطای مسیریابی، و مردم را یک ساعت به گزارش‌های اشتباه می‌فرستد.
پورت بالا را صادقانه منتشر کنید
اگر بازدیدکنندگان مستقیم وصل می‌شوند و ارائه‌دهنده پورت بالایی تخصیص داده است، نشانی کامل را به آن‌ها بدهید. یک رکورد نشانی DNS معمولی نمی‌تواند به درخواست HTTPS که به‌طور پیش‌فرض از 443 استفاده می‌کند پورت اضافه کند، و هیچ دستکاری TTL این را تغییر نمی‌دهد.
یک فرانت‌اند وب می‌تواند این را با پذیرش بازدیدکنندگان روی پورت معمول و برقراری اتصال خودش به پورت مبدأ ارسال‌شده حل کند. اما پورت‌های پیش‌فرض پروکسی Cloudflare یک فهرست مشخص است و یک پورت تخصیص‌یافتهٔ دلخواه فقط با افزودن یک رکورد DNS پروکسی‌شده به پورت لبهٔ پشتیبانی‌شده تبدیل نمی‌شود.
تغییر پورت مقصد مبدأ عملیاتی متفاوت از تغییر پورت بازدیدکننده است. Origin Rules در Cloudflare بازنویسی پورت مقصد را برای اتصال بک‌اند مستند می‌کند، محدود به قاعده، طرح و نام میزبان پشتیبانی‌شده. بازنویسی پورت یک رلهٔ عمومی برای UDP دلخواه یا پروتکل‌های دیگر نیست.
وقتی یک فرانت‌اند TLS را پایان می‌دهد، هر دو گام را اعتبارسنجی کنید: گواهی از مرورگر تا فرانت‌اند و اتصال از فرانت‌اند تا مبدأ. گام VPN هیچ‌کدام از این دو بررسی را جایگزین نمی‌کند، و نشت یک نشانی داخلی به تغییرمسیرها یا کوکی‌ها نشانهٔ معمول این است که فقط یکی از این دو با در نظر گرفتن نام عمومی پیکربندی شده است.
نگاشت را زنده نگه دارید
برخی ارائه‌دهندگان پس از اتصال دوباره پورت دیگری تخصیص می‌دهند و یک نگاشت اجاره‌ای ممکن است به تمدید از طریق اقدامی در سمت ارائه‌دهنده نیاز داشته باشد. سازوکاری را که ارائه‌دهنده‌تان مستند می‌کند پیگیری کنید و شنونده، قواعد محلی، DNS یا قاعدهٔ فرانت‌اند را فقط جایی به‌روز کنید که قرارداد کنونی آن را می‌طلبد.
یک نشانی عمومی ثابت، اجارهٔ پورت را ثابت نمی‌کند. نشانی و پورتی که هنوز در داشبورد نشان داده می‌شوند اثبات این نیست که نشست فعال مالک نگاشت است، به همین دلیل آزمون یک درخواست تازه از بیرون است نه یک تصویر صفحه.
سپس مواردی را که انتظار دارید تکرار کنید: یک اتصال دوبارهٔ معمولی و یک قطع VPN. اگر قطع باید مبدأ را در دسترس‌ناپذیر کند، نگذارید یک به‌روزرسان در پس‌زمینه بی‌صدا مسیر مستقیم ISP را دوباره منتشر کند. و اگر قرارداد ارسال نمی‌تواند نیازهای پایداری سایت را برآورده کند، ترتیب انتشار دیگری برگزینید به‌جای خرید یک برچسب نشانی دیگر و امید به اینکه مثل سرور رفتار کند.