Hvad gateway-ping-timeout egentlig venter på i NetworkManager

Du finder connection.gateway-ping-timeout i en tråd om en bærbar computer, der starter, før netværket er brugbart, du hæver den, og noget ændrer sig. Om ændringen hjalp af den grund, du tror, er et separat spørgsmål. Svaret begynder med, hvad aktiveringen faktisk gør, mens den timer kører, og med at ventetiden har to mulige afslutninger.

Følg én forbindelse fra kommandolinjen, og semantikken bliver konkret.

Følg én aktivering

Begynd med at se på den gemte forbindelse i stedet for en global standardværdi, fordi dette er en egenskab for hver forbindelse. Tilføj --show-secrets kun, hvis du faktisk har brug for det; selve indstillingen er ikke en hemmelighed.

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

Med egenskaben på nul, som er den dokumenterede standard, fortsætter aktiveringen, så snart adresseringen er færdig. Sæt den til en positiv værdi, og aktiveringen af IP-konfigurationen venter, til der kommer et svar fra gatewayen, eller timeouten udløber.

Tag derefter forbindelsen ned og op igen, mens du følger hændelsesstrømmen. Den rækkefølge, du ser, er indstillingen, der gør sit arbejde: enhedstilstand, adressering, ventetiden og til sidst den aktiverede tilstand, som afhængige tjenester normalt ordnes efter.

Ventetiden har to afslutninger

Begge afslutninger betyder noget, og de fleste husker kun én. Et svar fra gatewayen afslutter ventetiden tidligt, og timeouten afslutter den også, uanset om noget svarede. Egenskaben kræver ikke et vellykket ping, før aktiveringen kan fuldføres.

Den ene sætning fjerner en del forvirring om bærbare computere på hoteller og konferencecentre, hvor en captive portal ofte afviser ICMP, indtil du logger ind. Forbindelsen aktiveres stadig, efter at timeouten er udløbet; den gør det bare senere, end det var nødvendigt, og hver tjeneste, der er ordnet efter forbindelsen, venter med den.

Det er heller ikke et livstegnstjek. Intet i beskrivelsen begynder at pinge en gateway, efter at forbindelsen er oppe, og intet afbryder en aktiv profil, fordi et senere ping mislykkes. Hvis du har brug for tabserkendelse, hører det til protokollen eller tunelejeren, ikke til en egenskab, der kørte én gang under aktiveringen.

To objekter, én indstilling

Den kablede basisprofil og en VPN-profil er separate konfigurationsobjekter, og at sætte egenskaben på den ene påvirker ikke den anden. En VPN-profil, der navngiver en basisforbindelse, arver ingen af dens aktiveringsindstillinger, og derfor kan den værdi, du ændrede, se ud til ikke at have nogen effekt på det, du fulgte.

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

Læs UUID'erne i stedet for navnene. Navne bliver duplikeret efter en geninstallation eller en gendannet profil, og to forbindelser med samme synlige navn får dig til at redigere den forkerte fil, mens den rigtige forbliver uændret.

Den installerede NetworkManager-version betyder også noget. Plugin-adfærd og måden, en forbindelsestype mapper denne egenskab til sine egne aktiveringstrin, varierer, så test på den version, du udruller, i stedet for at antage, at et indlæg, du fandt, gælder uændret.

Hvad ventetiden ikke kan attestere

Her er den del, der koster mest tid. Et svar fra den lokale router beviser, at én vært besvarede ét ICMP-ekko under aktiveringen. Det beviser ikke, at et VPN-endepunkt opløses, at klientens identitet accepteres, at private ruter blev installeret, at kontorets resolver svarer, eller at det program, du bekymrer dig om, vil virke.

Det er separate afhængigheder med separate beviser. En gateway kan svare, mens DNS fejler, og en gateway kan lydløst droppe ICMP efter politik, mens enhver programsvej virker. At gøre denne egenskab til en betingelse er derfor et gæt på, hvilket lag der er sent, ikke en måling af det.

Hvis du venter på en afhængig tjeneste, så navngiv, hvad den har brug for. En tildelt adresse besvares af adressering. En tunnel besvares af tunnelens egen tilstand. Et privat navn besvares af en forespørgsel. Et program besvares af programmet, og ingen af de svar kommer fra en timer, der er opkaldt efter gatewayen.

Hvis du ændrer den, så skriv hvorfor

Notér den tidligere værdi og årsagen før en godkendt ændring, og sæt den derefter på den specifikke forbindelse i stedet for overalt. En længere ventetid flytter aktiveringstidspunktet for alt, der er ordnet efter den forbindelse, hvilket kan få et langsomt system til at se fint ud og et hurtigt til at se i stykker.

En historisk fælde er værd at nævne: en værdi som denne bliver nogle gange ændret for at få en ældre editor til at acceptere en profil. Hvis det er den rigtige historie, har du to hændelser, ikke én. Editoren gemte, og en levende netværkspolitik ændrede sig. Ret editoren eller plugin'et, og sæt timeren tilbage.

NetworkManager-kilden definerer egenskaben som en forsinkelse af IP-adresseringens succes indtil et gatewaysvar eller timeouten, med en standard på nul, og definitionen af forbindelsesindstillingen er den reference, du skal læse, før du stoler på nogen adfærd, der er beskrevet på anden hånd.