SSH پس از راه‌اندازی مجدد گوش نمی‌دهد: نشانی VPN دیر می‌رسد
سرویسی که به نشانی تونل مقید می‌شود، در لحظهٔ اتصال به آن نشانی نیاز دارد. پیش از ویرایش کلیدها، مالک شنونده، ترتیب بوت و خطای اتصال را بررسی کنید.
در هنگام راه‌اندازی، SSH را به نشانی تونل مقید می‌کنید، کار می‌کند، و پس از راه‌اندازی مجدد بعدی هیچ‌کس نمی‌تواند وارد شود تا زمانی که کسی سرویس را دستی دوباره راه‌اندازی کند. اعتبارنامه‌ها مشکل نیستند. دیمن از هسته نشانی‌ای خواست که هنوز وجود نداشت، اتصال شکست خورد، و پیام در گزارش بوت از کنار گذشت. آنچه مشکل احراز هویت به نظر می‌رسد، مشکلی در ترتیب شروع است.
خطای اتصال در واقع چه می‌گوید
سوکت شنونده باید روی نشانی‌ای ایجاد شود که در آن لحظه وجود دارد. وقتی رابط VPN بعداً بالا می‌آید، دیمنی که فقط برای اتصال به نشانی تونل پیکربندی شده چیزی ندارد که به آن بچسبد. پیکربندی از نظر نحوی معتبر می‌ماند؛ محیط به‌سادگی آماده نبود. سرویسی که از یک شروع دستی در حال اجرا بوده هرگز مسیر بوت را طی نمی‌کند، به همین دلیل این نقص فقط در راه‌اندازی مجدد بعدی ظاهر می‌شود. زمان شکست اتصال را با زمان تخصیص نشانی مقایسه کنید و ترتیب آشکار می‌شود.
اعتبار پیکربندی و آمادگی زمان اجرا دو ویژگی جداگانه‌اند. هر دو را آزمایش کنید، زیرا یکی از آن‌ها بدون گفتن چیزی شکست می‌خورد.
کدام فرایند مالک پورت است
دیمن همیشه مؤلفه‌ای نیست که شنونده را می‌سازد. فعال‌سازی سوکت آن مسئولیت را به یک واحد منتقل می‌کند، و آن‌گاه راه‌اندازی مجدد دیمن چیزی را تغییر نمی‌دهد.
ss -ltnp 'sport = :22'
systemctl cat ssh.socketفهرست سوکت نشان می‌دهد کدام فرایند پورت را و روی کدام نشانی نگه داشته است، در حالی که خروجی واحد نشان می‌دهد آیا واحد سوکتی اصلاً وجود دارد. وقتی فعال‌سازی در جریان است، نشانی به واحد سوکت تعلق دارد و فایل دیمن مرجع نیست. برای خطای اتصال واقعی گزارش بوت را بخوانید، نه اینکه آن را از نشانه استنتاج کنید. نبودن واحد سوکت به‌سادگی یعنی چیدمان کلاسیک، که در آن دیمن مستقیماً متصل می‌شود.
آمادگی را صریح کنید، نه خواب
تأخیر ثابت حدسی است که سخت‌افزار سریع و شبکه‌های کند را یکسان می‌بیند. در عوض وابستگی را بیان کنید: منتظر نشانی بمانید، سپس شروع کنید.
ip -4 addr show dev tun0
systemctl edit ssh.serviceدستور ExecStartPre اضافه کنید که تا ظاهر شدن نشانی تکرار شود، یا واحد را پس از هدف شبکهٔ مشخصی که مالک رابط است مرتب کنید. هر دو رویکرد وابستگی را جایی ثبت می‌کنند که مدیر بعدی بتواند بخواند. حلقه به یک مهلت نیاز دارد، وگرنه VPN ناموفق واحدی باقی می‌گذارد که به‌جای گزارش خطا معلق می‌ماند. سپس تأیید کنید که دیمن نشانی تونل را متصل می‌کند در حالی که رابط معمولی تحت قواعد فیلتر شما باقی می‌ماند.
یک بوت پاک و یک اتصال مجدد را آزمایش کنید
راه‌اندازی مجدد دستی پس از آنکه همه‌چیز آنلاین است چیزی دربارهٔ ترتیب بوت اثبات نمی‌کند. ماشین را با تونل پیکربندی‌شده برای بالا آمدن خودکار دوباره راه‌اندازی کنید و ببینید آیا شنونده بدون دخالت ظاهر می‌شود.
systemctl status ssh.service
ss -ltnp 'sport = :22'سپس تونل را قطع و دوباره برقرار کنید، زیرا اتصال مجدد می‌تواند نشانی را تغییر دهد و اتصال سخت‌کدشده از آن پیروی نمی‌کند. هنگام آزمایش یک مسیر بازیابی خارج از باند نگه دارید تا یک تغییر ترتیب بد نتواند شما را از میزبان قفل بیرون کند.
معیار موفقیت شنونده‌ای است که زیر وابستگی مستندش ظاهر می‌شود، نه شنونده‌ای که کسی یادش افتاد دوباره راه‌اندازی کند.