Què espera realment gateway-ping-timeout a NetworkManager

Trobeu connection.gateway-ping-timeout en un fil sobre un portàtil que arrenca abans que la xarxa sigui utilitzable, l’apugeu i alguna cosa canvia. Si el canvi ha ajudat pel motiu que penseu és una qüestió separada. La resposta comença per què fa realment l’activació mentre aquell temporitzador funciona, i pel fet que l’espera té dos finals possibles.

Seguiu una connexió des de la línia d’ordres i la semàntica es fa concreta.

Seguiu una activació

Comenceu mirant la connexió desada en lloc d’un valor predeterminat global, perquè això és una propietat per connexió. Afegiu --show-secrets només si realment el necessiteu; el paràmetre en si no és cap secret.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

Amb la propietat a zero, que és el valor predeterminat documentat, l’activació continua tan bon punt l’adreçament s’ha completat. Poseu-la a un valor positiu i l’activació de la configuració IP espera fins que arribi una resposta de la passarel·la o caduqui el temps d’espera.

Després baixeu i pugeu la connexió mentre observeu el flux d’esdeveniments. L’ordre que veieu és el paràmetre fent la seva feina: estat del dispositiu, adreçament, l’espera i finalment l’estat activat segons el qual se solen ordenar els serveis dependents.

L’espera té dos finals

Els dos finals importen, i la majoria de la gent només en recorda un. Una resposta de la passarel·la acaba l’espera abans d’hora, i el temps d’espera també l’acaba, tant si algú ha respost com si no. La propietat no exigeix un ping correcte abans que l’activació es pugui completar.

Aquesta única frase aclareix molta confusió sobre portàtils en hotels i centres de congressos, on un portal captiu sovint refusa ICMP fins que inicieu sessió. La connexió s’activa igualment després que caduqui el temps d’espera; simplement ho fa més tard del que calia, i cada servei ordenat després de la connexió espera amb ella.

Tampoc no és una comprovació de vitalitat. Res de la descripció no comença a fer ping a una passarel·la després que la connexió estigui engegada, i res no desconnecta un perfil actiu perquè un ping posterior falli. Si necessiteu detecció de pèrdues, això correspon al protocol o a l’amo del túnel, no a una propietat que va córrer una vegada durant l’activació.

Dos objectes, un paràmetre

El perfil base per cable i un perfil VPN són objectes de configuració separats, i posar la propietat en un no afecta l’altre. Un perfil VPN que nomena una connexió base no n’hereta cap paràmetre d’activació, i per això el valor que heu canviat pot semblar que no té cap efecte sobre allò que observàveu.

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

Llegiu els UUID en lloc dels noms. Els noms es dupliquen després d’una reinstal·lació o d’un perfil restaurat, i dues connexions amb el mateix nom visible us faran editar el fitxer equivocat mentre la real queda sense canvis.

La versió instal·lada de NetworkManager també importa. El comportament del connector i com un tipus de connexió mapeja aquesta propietat als seus propis passos d’activació varien, així que proveu amb la versió que desplegueu en lloc de suposar que un article que heu trobat s’aplica sense canvis.

Què no pot certificar l’espera

Aquí hi ha la part que costa més temps. Una resposta de l’encaminador local demostra que un host va respondre un eco ICMP durant l’activació. No demostra que es resolgui un extrem de VPN, que s’accepti la identitat del client, que s’hagin instal·lat rutes privades, que el resolutor de l’oficina respongui o que l’aplicació que us importa funcioni.

Aquestes són dependències separades amb proves separades. Una passarel·la pot respondre mentre el DNS falla, i una passarel·la pot descartar ICMP silenciosament per política mentre tots els camins d’aplicació funcionen. Per tant, condicionar-ho a aquesta propietat és una conjectura sobre quina capa arriba tard, no una mesura.

Si espereu un servei dependent, anomeneu què necessita. Una adreça assignada la respon l’adreçament. Un túnel el respon l’estat propi del túnel. Un nom privat el respon una consulta. Una aplicació la respon l’aplicació, i cap d’aquestes respostes no ve d’un temporitzador que duu el nom de la passarel·la.

Si el canvieu, escriviu per què

Registreu el valor anterior i el motiu abans d’un canvi aprovat, i després poseu-lo a la connexió concreta en lloc d’arreu. Una espera més llarga desplaça el moment d’activació de tot el que s’ordena després d’aquella connexió, cosa que pot fer que un sistema lent sembli bé i un de ràpid sembli trencat.

Una trampa històrica val la pena esmentar-la: un valor com aquest de vegades es canvia perquè un editor més antic accepti un perfil. Si aquesta és la història real, teniu dos esdeveniments, no un. L’editor va desar i una política de xarxa viva va canviar. Arregleu l’editor o el connector i torneu el temporitzador.

El codi font de NetworkManager defineix la propietat com un retard de l’èxit d’adreçament IP fins a una resposta de la passarel·la o el temps d’espera, amb un valor predeterminat de zero, i la definició del paràmetre de connexió és la referència que cal llegir abans de confiar en qualsevol comportament descrit de segona mà.