Ce așteaptă de fapt gateway-ping-timeout în NetworkManager

Găsești connection.gateway-ping-timeout într-o discuție despre un laptop care pornește înainte ca rețeaua să fie utilizabilă, îl mărești și ceva se schimbă. Dacă schimbarea a ajutat din motivul la care te gândești este o întrebare separată. Răspunsul începe cu ce face de fapt activarea cât timp rulează acel temporizator și cu faptul că așteptarea are două finaluri posibile.

Urmărește o conexiune din linia de comandă și semantica devine concretă.

Urmărirea unei activări

Începe cu conexiunea salvată, nu cu o valoare implicită globală, pentru că aceasta este o proprietate per conexiune. Adaugă --show-secrets doar dacă ai într-adevăr nevoie; setarea în sine nu este un secret.

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

Cu proprietatea pe zero, care este valoarea implicită documentată, activarea merge mai departe imediat ce adresarea se încheie. Setează o valoare pozitivă și activarea configurației IP așteaptă până când sosește un răspuns de la gateway sau expiră timpul.

Apoi oprește și repornește conexiunea urmărind fluxul de evenimente. Ordinea pe care o vezi este setarea făcându-și treaba: starea dispozitivului, adresarea, așteptarea și în final starea activată după care serviciile dependente sunt de obicei ordonate.

Așteptarea are două finaluri

Ambele finaluri contează, iar majoritatea oamenilor își amintesc doar unul. Un răspuns de la gateway încheie așteptarea mai devreme, iar expirarea o încheie și ea, indiferent dacă ceva a răspuns sau nu. Proprietatea nu cere un ping reușit înainte ca activarea să se poată încheia.

Acea singură frază lămurește multă confuzie despre laptopurile din hoteluri și centre de conferințe, unde un portal captiv refuză adesea ICMP până te autentifici. Conexiunea se activează totuși după ce expiră timpul; pur și simplu o face mai târziu decât era nevoie, iar fiecare serviciu ordonat după conexiune așteaptă împreună cu ea.

Nu este nici o verificare de vivacitate. Nimic din descriere nu începe să facă ping către un gateway după ce conexiunea este activă și nimic nu deconectează un profil activ pentru că un ping ulterior eșuează. Dacă ai nevoie de detectarea pierderilor, aceasta aparține protocolului sau proprietarului tunelului, nu unei proprietăți care a rulat o dată în timpul activării.

Două obiecte, o setare

Profilul de bază cu fir și un profil VPN sunt obiecte de configurare separate, iar setarea proprietății pe unul nu îl afectează pe celălalt. Un profil VPN care numește o conexiune de bază nu moștenește niciuna dintre setările ei de activare, motiv pentru care valoarea modificată poate părea că nu are efect asupra lucrului pe care îl urmăreai.

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

Citește UUID-urile, nu numele. Numele se dublează după o reinstalare sau un profil restaurat, iar două conexiuni cu același nume vizibil te vor face să editezi fișierul greșit în timp ce cel real rămâne neschimbat.

Contează și versiunea instalată de NetworkManager. Comportamentul pluginului și modul în care un tip de conexiune mapează această proprietate pe propriii pași de activare variază, așa că testează pe versiunea pe care o implementezi, în loc să presupui că un articol găsit se aplică neschimbat.

Ce nu poate certifica așteptarea

Iată partea care costă cel mai mult timp. Un răspuns de la routerul local dovedește că un host a răspuns la un ecou ICMP în timpul activării. Nu dovedește că un punct final VPN se rezolvă, că identitatea clientului este acceptată, că s-au instalat rute private, că resolverul biroului răspunde sau că aplicația care te interesează va funcționa.

Sunt dependențe separate cu dovezi separate. Un gateway poate răspunde în timp ce DNS eșuează, iar un gateway poate arunca în silență ICMP conform politicii în timp ce toate căile aplicației funcționează. Condiționarea pe această proprietate este deci o presupunere despre ce strat întârzie, nu o măsurare a lui.

Dacă aștepți un serviciu dependent, numește de ce are nevoie. La o adresă atribuită răspunde adresarea. La un tunel răspunde starea tunelului însuși. La un nume privat răspunde o interogare. La o aplicație răspunde aplicația, și niciunul dintre acele răspunsuri nu vine de la un temporizator numit după gateway.

Dacă o modifici, notează de ce

Înregistrează valoarea anterioară și motivul înainte de o modificare aprobată, apoi seteaz-o pe conexiunea specifică, nu peste tot. O așteptare mai lungă deplasează momentul activării pentru tot ce este ordonat după acea conexiune, ceea ce poate face un sistem lent să pară în regulă și unul rapid să pară stricat.

Merită numită o capcană istorică: o astfel de valoare este uneori modificată pentru ca un editor mai vechi să accepte un profil. Dacă aceasta este povestea reală, ai două evenimente, nu unul. Editorul a salvat, iar o politică de rețea live s-a schimbat. Repară editorul sau pluginul și pune temporizatorul la loc.

Sursa NetworkManager definește proprietatea ca o întârziere a succesului adresării IP până la un răspuns al gateway-ului sau expirarea timpului, cu valoarea implicită zero, iar definiția setării conexiunii este referința de citit înainte de a te baza pe un comportament descris din auzite.