Чого насправді чекає gateway-ping-timeout у NetworkManager

Ви знаходите 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. Якщо вам потрібне виявлення втрат, це належить протоколу або власнику тунелю, а не властивості, яка спрацювала один раз під час активації.

Два об'єкти, одне налаштування

Дротовий базовий профіль і профіль VPN — окремі об'єкти конфігурації, і встановлення властивості на одному не впливає на інший. Профіль VPN, який називає базове з'єднання, не успадковує жодного з його налаштувань активації, тому змінене значення може виглядати так, ніби не впливає на те, за чим ви спостерігали.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

Читайте UUID, а не назви. Назви дублюються після перевстановлення або відновленого профілю, і два з'єднання з однаковою видимою назвою змусять вас редагувати не той файл, поки справжній залишається незмінним.

Встановлений випуск NetworkManager теж важливий. Поведінка плагіна й те, як тип з'єднання відображає цю властивість на власні кроки активації, різняться, тому тестуйте на версії, яку розгортаєте, а не припускайте, що знайдений допис застосовний без змін.

Чого очікування не може засвідчити

Ось частина, яка коштує найбільше часу. Відповідь від локального маршрутизатора доводить, що один хост відповів на один відлуння-запит ICMP під час активації. Вона не доводить, що кінцева точка VPN розв'язується, що особу клієнта прийнято, що встановлено приватні маршрути, що офісний резолвер відповідає або що потрібний вам застосунок працюватиме.

Це окремі залежності з окремими доказами. Шлюз може відповідати, поки DNS зазнає невдачі, і шлюз може тихо відкидати ICMP за політикою, поки всі шляхи застосунку працюють. Тому умова на цій властивості — це здогад про те, який рівень спізнюється, а не його вимірювання.

Якщо ви чекаєте на залежну службу, назвіть, що їй потрібно. Призначеній адресі відповідає адресація. Тунелю відповідає стан самого тунелю. Приватному імені відповідає запит. Застосунку відповідає застосунок, і жодна з цих відповідей не надходить від таймера, названого на честь шлюзу.

Якщо змінюєте, запишіть чому

Запишіть попереднє значення й причину до схваленої зміни, а потім задайте його на конкретному з'єднанні, а не всюди. Довше очікування зсуває час активації для всього, що впорядковане після цього з'єднання, через що повільна система може виглядати справною, а швидка — зламаною.

Варто назвати одну історичну пастку: таке значення іноді змінюють, щоб старіший редактор прийняв профіль. Якщо це справжня історія, у вас дві події, а не одна. Редактор зберіг, а жива мережева політика змінилася. Виправте редактор або плагін і поверніть таймер на місце.

Вихідний код NetworkManager визначає цю властивість як затримку успішної IP-адресації до відповіді шлюзу або тайм-ауту, з типовим значенням нуль, а визначення налаштування з'єднання — це джерело, яке варто прочитати, перш ніж покладатися на поведінку, описану з чужих слів.