Kion gateway-ping-timeout vere atendas en NetworkManager

Vi trovas connection.gateway-ping-timeout en fadeno pri tekokomputilo, kiu ekfunkcias antaŭ ol la reto estas uzebla, vi pliigas ĝin, kaj io ŝanĝiĝas. Ĉu la ŝanĝo helpis pro la kialo, kiun vi pensas, estas aparta demando. La respondo komenciĝas per tio, kion la aktivigo efektive faras dum tiu tempigilo funkcias, kaj per la fakto, ke la atendo havas du eblajn finojn.

Sekvu unu konekton el la komandlinio kaj la semantiko fariĝas konkreta.

Sekvu unu aktivigon

Komencu rigardante la konservitan konekton anstataŭ tutmondan defaŭlton, ĉar ĉi tio estas eco por unuopa konekto. Aldonu --show-secrets nur se vi vere bezonas ĝin; la agordo mem ne estas sekreto.

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

Kiam la eco estas nulo, kio estas la dokumentita defaŭlto, la aktivigo daŭras tuj kiam la adresado finiĝas. Agordu ĝin al pozitiva valoro kaj la aktivigo de la IP-agordo atendas ĝis respondo alvenas de la pordego aŭ la tempolimo finiĝas.

Poste mallevu kaj relevu la konekton dum vi observas la eventan fluon. La ordo, kiun vi vidas, estas la agordo faranta sian laboron: aparata stato, adresado, la atendo kaj fine la aktivigita stato, laŭ kiu dependaj servoj kutime estas ordigitaj.

La atendo havas du finojn

Ambaŭ finoj gravas, kaj plej multaj homoj memoras nur unu. Respondo de la pordego finas la atendon frue, kaj la tempolimo ankaŭ finas ĝin, ĉu io respondis aŭ ne. La eco ne postulas sukcesan ping antaŭ ol la aktivigo povas finiĝi.

Tiu sola frazo klarigas multan konfuzon pri tekokomputiloj en hoteloj kaj konferencaj centroj, kie kaptita portalo ofte rifuzas ICMP ĝis vi ensalutos. La konekto tamen aktiviĝas post kiam la tempolimo finiĝas; ĝi simple faras tion pli malfrue ol necese, kaj ĉiu servo ordigita post la konekto atendas kune kun ĝi.

Ĝi ankaŭ ne estas vivkapabla kontrolo. Nenio en la priskribo komencas pingsendi al pordego post kiam la konekto estas supren, kaj nenio malkonektas aktivan profilon ĉar posta ping malsukcesas. Se vi bezonas perdo-detekton, tio apartenas al la protokolo aŭ al la posedanto de la tunelo, ne al eco, kiu funkciis unufoje dum la aktivigo.

Du objektoj, unu agordo

La drata baza profilo kaj VPN-profilo estas apartaj agordaj objektoj, kaj agordi la econ sur unu ne influas la alian. VPN-profilo, kiu nomas bazan konekton, ne heredas iun ajn el ĝiaj aktivigaj agordoj, kaj tial la valoro, kiun vi ŝanĝis, povas ŝajni sen efiko sur tio, kion vi observis.

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

Legu la UUID-ojn anstataŭ la nomojn. Nomoj duobliĝas post reinstalo aŭ restarigita profilo, kaj du konektoj kun la sama videbla nomo sendos vin redakti la malĝustan dosieron dum la vera restas senŝanĝa.

Ankaŭ la instalita versio de NetworkManager gravas. La konduto de kromaĵoj kaj kiel konekta tipo mapas ĉi tiun econ al siaj propraj aktivigaj paŝoj varias, do testu sur la versio, kiun vi deplojas, anstataŭ supozi, ke trovita artikolo validas senŝanĝe.

Kion la atendo ne povas atesti

Jen la parto, kiu kostas plej multe da tempo. Respondo de la loka enkursigilo pruvas, ke unu gastiganto respondis unu ICMP-ekon dum la aktivigo. Ĝi ne pruvas, ke VPN-finpunkto solviĝas, ke la identeco de la kliento akceptiĝas, ke privataj vojoj instaliĝis, ke la oficeja solvilo respondas, aŭ ke la aplikaĵo, pri kiu vi zorgas, funkcios.

Tiuj estas apartaj dependaĵoj kun apartaj pruvoj. Pordego povas respondi dum DNS malsukcesas, kaj pordego povas silente forĵeti ICMP laŭ politiko dum ĉiu aplikaĵa vojo funkcias. Do dependigi ĉion de ĉi tiu eco estas konjekto pri tio, kiu tavolo malfruas, ne mezuro de ĝi.

Se vi atendas dependan servon, nomu, kion ĝi bezonas. Al asignita adreso respondas la adresado. Al tunelo respondas la propra stato de la tunelo. Al privata nomo respondas demando. Al aplikaĵo respondas la aplikaĵo, kaj neniuj el tiuj respondoj venas de tempigilo nomita laŭ la pordego.

Se vi ŝanĝas ĝin, skribu kial

Notu la antaŭan valoron kaj la kialon antaŭ aprobita ŝanĝo, poste agordu ĝin sur la specifa konekto anstataŭ ĉie. Pli longa atendo movas la aktivigan tempon por ĉio ordigita post tiu konekto, kio povas igi malrapidan sistemon aspekti bone kaj rapidan aspekti difektita.

Unu historia kaptilo indas esti nomita: valoro kiel ĉi tio foje ŝanĝiĝas por ke pli malnova redaktilo akceptu profilon. Se tio estas la vera rakonto, vi havas du eventojn, ne unu. La redaktilo konservis, kaj viva reta politiko ŝanĝiĝis. Riparu la redaktilon aŭ la kromaĵon kaj remetu la tempigilon.

La fonto de NetworkManager difinas la econ kiel prokraston de la sukceso de IP-adresado ĝis pordega respondo aŭ la tempolimo, kun defaŭlto nulo, kaj la difino de la konekta agordo estas la referenco legenda antaŭ ol fidi iun ajn konduton priskribitan duaranke.