چرا یک تونل Azure OpenVPN تقریباً هر شصت ثانیه قطع میشود
تونلی که هر شصت ثانیه قطع میشود، دستدادنش را کامل کرده است، پس چیزی جلوی آن را نمیگیرد. ابتدا دلیل قطع اتصال را بخوانید، سپس هر دو تایمر keepalive را مقایسه کنید.
تونل دستدادن را کامل میکند، حدود یک دقیقه ترافیک را حمل میکند و سپس دوباره متصل میشود. این توالی مظنون معمول را رد میکند، زیرا فایروالی که پورت را مسدود کند، دستدادن را متوقف میکرد نه نشست را. آنچه دارید اختلاف نظر درباره زندهبودن است: یک طرف تصمیم گرفت طرف دیگر ساکت شده و تونلی را که کار میکرد پایین کشید. خط گزارش میگوید کدام طرف، و همان خط تعمیر را انتخاب میکند.
آن خط را پیش از دست زدن به هر تایمری بخوانید.
افسانه: چیزی در مسیر تونل را مسدود میکند
اگر پورتی مسدود بود، اتصال همان ابتدا شکست میخورد و شکستخورده میماند. چرخه تکرارشونده یعنی پیامهای کنترل در جریاناند، نشستها برقرار میشوند، و چیزی در ادامه گفتگو مدام منقضی میشود. مسدودسازی سکوت تولید میکند، و این یکی ریتم تولید میکند.
ریتم سرنخ مفید است. تایمرها آن را تولید میکنند؛ از دست رفتن بسته بهندرت.
پیش از تایمر، دلیل قطع اتصال را بخوانید
OpenVPN دلیل خود را نام میگذارد و هر نام به زیرسیستم متفاوتی اشاره دارد. Session invalidated: KEEPALIVE_TIMEOUT یک تایمر در حال انقضاست، پس مقادیر ping و ping-restart را در هر دو سر مقایسه کنید. AUTH_FAILED اعتبارنامه یا وضعیت گواهی است و هیچ تغییر تایمری کمکی نمیکند. خطای TLS یعنی همتایان هرگز به مرحله keepalive نرسیدند.
زمان اتصال، زمان قطع و اینکه فاصله تا ثانیه پایدار است یا نه را ثبت کنید. همین یک اندازهگیری یک برنامه زمانبندیشده را از یک تصادف جدا میکند.
فاصله پایدار یعنی تایمر. فاصله متغیر به احتمال بیشتر مشکل مسیر یا نشست جابهجاشده است.
دو تایمر keepalive که هرگز توافق نکردند
پروفایلهای صادرشده از درگاه گاهی هنوز خطوط keepalive یا ping-restart کپیشده از الگوی سرور جامعه را دارند. درگاه تشخیص همتای مرده خودش را اجرا میکند و انتظارات خودش را تحمیل میکند، و دو برنامه لازم نیست یکسان باشند. وقتی اختلاف دارند، کلاینت طبق برنامهای که درگاه هرگز نپذیرفته دوباره راهاندازی میشود.
این دو مقدار یک کنترل نیستند. ping این است که کلاینت هر چند وقت یک بار پژواک میفرستد، و ping-restart این است که پیش از پایین کشیدن تونل چه مدت بدون شنیدن چیزی صبر میکند. پروفایلی با ping-restart کوتاه و درگاهی که کند پاسخ میدهد در هر دوره سکوت دوباره راهاندازی میشوند، که دقیقاً شکل یک چرخه یکدقیقهای است.
کوچکترین تغییر سمت کلاینت خنثی کردن تایمرها در سطح بالای پروفایل است، بیرون از هر بلوک درونخطی:
keepalive 0 0ذخیره کنید، پروفایل را دوباره بارگذاری کنید، دوباره متصل شوید. نشستی که از قبل در حافظه است مقادیر قدیمی را نگه میدارد، و به همین دلیل ویرایش گاهی طوری به نظر میرسد که انگار هیچ کاری نکرده است.
نام گواهی میتواند زیر پای شما جابهجا شود
احراز هویت گواهی Azure به این بستگی دارد که کلاینت به نامی که درگاه امروز ارائه میدهد اعتماد کند. یک خط verify-x509-name در دانلود قدیمیتر میتواند نامی را سنجاق کند که بازسازی درگاه یا تمدید گواهی از آن زمان تغییرش داده، و ناسازگاری بهصورت حلقه اتصال مجدد ظاهر میشود نه خطای روشن. حذف آن خط اتصال را برمیگرداند، که آن را به تشخیصی خوب و اصلاحی دائمی بد تبدیل میکند، چون تأیید را هم حذف میکند. وقتی تونل پایدار شد، خط را با نامی که درگاه واقعاً ارائه میدهد برگردانید.
پیش از ویرایش درگاه، نسل دوم کلاینت را روی همان ماشین آزمایش کنید. اگر یک کلاینت حلقه بزند و دیگری پایدار بماند، مشکل پروفایل نیست.
چه چیزی را تغییر دهید، و به چه ترتیبی
سپس نشست جابهجاشده را بررسی کنید. دو دستگاهی که یک گواهی را شریکاند میتوانند یکدیگر را بیرون بیندازند، و نتیجه دورهای به نظر میرسد چون هر دو طرف مدام دوباره متصل میشوند. سوابق نشست نقطهبهسایت را برای همان هویتی که بارها و بارها ظاهر میشود مقایسه کنید.
سپس مسیر بیکار را با اجرای ترافیک پیوسته برای چند دقیقه آزمایش کنید. اگر قطعها هنگام جریان ترافیک متوقف شوند، تایمر مهم به یک دستگاه NAT یا متعادلکننده بار در مسیر تعلق دارد، نه به OpenVPN.
تنظیمات درگاه فقط پس از آن چهار آزمون باید تغییر کنند.