Какво всъщност чака 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 адресирането до отговор от шлюза или до изтичане на времето, със стойност по подразбиране нула, и дефиницията на настройката за връзка е референцията, която да прочетете, преди да разчитате на каквото и да е поведение, описано от втора ръка.