Чего на самом деле ждёт 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-адресации до ответа шлюза или истечения тайм-аута, со значением по умолчанию ноль, а определение настройки подключения — это источник, который стоит прочитать, прежде чем полагаться на поведение, описанное с чужих слов.