Waarop gateway-ping-timeout in NetworkManager werklik wag

Jy vind connection.gateway-ping-timeout in ’n draad oor ’n skootrekenaar wat opkom voordat die netwerk bruikbaar is, jy verhoog dit, en iets verander. Of die verandering gehelp het om die rede wat jy dink, is ’n aparte vraag. Die antwoord begin by wat die aktivering werklik doen terwyl daardie tydhouer loop, en by die feit dat die wag twee moontlike eindes het.

Volg een verbinding vanaf die opdragreël en die semantiek word konkreet.

Volg een aktivering

Begin deur na die gestoorde verbinding te kyk eerder as na ’n globale verstekwaarde, want dit is ’n eienskap per verbinding. Voeg --show-secrets slegs by as jy dit werklik nodig het; die instelling self is nie ’n geheim nie.

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

Met die eienskap op nul, wat die gedokumenteerde verstek is, gaan die aktivering verder sodra adressering voltooi is. Stel dit op ’n positiewe waarde en die aktivering van IP-konfigurasie wag totdat óf ’n antwoord van die gateway opdaag óf die tydsbeperking verstryk.

Bring dan die verbinding af en op terwyl jy die stroom gebeurtenisse dophou. Die volgorde wat jy sien, is die instelling wat sy werk doen: toestand van die toestel, adressering, die wag, en uiteindelik die geaktiveerde toestand waarteen afhanklike dienste gewoonlik georden word.

Die wag het twee eindes

Albei eindes maak saak, en die meeste mense onthou net een. ’n Antwoord van die gateway voltooi die wag vroeg, en die tydsbeperking voltooi dit ook, of iets geantwoord het of nie. Die eienskap vereis nie ’n suksesvolle ping voordat aktivering kan voltooi nie.

Daardie enkele sin verduidelik baie verwarring oor skootrekenaars by hotelle en konferensiesentrums, waar ’n captive portal dikwels ICMP weier totdat jy aanmeld. Die verbinding aktiveer steeds nadat die tydsbeperking verstryk het; dit doen net later as wat nodig was, en elke diens wat na die verbinding georden is, wag saam.

Dit is ook nie ’n lewendigheidstoets nie. Niks in die beskrywing begin ’n gateway ping nadat die verbinding op is nie, en niks ontkoppel ’n aktiewe profiel omdat ’n latere ping misluk nie. As jy verliesopsporing nodig het, hoort dit by die protokol of die tonnel-eienaar, nie by ’n eienskap wat een keer tydens aktivering geloop het nie.

Twee voorwerpe, een instelling

Die bedrade basisprofiel en ’n VPN-profiel is aparte konfigurasievoorwerpe, en om die eienskap op een te stel, raak nie die ander nie. ’n VPN-profiel wat ’n basisverbinding noem, erf niks van sy aktiveringsinstellings nie, en daarom kan die waarde wat jy verander het, lyk of dit geen effek het op die ding wat jy dopgehou het nie.

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

Lees die UUID’s eerder as die name. Name word gedupliseer na ’n herinstallering of ’n herstelde profiel, en twee verbindings met dieselfde sigbare naam sal jou die verkeerde lêer laat redigeer terwyl die regte een onveranderd bly.

Die geïnstalleerde NetworkManager-weergawe maak ook saak. Inpropgedrag en hoe ’n verbindingstipe hierdie eienskap op sy eie aktiveringsstappe afbeeld, verskil, so toets op die weergawe wat jy ontplooi eerder as om aan te neem dat ’n pos wat jy gevind het onveranderd geld nie.

Wat die wag nie kan sertifiseer nie

Hier is die deel wat die meeste tyd kos. ’n Antwoord van die plaaslike router bewys dat een gasheer een ICMP-eggoboodskap tydens aktivering geantwoord het. Dit bewys nie dat ’n VPN-eindpunt opgelos word nie, dat die kliënt se identiteit aanvaar word nie, dat private roetes geïnstalleer is nie, dat die kantoor-resolver antwoord nie, of dat die toepassing waaroor jy gee, sal werk nie.

Daardie dinge is aparte afhanklikhede met aparte bewyse. ’n Gateway kan antwoord terwyl DNS faal, en ’n gateway kan ICMP per beleid stilweg laat val terwyl elke toepassingsroete werk. Om op hierdie eienskap te hek, is dus ’n raaiskoot oor watter laag laat is, nie ’n meting daarvan nie.

As jy op ’n afhanklike diens wag, noem wat dit nodig het. ’n Toegewysde adres word deur adressering beantwoord. ’n Tonnel word deur die tonnel se eie toestand beantwoord. ’n Private naam word deur ’n navraag beantwoord. ’n Toepassing word deur die toepassing beantwoord, en nie een van daardie antwoorde kom van ’n tydhouer wat na die gateway vernoem is nie.

As jy dit verander, skryf neer waarom

Teken die vorige waarde en die rede aan voor ’n goedgekeurde verandering, en stel dit dan op die spesifieke verbinding eerder as oral. ’n Langer wag verskuif aktiveringstyd vir alles wat na daardie verbinding georden is, wat ’n stadige stelsel goed kan laat lyk en ’n vinnige een stukkend.

Een historiese lokval is die moeite werd om te noem: ’n waarde soos hierdie word soms verander om ’n ouer redigeerder ’n profiel te laat aanvaar. As dit die werklike verhaal is, het jy twee gebeurtenisse, nie een nie. Die redigeerder het gestoor, en ’n lewendige netwerkbeleid het verander. Maak die redigeerder of die inprop reg en sit die tydhouer terug.

Die NetworkManager-bron definieer die eienskap as ’n vertraging van IP-adresseringsukses tot ’n gateway-antwoord of die tydsbeperking, met ’n verstek van nul, en die definisie van die verbindingsinstelling is die verwysing om te lees voordat jy op enige gedrag staatmaak wat tweedehands beskryf word.