Për çfarë pret vërtet gateway-ping-timeout te NetworkManager

E gjeni connection.gateway-ping-timeout në një diskutim për një laptop që ndizet përpara se rrjeti të jetë i përdorshëm, e rritni, dhe diçka ndryshon. Nëse ndryshimi ndihmoi për arsyen që mendoni, është pyetje më vete. Përgjigja nis me atë që aktivizimi bën në të vërtetë ndërsa ai kohëmatës punon, dhe me faktin se pritja ka dy përfundime të mundshme.

Ndigni një lidhje nga rreshti i komandave dhe semantika bëhet konkrete.

Ndjekja e një aktivizimi

Filloni me lidhjen e ruajtur dhe jo me një parazgjedhje globale, sepse kjo është një veti për çdo lidhje. Shtoni --show-secrets vetëm nëse ju nevojitet vërtet; vetë cilësimi nuk është sekret.

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

Kur vetia është zero, që është parazgjedhja e dokumentuar, aktivizimi vazhdon sapo përfundon adresimi. Vendosni një vlerë pozitive dhe aktivizimi i konfigurimit IP pret derisa të vijë një përgjigje nga porta ose të skadojë kohëmatësi.

Pastaj uleni dhe ngrijeni lidhjen duke ndjekur rrjedhën e ngjarjeve. Rendi që shihni është cilësimi duke bërë punën e vet: gjendja e pajisjes, adresimi, pritja dhe në fund gjendja e aktivizuar sipas së cilës zakonisht renditen shërbimet e varura.

Pritja ka dy përfundime

Të dy përfundimet kanë rëndësi, dhe shumica e njerëzve mbajnë mend vetëm një. Një përgjigje nga porta e përfundon pritjen më herët, dhe skadimi e përfundon gjithashtu, pavarësisht nëse diçka u përgjigj apo jo. Vetia nuk kërkon një ping të suksesshëm përpara se aktivizimi të përfundojë.

Ai një fjali sqaron shumë konfuzion rreth laptopëve në hotele dhe qendra konferencash, ku portali i kapjes shpesh refuzon ICMP derisa të hyni. Lidhja aktivizohet gjithsesi pasi skadon kohëmatësi; thjesht e bën këtë më vonë sesa duhej, dhe çdo shërbim i renditur pas lidhjes pret bashkë me të.

Nuk është as një kontroll jetëgjatësie. Asgjë në përshkrim nuk fillon të pingojë një portë pasi lidhja është lart, dhe asgjë nuk shkëput një profil aktiv sepse një ping i mëvonshëm dështon. Nëse ju nevojitet zbulimi i humbjeve, kjo i përket protokollit ose pronarit të tunelit, jo një vetie që u ekzekutua një herë gjatë aktivizimit.

Dy objekte, një cilësim

Profili bazë me tel dhe një profil VPN janë objekte konfigurimi të veçanta, dhe vendosja e vetisë në njërin nuk ndikon në tjetrin. Një profil VPN që emërton një lidhje bazë nuk trashëgon asnjë nga cilësimet e saj të aktivizimit, prandaj vlera që ndryshuat mund të duket se nuk ka asnjë efekt mbi atë që po vëzhgonit.

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

Lexoni UUID-të dhe jo emrat. Emrat dyfishohen pas një riinstalimi ose një profili të rikthyer, dhe dy lidhje me të njëjtin emër të dukshëm do t'ju bëjnë të redaktoni skedarin e gabuar ndërsa ai i vërteti mbetet i pandryshuar.

Ka rëndësi edhe versioni i instaluar i NetworkManager. Sjellja e shtojcës dhe mënyra se si një lloj lidhjeje e harton këtë veti në hapat e vetë të aktivizimit ndryshojnë, prandaj provoni në versionin që vendosni në punë në vend që të supozoni se një artikull i gjetur zbatohet pa ndryshime.

Çfarë pritja nuk mund të vërtetojë

Këtu është pjesa që kushton më shumë kohë. Një përgjigje nga ruteri lokal provon se një host iu përgjigj një jehone ICMP gjatë aktivizimit. Nuk provon se një pikë fundore VPN zgjidhet, se identiteti i klientit pranohet, se u instaluan rrugë private, se zgjidhësi i zyrës përgjigjet, ose se aplikacioni që ju intereson do të punojë.

Këto janë varësi të veçanta me prova të veçanta. Një portë mund të përgjigjet ndërsa DNS dështon, dhe një portë mund të hedhë në heshtje ICMP sipas politikës ndërsa të gjitha rrugët e aplikacionit punojnë. Pra, kushtëzimi mbi këtë veti është një hamendje se cila shtresë është vonë, jo një matje e saj.

Nëse po prisni një shërbim të varur, emërtoni çfarë i nevojitet. Një adresë e caktuar përgjigjet nga adresimi. Një tunel përgjigjet nga gjendja e vetë tunelit. Një emër privat përgjigjet nga një pyetës. Një aplikacion përgjigjet nga aplikacioni, dhe asnjë nga ato përgjigje nuk vjen nga një kohëmatës i pagëzuar sipas portës.

Nëse e ndryshoni, shkruani pse

Regjistroni vlerën e mëparshme dhe arsyen përpara një ndryshimi të miratuar, pastaj vendoseni në lidhjen specifike dhe jo kudo. Një pritje më e gjatë zhvendos kohën e aktivizimit për gjithçka të renditur pas asaj lidhjeje, gjë që mund ta bëjë një sistem të ngadaltë të duket mirë dhe një të shpejtë të duket i prishur.

Vlen të përmendet një kurth historik: një vlerë e tillë ndonjëherë ndryshohet që një redaktor i vjetër të pranojë një profil. Nëse kjo është historia e vërtetë, keni dy ngjarje, jo një. Redaktori ruajti, dhe një politikë rrjeti e gjallë ndryshoi. Rregulloni redaktorin ose shtojcën dhe kthejeni kohëmatësin aty ku ishte.

Kodi burim i NetworkManager e përcakton vetinë si një vonesë të suksesit të adresimit IP deri në një përgjigje të portës ose në skadimin e kohëmatësit, me parazgjedhje zero, dhe përkufizimi i cilësimit të lidhjes është referenca që duhet lexuar përpara se të mbështeteni në sjellje të treguar nga të tjerët.