SSH روی مسیر خصوصی دوم در حالی که VPN برقرار می‌ماند

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

چرا یک مسیر تازه شنوندهٔ تازه نمی‌سازد

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

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

نشانی‌ها و شنونده‌ها را فهرست کنید

پیش از هر تغییری، نشانی‌های میزبان و سوکت‌هایی را که اکنون وجود دارند ثبت کنید.

ip -br addr
ss -ltnp | grep ':22'

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

اتصال را اضافه کنید و قدیمی را نگه دارید

OpenSSH چندین ورودی ListenAddress را می‌پذیرد، پس مسیر VPN می‌تواند بماند در حالی که مسیر خصوصی افزوده می‌شود. فایل را پیش از بارگذاری دوباره آزمایش کنید.

sshd -t
systemctl reload sshd

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

نشست تازه را پیش از بستن نشست قدیمی بررسی کنید

در حالی که نشست اصلی هنوز باز است به نشانی تازه متصل شوید و از خروجی مشروح استفاده کنید تا ببینید کدام نشانی و کدام کلید به کار رفته است. نشست اصلی را باز نگه دارید تا آزمایش دو بار موفق شود.

ssh -v [email protected]

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

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