چرا URL شما به ورودی روی پورت 80 یا 443 نیاز دارد، نه 45000
مرورگر 80 یا 443 را از طرح‌واره انتخاب می‌کند، نه پورت بالای ارائه‌دهنده شما. مسیر ورود و مبدأیی را که هر گزینه انتشار باقی می‌گذارد یک بار مرور کنید.
یک نام میزبان در مرورگر تایپ کنید و طرح‌واره پورت مقصد را تعیین می‌کند: 80 برای http و 443 برای https. هیچ چیز در پاسخ DNS این را نقض نمی‌کند، و هیچ قاعده بازفرستی روی دستگاه شما نمی‌تواند شنونده‌ای در لبه ارائه‌دهنده بسازد. وقتی ارائه‌دهنده VPN پورت عمومی بالایی مانند 45000 به شما می‌دهد، URL صریح کار می‌کند و URL تمیز نه. شکاف در نقطه ورود است، نه درون برنامه.
مسیر مرورگر تا فرایند را یک بار مرور کنید و سه گزینه انتشار دیگر مرموز به نظر نمی‌رسند.
ببینید درخواست واقعاً به کجا می‌رود
مرورگر نام را به نشانی تبدیل می‌کند، سپس اگر URL پورت دیگری را نام نبرد، به آن نشانی روی پورت پیش‌فرض طرح‌واره وصل می‌شود. لبه ارائه‌دهنده شما دربارهٔ اتصال ورودی تصمیم می‌گیرد. اگر جدول بازفرست آن فقط 45000 را به نشانی داخلی شما نگاشت کند، اتصال به 80 جایی برای رفتن ندارد و پیش از دخالت دستگاه شما رد یا رها می‌شود.
این رد شدن در لبه رخ می‌دهد، به همین دلیل گزارش‌های برنامه شما هیچ چیز نشان نمی‌دهند. نبود گزارش شاهدی است بر اینکه بسته کجا متوقف شده، نه شاهدی بر خراب بودن برنامه.
چرا یک قاعده محلی نمی‌تواند لبه را درست کند
یک تغییرمسیر یا قاعده DNAT روی میزبان برنامه روی بسته‌هایی اثر می‌گذارد که از قبل رسیده‌اند. بسته‌هایی که به پورت 80 در ارائه‌دهنده فرستاده می‌شوند هرگز نمی‌رسند، بنابراین قاعده هرگز ارزیابی نمی‌شود. این شایع‌ترین ساعت تلف‌شده در کل مسئله است.
DNS هم نمی‌تواند پورت را حمل کند. مشخصات HTTP پیش‌فرض‌های طرح‌واره را تعریف می‌کند، و رکورد A یا AAAA نشانی برمی‌گرداند در حالی که CNAME نام دیگری برمی‌گرداند. مرورگر همچنان پورت طرح‌واره را می‌چسباند، بنابراین فقط پورت صریح در URL مقصد را تغییر می‌دهد.
گزینه اول: نگه داشتن پورت صریح
اغلب پاسخ درست همان گزینه بی‌تجمل است. URL کامل را با پورت منتشر کنید، TLS را روی ورودی‌ای که از آن پشتیبانی می‌کند پایان دهید، و مطمئن شوید هر پیوند تولیدشده همان مبدأ را حفظ می‌کند. برای مخاطب کوچک و کنترل‌شده این کامل است و چیزی بیش از یک شماره پورت قابل مشاهده هزینه ندارد.
در همان حال تغییرمسیرها و دامنه کوکی را بررسی کنید، زیرا بک‌اندی که نام میزبان خودش را در سرصفحه Location می‌نویسد این ترتیب را باطل می‌کند.
گزینه دوم: گرفتن ورودی واقعی روی پورت پیش‌فرض
برخی ارائه‌دهندگان و ترتیبات میزبانی، 80 و 443 را روی نشانی مشترک یا اختصاصی به عنوان سرویس مستند بازفرست می‌کنند. بپرسید واقعاً چه چیزی شامل می‌شود، به‌جای فرض اینکه نشانی خروج عمومی به معنای پورت‌های ورودی دلخواه است. نشانی خروج اختصاصی چیزی دربارهٔ بازفرست ورودی نمی‌گوید.
مالکیت و دسترس‌پذیری را کتباً تأیید کنید، از جمله اینکه وقتی تونل با نشانی دیگری دوباره متصل می‌شود چه بر سر ورودی می‌آید. ورودی‌ای که با تونل جابه‌جا می‌شود قطعی‌هایی ایجاد می‌کند که شبیه خرابی DNS به نظر می‌رسند.
گزینه سوم: قرار دادن یک فرانت‌اند در جلو
یک پراکسی معکوس روی نشانی قابل دسترس می‌تواند روی 443 گوش دادن و TLS را پایان دادن و اتصال جداگانه‌ای به بک‌اند از طریق VPN باز کند. بازدیدکنندگان نام و پورت پیش‌فرض فرانت‌اند را می‌بینند، در حالی که فرانت‌اند به نمایندگی از شما با پورت بالای بک‌اند صحبت می‌کند. این کار می‌کند چون معماری را تغییر می‌دهد نه اینکه با نقطه ورود بجنگد. آن‌گاه بک‌اند اصلاً به پورت ورودی در اینترنت عمومی نیاز ندارد.
همچنین چیزی را که اداره می‌کنید تغییر می‌دهد. فرانت‌اند مالک TLS عمومی، سیاست دسترسی، گزارش‌ها و دسترس‌پذیری است و باید انتخاب بک‌اند را به سرویس مورد نظر محدود کند. اگر پرش فرانت‌اند به بک‌اند از HTTPS استفاده می‌کند، اعتبارسنجی گواهی را روی همان پرش نگه دارید.
یک مبدأ را نگه دارید
نام میزبان عمومی، طرح‌واره و پورت فرانت‌اند مبدأیی را می‌سازند که بازدیدکنندگان استفاده می‌کنند، پس URL خارجی برنامه، تغییرمسیرها و کوکی‌ها را برای همان مبدأ تنظیم کنید. اگر برنامه پیوندهای مطلق می‌سازد، میزبان اصلی و طرح‌واره بازفرست‌شده را بفرستید. پاسخی که کاربران را به نام خصوصی یا پورت بالا برگرداند ورودی تمیزی را که تازه ساخته‌اید باطل می‌کند.
سپس با در نظر گرفتن مخاطب تصمیم بگیرید. یک URL کوتاه می‌تواند فرانت‌اند مدیریت‌شده را توجیه کند، و ارزش ندارد به‌طور تصادفی یک سرویس خصوصی فقط برای VPN را عمومی کنید.