وقتی میزبان یک VPN خروجی اجرا می‌کند، SSH محلی را نگه دارید

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

مراحل زیر فرض می‌کنند که مدیر روی همان LAN است.مدیریت از راه دور مسئله دیگری با پاسخ دیگری است.

SSH را به نشانی‌ای که مدیران استفاده می‌کنند مقید کنید

از شنونده شروع کنید.ss -ltnp | grep :22 نشان می‌دهد که sshd به چه چیزی مقید است، و شنونده روی 0.0.0.0 اتصال‌ها را از هر رابط، از جمله تونل، می‌پذیرد. مقید کردن به نشانی LAN باریک‌تر است و نیت را آشکار می‌کند:ListenAddress 192.168.10.20 در sshd_config، و پس از آن آزمون پیکربندی و بارگذاری مجدد. یک اشتباه تایپی در آن نشانی از یک نویسه عام آشکارتر است، زیرا sshd وقتی نشانی وجود نداشته باشد از راه‌اندازی خودداری می‌کند.

بررسی کلید میزبان و احراز هویت هر کاربر را دقیقاً همان‌طور که هستند نگه دارید. «فقط شبکه محلی است» یک روش احراز هویت نیست، و کانال مدیریتی که چون مسیر کوتاه است بررسی کلید را رد می‌کند، کانالی است که در انتظار سوءاستفاده است. رزرو DHCP یا نشانی ثابت هدف را قابل پیش‌بینی می‌کند بدون آنکه آن را به هویت عمومی سرور تبدیل کند.

مسیر LAN را از تونل بیرون نگه دارید

میزبانی که نشانی‌اش در 192.168.10.0/24 است برای آن پیشوند یک مسیر متصل دارد، و یک مسیر مشخص‌تر در همان جدول بر مسیر پیش‌فرض VPN پیروز می‌شود. به همین دلیل SSH محلی اغلب وقتی تونل بالا می‌آید خودبه‌خود کار می‌کند. آن را بررسی کنید نه فرض:ip route get 192.168.10.50 رابط و نشانی مبدأیی را که هسته استفاده می‌کرد نام می‌برد، و پاسخ باید دستگاه LAN باشد نه تونل. بررسی را از ماشین مدیر هم تکرار کنید، زیرا جدول خودش تعیین می‌کند که بسته‌ها اصلاً می‌رسند یا نه. دو میزبان روی یک سیم می‌توانند درباره اینکه کدام جهت قابل دسترسی است اختلاف داشته باشند.

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

VLANهای مدیریت مسیریابی‌شده مورد دیگرند. اگر مدیر روی 192.168.50.0/24 پشت روتر محلی باشد، سرور به یک مسیر صریح برای آن پیشوند از طریق 192.168.10.1 نیاز دارد، و آن مسیر باید از اتصال مجدد جان سالم ببرد. استثنا را مخصوص پیشوند مدیریت نگه دارید؛ استثنای گسترده برای محدوده‌های خصوصی هدف تونل را باطل می‌کند.

استثنای دیوار آتش را به باریکی قاعده کنید

اگر میزبان دیوار آتش دارد، SSH را فقط از مبدأ مدیریت و فقط روی رابط LAN مجاز کنید. قاعده‌ای که پورت 22 را از همه‌جا مجاز می‌کند گسترده‌تر از نیاز است و توجیه آن در یک بازبینی دشوارتر. روی میزبان nftables قاعده به زنجیره ورودی تعلق دارد با تطبیق رابط و مبدأ؛ روی میزبان iptables معادل آن یک جفت تطبیق روی -i و -s است. قاعده را با گروه مدیری که به آن خدمت می‌کند توضیح دهید، تا بازرسی بعدی مجبور نباشد حدس بزند چرا پورت 22 باز است.

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

هر دو حالت را آزمایش کنید

آزمون را دو بار اجرا کنید: یک بار با تونل متصل و یک بار با آن قطع. در هر حالت شنونده، مسیر و یک ورود واقعی SSH از ماشین مدیر را تأیید کنید. مسیری که فقط تا وقتی تونل بالاست کار می‌کند مسیر مدیریت محلی نیست؛ یک تصادف است.

سپس تونل را در حالی که یک نشست SSH باز است دوباره راه‌اندازی کنید. نشستی که زنده می‌ماند ثابت می‌کند مسیریابی پایدار است؛ نشستی که می‌افتد به شما می‌گوید کلاینت در اتصال مجدد مسیرها یا فیلترها را بازنویسی می‌کند، که دانستنش پیش از یک رخداد ارزش دارد نه در میانه آن.

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

مسیر بازیابی را در runbook بنویسید

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

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