SSH روی VPN هر دقیقه قطع می‌شود؟ مشکل keepalive نیست

SSH وصل می‌شود، حدود یک دقیقه کار می‌کند و بعد هر بار تقریباً در همان فاصله منجمد می‌شود. توضیح رایج یک تایم‌اوت بیکاری است، پس مردم MTU را کم می‌کنند و keepalive کلاینت را تنظیم می‌کنند. لینک WireGuardی که روی آن کار می‌کردم از قبل همه این‌ها را پشت سر گذاشته بود: MTU تونل کوچک‌تر، تنظیمات client-alive، یک keepalive تونل پیکربندی‌شده. قطع‌ها بدون تغییر ادامه داشتند. علت یک مسیر LAN نامتقارن بود، و این الگو ارزش شناختن دارد چون هر اصلاح مبتنی بر تایمر را شکست می‌دهد.

keepalive ثابت می‌کند که میزبان شما هنوز مایل به فرستادن است. نمی‌تواند کاری کند که دستگاهی با حفظ وضعیت پاسخی را ببیند که هرگز از آن عبور نمی‌کند.

افسانه: keepalive یک قطع خاموش را درست می‌کند

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

تغییر MTU اصلاح محبوب دیگر است و همان حالت شکست را دارد. کاهش MTU به تکه‌تکه‌شدن و مشکلات MTU مسیر کمک می‌کند و برای مسیر کاری نمی‌کند. اگر تایمرها و MTU شما از قبل معقول‌اند و قطع هنوز در فاصله‌ای تکرارشونده است، فاصله دارد از یک تایم‌اوت جایی به شما می‌گوید، نه از اندازه بسته. فاصله را یادداشت کنید و آن را با تایم‌اوت‌های وضعیت روی هر دستگاه در مسیر مقایسه کنید.

نشانه، نظم همراه با نشستی است که درون آن فاصله قابل استفاده می‌ماند. تایم‌اوت‌های بیکاری وقتی هیچ اتفاقی نمی‌افتد ضربه می‌زنند؛ این یکی وقتی تایپ می‌کنید ضربه می‌زند.

دروازه اضافی واقعاً چه می‌کند

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

آدرس‌های زیر آن چیدمان را بازتاب می‌دهند:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

تغییرمسیرها و مدیریت وضعیت سپس یک دست‌دادن کارآمد را به اتصالی تبدیل می‌کنند که دیرتر می‌میرد نه فوراً. تأخیر، کهنه‌شدن ورودی وضعیت یا شکست یک بررسی سخت‌گیرانه‌تر است، و به همین دلیل فاصله اینقدر مکانیکی به نظر می‌رسد.

هیچ‌یک از این‌ها در پیکربندی کلاینت ظاهر نمی‌شود، و به همین دلیل جست‌وجوی آن معمولاً در فایل اشتباه شروع می‌شود.

یک مسیر آگاهانه انتخاب کنید

برای چیدمان بالا، مسیریابی زیرشبکه دور مستقیماً به دروازه VPN نیمی از اتصال را حذف می‌کند:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

از دو سر آزمایش کنید

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

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

کی نامتقارنی اشکالی ندارد

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

پاسخ پایدار دو مسیر را نام می‌برد، دستگاهی که باید هر دو را ببیند، و مسیری که آن را ممکن می‌کند. اگر نمی‌توانید دستگاه را نام ببرید، هنوز علت را پیدا نکرده‌اید.