دسترسی به سایت HTTPS که فقط از طریق VPN در دسترس است با یک انتقال SSH

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

مرحله یک: سه پیش‌شرط را تأیید کنید

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

دو فرمان نیمه فنی آن فهرست را روشن می‌کند. اولی ثابت می‌کند حساب و کلید بدون درخواست تعاملی کار می‌کنند، و دومی سیاست مؤثر سرور را چاپ می‌کند نه نمونه تفسیرشده در فایل پیکربندی را.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

مرحله دو: یک پورت loopback را مقید کنید و نشست را زنده نگه دارید

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

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

مرحله سه: وقتی سوکت محلی است نام HTTPS را حفظ کنید

مرور https://127.0.0.1:9443/ نام سرور TLS و اختیار برنامه را تغییر می‌دهد. گواهی صادرشده برای portal.lab.example در برابر آدرس loopback معتبر نیست، و خطای حاصل شبیه گواهی خراب است نه میان‌بر انتقال. برای آزمایش خط فرمان، URL واقعی را نگه دارید و فقط مقصد سوکت را تغییر دهید. --connect-to همین کار را می‌کند، و راهنمای curl شکل چهار میدانی استفاده‌شده در زیر را مستند می‌کند.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

نام در URL، در دست‌دادن TLS و در سرآیند Host می‌ماند، در حالی که اتصال TCP به شنونده محلی می‌رود. گزینه بدون پروکسی آزمایش را روی همین انتقال نگه می‌دارد نه اینکه پروکسی HTTP پیکربندی‌شده آن را رهگیری کند، و روشن نگه داشتن بررسی گواهی همان چیزی است که نتیجه را معنادار می‌کند.

مرحله چهار: بدانید یک انتقال چه چیزی را پوشش نمی‌دهد

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

UDP، کشف SMB و ورود به دامنه اصلاً از انتقال TCP عبور نمی‌کنند. اگر نیاز واقعی دسترسی عمومی به شبکه است، این طراحی ابزار اشتباه است و دروازه دسترسی از راه دور پشتیبانی‌شده ابزار درست است.

مرحله پنج: پاک‌سازی کنید و ثبت کنید

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

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