gateway-ping-timeout در NetworkManager واقعاً منتظر چیست
یک فعال‌سازی را از nmcli در طول انتظار دنبال کنید: پاسخ یا پایان مهلت آن را تمام می‌کند و هیچ‌کدام ثابت نمی‌کند که تونل یا برنامه آماده است.
شما connection.gateway-ping-timeout را در گفت‌وگویی دربارهٔ لپ‌تاپی می‌یابید که پیش از آماده شدن شبکه بالا می‌آید، آن را افزایش می‌دهید و چیزی تغییر می‌کند. اینکه تغییر به دلیلی که فکر می‌کنید کمک کرده باشد، پرسشی جداست. پاسخ با این شروع می‌شود که فعال‌سازی در زمانی که آن زمان‌سنج در حال اجراست واقعاً چه می‌کند، و با این واقعیت که انتظار دو پایان ممکن دارد.
یک اتصال را از خط فرمان دنبال کنید و معناشناسی عینی می‌شود.
یک فعال‌سازی را دنبال کنید
با نگاه به اتصال ذخیره‌شده آغاز کنید نه یک مقدار پیش‌فرض سراسری، زیرا این ویژگی مخصوص هر اتصال است. --show-secrets را فقط اگر واقعاً به آن نیاز دارید اضافه کنید؛ خود تنظیم راز نیست.
nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-pingوقتی این ویژگی صفر است، که پیش‌فرض مستندشده است، فعال‌سازی به‌محض کامل شدن نشانی‌دهی ادامه می‌یابد. آن را روی مقدار مثبتی بگذارید و فعال‌سازی پیکربندی IP تا رسیدن پاسخی از دروازه یا پایان مهلت صبر می‌کند.
سپس اتصال را پایین و دوباره بالا بیاورید و جریان رویدادها را تماشا کنید. ترتیبی که می‌بینید همان تنظیم است که کارش را می‌کند: وضعیت دستگاه، نشانی‌دهی، انتظار، و در پایان وضعیت فعال‌شده‌ای که سرویس‌های وابسته معمولاً بر اساس آن مرتب می‌شوند.
انتظار دو پایان دارد
هر دو پایان اهمیت دارند و بیشتر مردم فقط یکی را به یاد می‌آورند. پاسخ دروازه انتظار را زودتر تمام می‌کند و پایان مهلت هم آن را تمام می‌کند، بی‌آنکه مهم باشد چیزی پاسخ داده یا نه. این ویژگی برای کامل شدن فعال‌سازی به ping موفق نیاز ندارد.
همین یک جمله بخش زیادی از سردرگمی دربارهٔ لپ‌تاپ‌ها در هتل‌ها و مراکز همایش را روشن می‌کند، جایی که دروازهٔ ورود اجباری اغلب تا ورود شما ICMP را رد می‌کند. اتصال پس از پایان مهلت هم فعال می‌شود؛ فقط دیرتر از آنچه لازم بود این کار را می‌کند و هر سرویسی که پس از اتصال مرتب شده باشد همراه آن صبر می‌کند.
این یک بررسی زنده‌بودن هم نیست. هیچ‌چیز در توصیف پس از بالا آمدن اتصال شروع به ping زدن به دروازه نمی‌کند و هیچ‌چیز یک نمایهٔ فعال را به‌خاطر شکست یک ping بعدی قطع نمی‌کند. اگر به تشخیص افت نیاز دارید، آن به پروتکل یا صاحب تونل تعلق دارد، نه به ویژگی‌ای که یک بار در طول فعال‌سازی اجرا شده است.
دو شیء، یک تنظیم
نمایهٔ پایهٔ سیمی و نمایهٔ VPN دو شیء پیکربندی جداگانه‌اند و گذاشتن این ویژگی روی یکی به دیگری اثری ندارد. نمایهٔ VPN که یک اتصال پایه را نام می‌برد هیچ‌یک از تنظیمات فعال‌سازی آن را به ارث نمی‌برد، و به همین دلیل ممکن است مقدار تغییرداده‌شده بی‌اثر بر چیزی که تماشا می‌کردید به نظر برسد.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-pingUUIDها را بخوانید نه نام‌ها را. نام‌ها پس از نصب دوباره یا بازیابی یک نمایه تکراری می‌شوند، و دو اتصال با نام ظاهری یکسان شما را به ویرایش فایل اشتباه می‌فرستند در حالی که فایل واقعی بی‌تغییر می‌ماند.
نسخهٔ نصب‌شدهٔ NetworkManager هم مهم است. رفتار افزونه و اینکه یک نوع اتصال این ویژگی را چگونه به گام‌های فعال‌سازی خودش نگاشت می‌کند متفاوت است، پس روی نسخه‌ای که مستقر می‌کنید آزمایش کنید نه اینکه فرض کنید نوشته‌ای که یافته‌اید بی‌تغییر معتبر است.
آنچه انتظار نمی‌تواند تأیید کند
این همان بخشی است که بیشترین زمان را می‌گیرد. پاسخ از روتر محلی ثابت می‌کند که یک میزبان در طول فعال‌سازی به یک بازتاب ICMP پاسخ داده است. ثابت نمی‌کند که نقطهٔ پایانی VPN حل می‌شود، هویت مشتری پذیرفته می‌شود، مسیرهای خصوصی نصب شده‌اند، resolver دفتر پاسخ می‌دهد یا برنامه‌ای که برایتان مهم است کار خواهد کرد.
این‌ها وابستگی‌های جدا با شواهد جدا هستند. دروازه می‌تواند پاسخ بدهد در حالی که DNS شکست می‌خورد، و دروازه می‌تواند بر اساس سیاست ICMP را بی‌صدا بیندازد در حالی که هر مسیر برنامه کار می‌کند. پس مشروط کردن به این ویژگی حدسی دربارهٔ این است که کدام لایه دیر است، نه اندازه‌گیری آن.
اگر منتظر یک سرویس وابسته هستید، نام ببرید که آن چه می‌خواهد. به نشانی تخصیص‌یافته نشانی‌دهی پاسخ می‌دهد. به تونل، وضعیت خود تونل پاسخ می‌دهد. به نام خصوصی، یک پرس‌وجو پاسخ می‌دهد. به برنامه، خود برنامه پاسخ می‌دهد، و هیچ‌یک از این پاسخ‌ها از زمان‌سنجی که به نام دروازه نام‌گذاری شده نیامده است.
اگر تغییرش می‌دهید، دلیلش را بنویسید
مقدار پیشین و دلیل را پیش از یک تغییر تأییدشده ثبت کنید، سپس آن را روی همان اتصال مشخص بگذارید نه همه‌جا. انتظار طولانی‌تر زمان فعال‌سازی همهٔ چیزهایی را که پس از آن اتصال مرتب شده‌اند جابه‌جا می‌کند، که می‌تواند سیستم کند را خوب و سیستم سریع را خراب نشان دهد.
یک تلهٔ تاریخی ارزش نام بردن دارد: مقداری مانند این گاهی تغییر می‌کند تا ویرایشگر قدیمی‌تری یک نمایه را بپذیرد. اگر داستان واقعی همین باشد، شما دو رویداد دارید نه یکی. ویرایشگر ذخیره کرد و یک سیاست شبکهٔ زنده تغییر کرد. ویرایشگر یا افزونه را درست کنید و زمان‌سنج را برگردانید.
کد منبع NetworkManager این ویژگی را به‌عنوان تأخیر موفقیت نشانی‌دهی IP تا پاسخ دروازه یا پایان مهلت تعریف می‌کند، با پیش‌فرض صفر، و تعریف تنظیم اتصال همان مرجعی است که باید پیش از تکیه بر هر رفتاری که دست‌دوم توصیف شده بخوانید.