SSH ServerAliveInterval över en VPN: vilken ände skickar sonden?

De flesta SSH-keepalive-råd stannar vid «lägg till ServerAliveInterval 30» och utelämnar de användbara delarna. Nyckelordet är en timer på klientsidan som bara utlöses när kanalen har varit tyst, den räknar obesvarade sonder i stället för sekunder, och den bor i en fil där det första matchande värdet vinner. Tar du fel på dessa tre egenskaper faller en frisk VPN-session ändå, medan en död blir hängande.

De två riktningarna tillhör olika daemoner

ServerAliveInterval läses av din ssh-klient. ClientAliveInterval läses av sshd på andra sidan och sondar åt andra hållet, från server till klient. De är inte alias och samarbetar inte, så att ställa in den ena påverkar inte den andra sidans beteende. Att blanda ihop dem är det vanliga skälet till att en rättelse verkar fungera på en värd och inte på nästa.

Båda accepterar noll. Vid noll skickar klienten ingenting alls, och på serversidan inaktiverar en ClientAliveCountMax på noll frånkopplingen som annars skulle följa obesvarade kontroller.

Vad en sond bevisar och vad den inte bevisar

När det inställda intervallet har gått utan att data kommit från servern skickar klienten en liten begäran genom den befintliga krypterade kanalen och väntar på svar. ServerAliveCountMax bestämmer hur många av dem som får förbli obesvarade innan sessionen rivs. Med ett intervall på 60 och ett antal på 3 ger klienten upp efter ungefär tre minuters tystnad, och den siffran är en egenskap hos din konfiguration, inte en nätverksstandard. Låt intervallet stå på standardvärdet 0 och ingen sond skickas någonsin, vilket är skälet till att en vanlig klient kan sitta på en död anslutning i oändlighet.

Eftersom utbytet sker inne i SSH-transporten bevisar ett svar att motpartens SSH-process fortfarande läser och skriver. Det säger ingenting om programmet du startade inne i den sessionen: en databasklient, en vidarebefordrad port eller ett långvarigt skript kan sitta fast medan transporten glatt svarar på sonder.

TCPKeepAlive är en separat mekanism ett lager längre ned. Kärnan hanterar den, den är inte krypterad, och en motpart vars SSH-daemon har fastnat kan ändå uppfylla den. Därför är sonden på SSH-nivå den mer meningsfulla signalen när du bryr dig om sessionen och inte om socketen.

Ordningen avgör vilket värde som överlever

OpenSSH använder det första värde det får för varje parameter, så ett specifikt Host-block måste stå före varje bredare block som också skulle matcha. Lägg standardvärden med jokertecken längst ned i filen, inte överst, och kom ihåg att ett Match-block längre ned inte kan åsidosätta ett värde som redan är satt. Referensen för OpenSSH-klientkonfiguration anger regeln om första värdet direkt, och den är värd att läsa en gång innan du organiserar om en delad konfiguration.

Kommandoradsflaggor vinner över filen, vilket gör ett tillfälligt experiment billigt:

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

För att se vad klienten faktiskt löste ut i stället för vad du tror att du skrev, be den dumpa den effektiva konfigurationen. Utdata innehåller de sammanslagna värdena för det värdnamnet och är det snabbaste sättet att fånga ett bortkommet tidigare block:

ssh -G office-shell | grep -i alive

Vad keepalives gör över en tunnel

Periodisk trafik hindrar en tillståndskänslig NAT- eller brandväggsmappning från att gå ut, vilket är en verklig fördel på en VPN vars gateway släpper inaktiva flöden efter några minuter. Sonder som anländer var 60:e sekund förnyar den mappningen utan att bära några applikationsdata.

De kan inte bygga upp en väg som är borta. När tunnelgränssnittet försvinner misslyckas sonderna som allt annat, och sessionen avslutas när antalet är slut. Livsteckendetektering och återställning av vägen är olika problem, och bara det första kan konfigureras i ssh_config. Det intervallet och antalet faktiskt köper dig är hur snabbt klienten märker det, och det är den del en användare upplever som en hängning.

Multiplexade anslutningar lägger till ett veck. Med ControlMaster i spel tillhör sonderna huvudanslutningen, och en ny session över en befintlig huvud ärver det som den huvudanslutningen förhandlade. Om mux-huvudet har fastnat kommer ett annat fönster inte att testa vägen igen.

Bekräfta inställningen från början till slut

På servern, dumpa daemonens effektiva konfiguration i stället för att läsa filen och gissa vilken include som vann:

sshd -T | grep -i clientalive

Titta sedan på en riktig session med felsökningsutdata påslagen. Klienten skriver ut en tidsgränsrad när antalet tar slut, och tidsstämplarna runt den visar om tystnaden var sammanhängande eller om sonderna aldrig skickades. En session som dör utan sondtrafik har oftast nyckelordet i ett block som aldrig matchade.

Två kontroller är värda att lägga till för varje värd du bara når via en tunnel: bekräfta att det upplösta intervallet är det du menade, och bekräfta att det intervallet multiplicerat med antalet är kortare än inaktivitetsgränsen på VPN-gatewayen. När det andra talet är större släpper gatewayen flödet tyst först, och sonden får aldrig chansen att rapportera något.