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

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

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

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

بررسی کنید آیا هدف می‌تواند مسیرها را از هم تشخیص دهد

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

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

بررسی کنید هر گزارش در واقع چه چیزی نگه می‌دارد

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

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

بررسی کنید سیاست در واقع کجا اعمال می‌شود

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

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

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

با یک تلاش مستقیم آگاهانه بررسی کنید

سیاستی که هرگز آزموده نشده امیدی بیش نیست. از کارخواهی که به VPN وصل است، مسیری را که اکنون باید رد شود بیازمایید، سپس مسیر تأییدشده را، و هر دو نتیجه را نگه دارید. تلاش ردشده همان شواهدی است که تغییر اثر کرده است.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

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

مقالات مرتبط