VPN مدام قطع می‌شود؟ به همین ترتیب پیش بروید

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

گام یک: فاصله و متن خطا را ثبت کنید

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

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

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

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

گام دو: یک متغیر را عوض کنید، نه پروفایل را

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

لپ‌تاپی با پورت Ethernet مقایسه دومی به شما می‌دهد که Wi-Fi را کاملاً از تصویر بیرون می‌برد. اگر تونل روی هر دو گزینه برقرار بماند، شبکه دسترسی اصلی شایسته توجه است: رومینگ بین نقاط دسترسی، روتر خانگی‌ای که جدول ترجمه‌اش منقضی می‌شود، یا لینک بالادستی که جریان‌های طولانی را بازنشانی می‌کند.

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

گام سه: فاصله را به یک لایه نسبت دهید

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

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

برای حالت بی‌کاری، تنظیمات وابسته به پروتکل است و هر دو سر مهم‌اند. keepalive 10 60 مربوط به OpenVPN روی سرور هر 10 ثانیه پینگ می‌فرستد و بدون آن پس از 60 ثانیه پیوند را دوباره راه می‌اندازد؛ کلاینت‌های WireGuard پشت NAT از PersistentKeepalive = 25 در بلوک همتا استفاده می‌کنند. OpenVPN همچنین کانال داده را با یک تایمر دوباره مذاکره می‌کند، reneg-sec، که در 2.x به‌طور پیش‌فرض 3600 ثانیه است.

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

گام چهار: یک جایگزین پشتیبانی‌شده را مقایسه کنید

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

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

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

اصلاح را تأیید کنید و امکان بازگشت را نگه دارید

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

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

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

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