دروازه صفحهٔ مدیریت خودش را میزبانی می‌کند: نشانی داخلی یا عمومی

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

صفحه از بیرون بارگذاری می‌شود، نه از طریق تونل

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

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

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

نقطهٔ پایانی بیرونی را قابل دسترس نگه دارید

نمایه‌های تونل کامل به یک مسیر استثنا برای نقطهٔ پایانی VPN نیاز دارند و گزینهٔ redirect-gateway در OpenVPN دقیقاً همین را مستند می‌کند: نقطهٔ پایانی دور مسیری از طریق دروازهٔ از پیش موجود نگه می‌دارد تا تونل به درون خودش مسیریابی نکند. آن استثنا را بردارید و حمل‌ونقل رمزنگاری‌شده از تونل پیروی می‌کند و این نشست را در یک حلقه پایان می‌دهد. همان استثنا دلیل آن است که نشانی نقطهٔ پایانی از داخل تونل قابل دسترس می‌ماند.

پیامد این است که نشانی عمومی از سمت کلاینت قابل دسترس می‌ماند و به همین دلیل درخواست مرورگر به آن نشانی می‌تواند همان استثنا را دنبال کند و بدون ورود به تونل خارج شود. استثنا کار خودش را می‌کند و نام است که آسیب می‌زند.

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

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

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

به سرویس یک نام خصوصی بدهید

سرویس به نامی نیاز دارد که در داخل تونل به نشانی دروازه تبدیل شود و در همان حال معنای گواهی و نام میزبان را که برنامه انتظار دارد حفظ کند. یک رکورد ناحیهٔ خصوصی برای نام مدیریت پاسخ معمول است و نام حمل‌ونقل را دست‌نخورده می‌گذارد.

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

هر دو خانوادهٔ نشانی را هم بررسی کنید، چون رکورد AAAA جامانده می‌تواند مرورگر را جایی بفرستد که طرح خصوصی هرگز آن را پوشش نمی‌داد.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

سیاست را با جایی که فرایند اجرا می‌شود هماهنگ کنید

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

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

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

دسترسی خصوصی و مسیر عمومی ردشده را بررسی کنید

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

اتصال‌ها و وضعیت فیلتر را بخوانید نه نام میزبانی را که به کاربران داده شد. در معرض بودن ویژگی سوکت است نه نام. آن تمایز از هر تغییر DNS جان سالم به در می‌برد.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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