SSH از راه دور روی VPN: کاری که تونل انجام نمی‌دهد
یک VPN سرور SSH را قابل دسترس می‌کند و نه چیز دیگری. سه شرط تعیین می‌کند که مناسب است یا نه، و مرحله خطا نشان می‌دهد کدام لایه مقصر است.
یک VPN به سرور SSH مسیری خصوصی می‌دهد و نیاز به شنوندهٔ عمومی روی پورت 22 را برمی‌دارد. این کار میزبان را احراز هویت نمی‌کند، کاربر را مجاز نمی‌کند و تعیین نمی‌کند که کدام حساب‌ها می‌توانند وارد شوند. این‌ها همچنان کار SSH است. اینکه VPN راه درستی برای رسیدن به سرور باشد به سه شرط بستگی دارد، و تونل تنها یکی از پاسخ‌های ممکن است.
تونل چه چیزی را تغییر می‌دهد و SSH هنوز چه چیزی را تعیین می‌کند
تونل دسترس‌پذیری را تغییر می‌دهد: کدام نشانی‌ها قابل دسترسی‌اند و از کجا. این تغییر نمی‌دهد که پس از رسیدن اتصال TCP چه رخ می‌دهد، جایی که سرور کلید میزبان را ارائه می‌دهد و هویت کاربر را می‌پرسد.
دو لایه را در ذهن و در مستندات خود جدا نگه دارید. ورود به VPN ثابت می‌کند چه کسی می‌تواند از شبکه استفاده کند. این چیزی دربارهٔ حساب‌های موجود روی هدف نمی‌گوید و اجازهٔ ورود به هر ماشین قابل دسترس نیست.
حالت‌های خطا هم جدا هستند، و همین جدایی را در هنگام یک حادثه مفید می‌کند.
سه شرطی که مدل دسترسی را تعیین می‌کند
نخست، آیا سرور باید برای افرادی بیرون از شبکهٔ شما قابل دسترس باشد؟ اگر نه، مسیر خصوصی به‌همراه یک استحکام‌بخش یا یک مش طرح کوچک‌تری است. دوم، آیا جمعیت کلاینت‌ها واقعاً می‌توانند کلاینت VPN را اجرا کنند، از جمله کسانی که روی دستگاه‌های مدیریت‌شده با محدودیت هستند؟
سوم، آیا به کنترل به‌ازای هر سرویس نیاز دارید یا کنترل به‌ازای هر کاربر؟ VPN دسترسی شبکه می‌دهد؛ SSH دسترسی حساب می‌دهد. اگر الزام این است که یک پیمانکار به یک میزبان و نه چیز دیگری برسد، این یک الزام مجوز است و تونل به‌تنهایی نمی‌تواند آن را بیان کند.
به آن سه پاسخ دهید و مدل خودش را انتخاب می‌کند. از آن‌ها بگذرید و در نهایت SSH را برای اجتناب از استقرار کلاینت به‌صورت عمومی افشا می‌کنید.
پیش از سرزنش SSH مسیر خصوصی را تأیید کنید
به VPN تأییدشده وصل شوید و از نام یا نشانی خصوصی مستندشدهٔ هدف استفاده کنید. سپس مسیر انتخاب‌شده، مجوز دروازه و مسیر بازگشت به کلاینت را بررسی کنید. نامی که درست حل می‌شود اثبات این نیست که نشانی تونل موردنظر را می‌گیرد، زیرا پیشوندهای محلی و راه‌دور هم‌پوشان می‌توانند درخواست را کاملاً جای دیگری بفرستند. این تفاوت ارزش نوشتن در runbook را دارد.
اگر اتصال هرگز نمی‌رسد، تأیید کنید که سرور روی رابطی که انتظار دارید گوش می‌دهد و اینکه فایروال میزبانش منبعی را که واقعاً می‌بیند مجاز می‌داند. یک NAT دروازه می‌تواند آن منبع را بازنویسی کند، بنابراین فهرست مجازِ نوشته‌شده برای نشانی تونل کلاینت ممکن است هرگز مطابقت نکند.
این ناسازگاری رایج‌ترین خطای SSH خودساخته روی VPN است.
مرحلهٔ خطا را بخوانید، نه خطای ترکیبی
سه مرحله سه پیام متفاوت تولید می‌کنند، و فقط یکی از آن‌ها دربارهٔ اعتبارنامه است.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
از خطای دقیق و گزارش خود سرور استفاده کنید، نه اینکه اعتبارنامه‌های VPN و SSH را با هم بازنشانی کنید. بازنشانی هر دو همان چیزی است که یک تشخیص پنج‌دقیقه‌ای را به حادثهٔ هویتی دوردوزه تبدیل می‌کند.
خروجی مشروح نشان می‌دهد به کدام مرحله رسیدید:
ssh -vv [email protected]کلیدهای میزبان و مجوز را سالم نگه دارید
کلید میزبان را از طریق فرایند مورداعتماد موردنظر اعتبارسنجی کنید، به‌ویژه پس از تعویض سرور. هشدار غیرمنتظرهٔ تغییر کلید تنها پیامی است که نباید فقط به‌خاطر وصل‌شدن VPN نادیده بگیرید، زیرا تونل خصوصی مقصد را همان ماشینی که فکر می‌کنید نمی‌کند. اثر انگشت را با منبعی که مستقل از اتصال به آن اعتماد دارید بررسی کنید.
در سمت سرور تأیید کنید که حساب مجاز است و روش احراز هویتی که پیکربندی کرده‌اید همان روش ارائه‌شده است. کلیدی که وجود دارد اما نادیده گرفته می‌شود معمولاً مشکلی در مجوزها یا پیکربندی است نه شبکه.
دسترسی سرویس را به هویت‌های لازم محدود کنید و مسیر بازیابی مجاز برای تغییرات شبکه نگه دارید.