محتوای آموزشی وبلاگ نت‌آرام
به سرور وصل می‌شوید، چند دقیقه به پنجره دست نمی‌زنید و وقتی دوباره تایپ می‌کنید پیام Broken pipe یا Connection reset می‌بینید. گاهی هم پنجره فقط بی‌پاسخ می‌ماند. ممکن است اتصال بیکار در مسیر شبکه یا خود سرور بسته شده باشد، اما مشکل اینترنت، راه‌اندازی مجدد سرور یا سیاست امنیتی نیز می‌تواند نقش داشته باشد.
در این راهنما ابتدا زمان و شرایط قطع را ثبت می‌کنیم، بعد یک تنظیم کوچک را فقط در سمت رایانه خود آزمایش می‌کنیم. همچنین نشان می‌دهیم چطور کار طولانی را طوری اجرا کنید که قطع پنجره لزوماً به معنی ازبین‌رفتن نشست کاری نباشد.
اول قطع هنگام بیکاری را از خطای ورود جدا کنید
اگر از ابتدا پیام Connection refused یا Connection timed out می‌گیرید، هنوز به مرحله نشست پایدار نرسیده‌اید؛ راهنمای تفاوت خطاهای اولیه SSH مسیر مناسب‌تری دارد. این مقاله درباره اتصالی است که ابتدا برقرار می‌شود و بعد قطع یا بی‌پاسخ می‌شود.
زمان ورود، مدت بیکاری، پیام دقیق و ساعت تقریبی قطع را یادداشت کنید. یک بار هنگام بیکاری و یک بار هنگام کار عادی رفتار را مقایسه کنید. اگر سرور هم‌زمان برای دیگر کاربران و سرویس‌ها قطع می‌شود، احتمالاً بررسی فقط پنجره SSH کافی نیست. اگر فقط یک اینترنت مشکل دارد، مسیر همان شبکه نیز مهم است.
اگر پیام تغییر کلید میزبان می‌بینید، اتصال را بدون تأیید هویت سرور ادامه ندهید. حذف عجولانه هشدار امنیتی راه رفع قطع بیکاری نیست. کلید خصوصی و رمز را هم در تصویر گزارش نفرستید.
قدم اول: یک اتصال تازه با تنظیم آزمایشی برقرار کنید
روی رایانه‌ای که با برنامه OpenSSH به سرور وصل می‌شوید، ترمینال را باز کنید. نام کاربر، نشانی، پورت و در صورت نیاز مسیر کلید را با اطلاعات واقعی خودتان جایگزین کنید:
کد / دستورssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -p 22 user@example.com
گزینه
ServerAliveInterval=60 به کلاینت می‌گوید اگر برای آن مدت داده‌ای از سرور نرسد، پیام بررسی از درون کانال SSH بفرستد. ServerAliveCountMax=3 تعداد پاسخ‌نگرفتن‌های مجاز را تعیین می‌کند؛ اگر سرور پاسخ ندهد، اتصال پس از چند نوبت می‌تواند بسته شود. این دو گزینه رمزگذاری را خاموش نمی‌کنند و بازماندن اتصال را در برابر هر قطعی تضمین نمی‌کنند. پورت ۲۲ و نام دامنه فقط مثال‌اند.بعد از ورود، نشست را در همان شرایطی که قبلاً قطع می‌شد برای مدت مشابه رها کنید و سپس فرمان بی‌خطری مانند
pwd بزنید. اگر مسیر فعلی چاپ شد، اتصال در آن آزمایش زنده مانده است. یک بار موفقیت به معنی حل قطعی در همه شبکه‌ها و ساعت‌ها نیست؛ چند بار در شرایط واقعی مقایسه کنید. اگر پیام قطع باز هم رخ داد، زمان و نوع پیام را ثبت کنید.اگر با PuTTY یا برنامه دیگری متصل می‌شوید، گزینه‌های نام‌گذاری‌شده ممکن است متفاوت باشند. در PuTTY تنظیم keepalive در بخش Connection وجود دارد، اما مقدار و رفتار را با نسخه و سیاست خودتان بخوانید. تغییر برنامه به حالت ناامن یا خاموش‌کردن بررسی هویت سرور ضرورتی ندارد.
قدم دوم: تنظیم را فقط برای همان سرور ذخیره کنید
اگر آزمایش مفید بود و با سیاست شما سازگار است، می‌توانید در فایل پیکربندی OpenSSH روی رایانه خودتان، نه سرور مقصد، برای همان میزبان یک ورودی قرار دهید. فایل معمولاً
کد / دستور~/.ssh/config است. در ویندوز OpenSSH مسیر متناظر زیر پوشه کاربری و .ssh قرار می‌گیرد. قبل از ویرایش از فایل موجود نسخه نگه دارید و ورودی‌های دیگر را حذف نکنید.Host my-server
HostName example.com
User user
Port 22
ServerAliveInterval 60
ServerAliveCountMax 3
در این نمونه،
my-server نام دلخواه اتصال است و سه مقدار نشانی، کاربر و پورت باید متعلق به سرویس شما باشند. پس از ذخیره، با ssh my-server وصل شوید. اگر از کلید استفاده می‌کنید، تنظیم مربوط به کلید همان حساب را مطابق پیکربندی خودتان حفظ کنید. از نوشتن یک قانون عمومی برای همه میزبان‌ها بدون آگاهی از اثر آن خودداری کنید.برای دیدن اینکه OpenSSH چه تنظیمی برای این نام در نظر می‌گیرد، دستور زیر را می‌توانید روی رایانه خود اجرا کنید:
کد / دستورssh -G my-server
در خروجی گزینه‌های
serveraliveinterval و serveralivecountmax را پیدا کنید. خروجی می‌تواند نام کاربر و مسیرهای محلی را نشان دهد؛ پیش از فرستادن تصویر آن را پالایش کنید. مستند رسمی تنظیمات OpenSSH معنای دقیق این گزینه‌ها را توضیح می‌دهد.اگر اتصال با وجود این تنظیم باز هم قطع شد
به ساعت قطعی و اثر آن روی سایر سرویس‌ها نگاه کنید. اگر سرور واقعاً ریستارت شده باشد، پیام‌های نگه‌دارنده نمی‌توانند نشست قبلی را حفظ کنند؛ راهنمای بررسی ریستارت ناگهانی سرور را بخوانید. اگر فقط یک شبکه یا VPN مشکل دارد، همان اتصال را با شبکه مجاز دیگری مقایسه و سیاست قطع نشست بیکار را از مدیر شبکه بپرسید.
مدیر سرور می‌تواند گزارش SSH را در همان زمان بخواند. نام سرویس بسته به توزیع ممکن است
کد / دستورssh یا sshd باشد. برای نمونه در سیستمی که نام واحد ssh است:sudo journalctl -u ssh --since '30 minutes ago' --no-pager
اگر واحد شما
sshd است، نام واقعی را جایگزین کنید. این دستور گزارش نیم ساعت اخیر آن واحد را نشان می‌دهد؛ ممکن است علت قطع در شبکه میانی باشد و در لاگ سرور دیده نشود. پیش از ارسال خروجی، نام حساب و نشانی‌های حساس را حذف کنید. تغییر همه تنظیمات فایروال یا افزایش نامحدود زمان نشست بدون شناخت سیاست سازمان کار مناسبی نیست.برای کار طولانی، نشست کاری جدا بسازید
اگر
کد / دستورtmux از منبع رسمی نصب است و سیاست سرویس اجازه می‌دهد، پس از اتصال به سرور می‌توانید یک نشست کاری بسازید:tmux new -s work
اکنون کار خود را داخل همان نشست اجرا کنید. برای جداشدن دستی، کلید
کد / دستورCtrl+B و سپس D را بزنید؛ برنامه داخل tmux معمولاً در سرور باقی می‌ماند. پس از اتصال مجدد می‌توانید اجرا کنید:tmux attach -t work
اگر نشست همچنان وجود داشته باشد، به آن برمی‌گردید. tmux جای پشتیبان نیست و در ریستارت سرور یا توقف خود فرایند تضمین حفظ کار ندارد. همچنین بعضی برنامه‌ها به اتصال شبکه یا ورودی کاربر وابسته‌اند. برای کار حساس، روش رسمی اجرای پس‌زمینه، ثبت خروجی و کنترل نتیجه همان برنامه را هم در نظر بگیرید.
پس از اصلاح، دست‌کم در چند نوبت و با زمان بیکاری مشابه، اتصال و نتیجه کار واقعی را بررسی کنید. اگر مشکل ادامه دارد، زمان، شبکه مورد استفاده، پیام و نتیجه مقایسه را بدون اطلاعات ورود به پشتیبانی بدهید. برای مشاهده امکانات سرویس، صفحه سرور مجازی ایران نت‌آرام در دسترس است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام