اینجا سه لایه انتقال روی هم می‌افتند و هر یک قاب‌بندی خودش را دارد۔ بار VPN درون یک نشست TLS سفر می‌کند، آن نشست TLS درون یک اتصال TCP به یک درگاه حلقه‌بازگشت سفر می‌کند، و بایت‌های آن اتصال درون SSH به یک میزبان رله سفر می‌کنند که اتصال TCP واقعی را به شنونده VPN باز می‌کند۔ هیچ چیز در این چیدمان تغییر نمی‌دهد آنچه را که OpenVPN تأیید می‌کند، و هیچ چیز در آن یک شنونده UDP را از طریق TCP قابل‌دسترس نمی‌کند۔ بقیه را به‌عنوان توصیف مسیر بایت‌ها بخوانید، نه دستور دور زدن یک کنترل شبکه۔

هدایت محلی در واقع چه چیزی را جابه‌جا می‌کند

کارخواه SSH روی یک درگاه محلی گوش می‌دهد۔ وقتی یک فرایند محلی وصل می‌شود، کارخواه بایت‌ها را در کانال رمزگذاری‌شده‌اش بسته‌بندی می‌کند و سمت سرور یک اتصال TCP تازه به مقصد نام‌برده در درخواست هدایت باز می‌کند۔

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

شروع نشست SSH فقط ثابت می‌کند که رله قابل‌دسترس و تأییدشده است۔ درباره اینکه شنونده بعدی بالا هست یا نه، آیا دیوار آتشی بین رله و شنونده اتصال را می‌پذیرد، یا آیا VPN پروفایل شما را می‌پذیرد چیزی نمی‌گوید۔

کارخواه را به شنونده محلی نشانه بگیرید

یک نمونه اعلام‌شده: رله می‌تواند به یک شنونده TCP در gw.internal.example:443 برسد، و یک درگاه محلی بالا آن مسیر را فقط برای همین ماشین آشکار می‌کند۔

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

راهنمای OpenSSH هدایت محلی را چنین توصیف می‌کند: پذیرش اتصال‌های TCP به‌صورت محلی و باز کردن اتصال بعدی از سمت دور۔ شنونده را به حلقه‌بازگشت ببندید نه به همه رابط‌ها، چون هدایتی که از شبکه قابل‌دسترس باشد یک رله باز با نام شماست۔ بستن با عام‌بند درگاه را برای هر حساب محلی دیگر روی ماشین مشترک هم آشکار می‌کند۔

سپس کارخواه VPN را در حالت TCP بگذارید و آن را به 127.0.0.1:24011 نشانه بگیرید۔ اگر پروفایل از UDP استفاده می‌کند، این طراحی نمی‌تواند کمک کند: هدایت یک جریان بایت حمل می‌کند و مسیری برای داده‌نگارها از آن نمی‌گذرد۔

دو تأیید هویت را جدا نگه دارید

SSH میزبان رله را تأیید می‌کند۔ OpenVPN هنوز هم همتای VPN را تأیید می‌کند و مقصد حلقه‌بازگشت آن شرط را تغییر نمی‌دهد۔ خاموش کردن بررسی‌های گواهی چون سوکت اکنون به localhost اشاره می‌کند بدترین میانبر در این طراحی است۔ این چیدمان انتقال را به چیدمان اعتماد تبدیل می‌کند و هیچ‌کس با دومی موافقت نکرده است۔

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

با رله به‌عنوان طرف دوم داستان اعتماد رفتار کنید: مدیرش می‌تواند فراداده اتصال‌ها را ببیند و اگر پیکربندی تغییر کند می‌تواند هدایت را تغییر مسیر دهد۔ چیدمان به تأیید هم رله و هم مالک سرویس VPN نیاز دارد، نه فقط کسی که امروز به آن نیاز دارد۔

زیر تونل حلقه نسازید

وقتی VPN مسیرها را نصب می‌کند، اتصال SSH که آن را حمل می‌کند هنوز به مسیری به رله نیاز دارد که از تونل نگذرد۔ اگر مسیر پیش‌فرض به VPN برود و رله فقط از همان تونل قابل‌دسترس باشد، انتقال فرو می‌ریزد و VPN هم با آن می‌رود۔ خطا شبیه تونل افتاده است نه اشتباه مسیریابی، و به همین دلیل بد تشخیص داده می‌شود۔

راه‌حل معمول یک مسیر میزبان به نشانی رله است که پیش از بالا آمدن تونل به رابط فیزیکی سنجاق می‌شود، به‌همراه بررسی اینکه مسیر از اتصال دوباره جان سالم به در می‌برد۔ آن را با جست‌وجوی مسیر برای نشانی رله بررسی کنید نه با فرض درست بودن ترتیب۔

همچنین انتظار داشته باشید این پشته از یک اتصال مستقیم کندتر و شکننده‌تر باشد، چون اکنون دو انتقال مرتب و یک نقطه پایانی دیگر برای نگهداری وجود دارد۔ این روشی برای عبور از مرز شبکه است، نه یک تکنیک کارایی۔

وقتی کارتان تمام شد شنونده را ببندید

وقتی تونل دیگر لازم نیست نشست SSH را متوقف کنید و تأیید کنید که درگاه محلی آزاد شده است۔ هدایت فراموش‌شده مسیری تأییدشده را روی ماشینی که ممکن است مشترک باشد باز نگه می‌دارد۔

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

مقالات مرتبط