ServerAliveInterval de SSH tra VPN: kiu flanko sendas la provon?

Plej multaj konsiloj pri subtenado de SSH-konekto haltas ĉe «aldonu ServerAliveInterval 30» kaj lasas ekstere la utilajn partojn. La ŝlosilvorto estas tempigilo ĉe la klienta flanko, kiu ekagas nur kiam la kanalo silentis, ĝi kalkulas neresponditajn provojn anstataŭ sekundojn, kaj ĝi loĝas en dosiero, kie venkas la unua kongrua valoro. Eraru pri tiuj tri ecoj kaj sana VPN-kunsido tamen falos, dum mortinta restos pendanta.

La du direktoj apartenas al malsamaj demonoj

ServerAliveInterval estas legata de via ssh-kliento. ClientAliveInterval estas legata de sshd ĉe la malproksima flanko kaj provas la alian direkton, de servilo al kliento. Ili ne estas alinomoj kaj ne kunlaboras, do agordi unu havas neniun efikon al la konduto de la alia flanko. Konfuzi ilin estas la kutima kaŭzo, kial korekto ŝajnas funkcii ĉe unu gastiganto kaj ne ĉe la sekva.

Ambaŭ akceptas nulon. Ĉe nulo la kliento sendas tute nenion, kaj ĉe la servila flanko ClientAliveCountMax de nulo malŝaltas la malkonekton, kiu alie sekvus neresponditajn kontrolojn.

Kion provo pruvas, kaj kion ne

Post kiam la agordita intervalo pasas sen alvenantaj datumoj de la servilo, la kliento sendas malgrandan peton tra la ekzistanta ĉifrita kanalo kaj atendas respondon. ServerAliveCountMax difinas, kiom da ili rajtas resti neresponditaj antaŭ ol la kunsido estos disŝirita. Kun intervalo de 60 kaj kalkulo de 3 la kliento rezignas post proksimume tri minutoj da silento, kaj tiu nombro estas eco de via agordo, ne de reta normo. Lasu la intervalon ĉe ĝia implicita valoro 0 kaj neniu provo iam estos sendata, kio estas kial norma kliento povas sidi sur mortinta konekto senfine.

Ĉar la interŝanĝo okazas ene de la SSH-transporto, respondo pruvas, ke la SSH-procezo de la alia flanko ankoraŭ legas kaj skribas. Ĝi diras nenion pri la programo, kiun vi lanĉis ene de tiu kunsido: datumbaza kliento, plusendita pordo aŭ longdaŭra skripto povas esti blokitaj dum la transporto ĝoje respondas al provoj.

TCPKeepAlive estas aparta mekanismo unu tavolon pli malalte. La kerno traktas ĝin, ĝi ne estas ĉifrita, kaj flanko, kies SSH-demono blokiĝis, ankoraŭ povas kontentigi ĝin. Tial la provo je la SSH-nivelo estas la pli signifa signalo, kiam vi zorgas pri la kunsido anstataŭ pri la ingo.

La ordo decidas, kiu valoro postvivas

OpenSSH aplikas la unuan valoron, kiun ĝi akiras por ĉiu parametro, do specifa Host-bloko devas aperi antaŭ iu ajn pli larĝa bloko, kiu ankaŭ kongruus. Metu la implicajn valorojn kun ĵokeroj ĉe la fundo de la dosiero, ne ĉe la supro, kaj memoru, ke Match-bloko pli malsupre ne povas superregi valoron jam agorditan. La OpenSSH-referenco pri klienta agordo rekte esprimas la regulon de la unua valoro, kaj indas legi ĝin unufoje antaŭ ol reorganizi komunan agordon.

La opcioj de la komanda linio superas la dosieron, kio igas provizoran eksperimenton malmultekosta:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Por vidi, kion la kliento efektive solvis, anstataŭ kion vi pensas, ke vi skribis, petu ĝin elflui la efektivan agordon. La eligo enhavas la kunfanditajn valorojn por tiu gastigantnomo kaj estas la plej rapida maniero kapti vagantan pli fruan blokon:

ssh -G office-shell | grep -i alive

Kion keepalives faras tra tunelo

Perioda trafiko malhelpas al stateca NAT aŭ fajroŝirma surĵeto eksvalidiĝi, kio estas vera avantaĝo ĉe VPN, kies enirejo forĵetas senaktivajn fluojn post kelkaj minutoj. Provoj alvenantaj ĉiujn 60 sekundojn refreŝigas tiun surĵeton sen porti aplikaĵdatumojn.

Ili ne povas rekonstrui vojon, kiu malaperis. Kiam la tunela interfaco malaperas, la provoj malsukcesas kiel ĉio alia, kaj la kunsido finiĝas post kiam la kalkulo elĉerpiĝas. Vivo-detekto kaj voja rehavo estas malsamaj problemoj, kaj nur la unua estas agordebla en ssh_config. Kion la intervalo kaj kalkulo vere aĉetas al vi estas kiom rapide la kliento rimarkas ĝin, kaj tio estas la parto, kiun uzanto spertas kiel pendiĝon.

Multiksitaj konektoj aldonas faldo. Kun ControlMaster en la ludo, la provoj apartenas al la ĉefa konekto, kaj nova kunsido super ekzistanta ĉefa heredas tion, kion tiu ĉefa interkonsentis. Se la mux-ĉefa blokiĝis, malfermi alian fenestron ne denove testos la vojon.

Konfirmi la agordon de komenco ĝis fino

Sur la servilo, elfluu la efektivan demonan agordon anstataŭ legi la dosieron kaj diveni, kiu inkludo venkis:

sshd -T | grep -i clientalive

Poste observu realan kunsidon kun ŝaltita sencimiga eligo. La kliento presas linion pri templimo, kiam la kalkulo elĉerpiĝas, kaj la tempomarkoj ĉirkaŭ ĝi montras, ĉu la silento estis kontinua aŭ la provoj tute ne estis senditaj. Kunsido, kiu mortas sen ia provtrafiko, kutime havas la ŝlosilvorton en bloko, kiu neniam kongruis.

Indas aldoni du kontrolojn por ĉiu gastiganto, kiun vi atingas nur tra tunelo: konfirmu, ke la solvita intervalo estas la intencita, kaj konfirmu, ke tiu intervalo multiplikita per la kalkulo estas pli mallonga ol la senaktiva templimo ĉe la VPN-enirejo. Kiam la dua nombro estas pli granda, la enirejo unue silente forĵetas la fluon kaj la SSH-provo neniam ricevas ŝancon raporti ion.