VPN روی UDP در حالت بی‌کار می‌ایستد: فایروال جریان شما را فراموش کرده

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

نشانه به‌اندازه کافی یکدست است تا تشخیص داده شود: بعد از بی‌کاری ظاهر می‌شود، نه زیر بار.

توقف بی‌کاری چه شکلی است

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

هر دو به بی‌کاری مربوط‌اند و به اصلاح‌های متفاوتی نیاز دارند.

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

دستگاهی را که فراموش کرده پیدا کنید

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

فرض نکنید که مقدار پیش‌فرض مستند، مهلت زمانی مسیر شماست. این پیش‌فرض یک دستگاه است.

• روتر خانگی: اغلب دقیقه‌ها، گاهی خیلی کمتر.
• NAT ابری یا توزیع‌کننده بار: مهلت بی‌کاری مستند را به‌طور خاص برای UDP جست‌وجو کنید.
• فایروال میزبان: تایمرهای ردیابی netfilter برای هر جریان اعمال می‌شوند.

تایمرها را روی مسیر واقعی بررسی کنید

در Linux، تایمرهای ردیابی netfilter قابل مشاهده و قابل تنظیم هستند: sysctl net.netfilter.nf_conntrack_udp_timeout و net.netfilter.nf_conntrack_udp_timeout_stream. دومی وقتی اعمال می‌شود که ترافیک در هر دو جهت دیده شده باشد، و به همین دلیل یک تونل برقرار می‌تواند از یک کاوش ساده بیشتر عمر کند.

RFC 4787 رفتار NAT برای UDP و حداقل‌های توصیه‌شده را تعیین می‌کند. این همان مرجعی است که وقتی پیش‌فرض یک فروشنده به‌طور غیرعادی کوتاه به نظر می‌رسد باید به آن استناد کنید.

Keepalive و اتصال دوباره دو ابزار متفاوت‌اند

Keepalive یک نگاشت را زنده نگه می‌دارد؛ اتصال دوباره یک نشست مرده را از نو می‌سازد. این دو خرابی‌های متفاوتی را حل می‌کنند و تنظیمات سرعت قابل‌تعویض نیستند. گزینه PersistentKeepalive در WireGuard هر بازه ثابتی یک بسته می‌فرستد تا پیوند NAT باز بماند. گزینه keepalive در OpenVPN همین کار را به روش خودش انجام می‌دهد. هیچ‌کدام کمک نمی‌کند اگر دستگاه میانی جریان را فراموش کرده و هر دو جهت را دور می‌ریزد.

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

با درخواست تازه بررسی کنید، نه با بارگذاری دوباره صفحه

بعد از تغییر یک تایمر یا افزودن keepalive، سناریوی بی‌کاری را دقیقاً مثل قبل تکرار کنید. سپس یک درخواست واقعاً تازه از برنامه پوشش‌داده‌شده بفرستید. زبانه مرورگری که از قبل بارگذاری شده می‌تواند از حافظه نهان نمایش داده شود و چیزی به شما نمی‌گوید.

اگر توقف ادامه داشت، یک گام به بیرون بروید و جدول وضعیت آن دستگاه را بررسی کنید.