ServerAliveInterval di SSH su VPN: quale estremo invia la sonda?

La maggior parte dei consigli per mantenere viva una sessione SSH si ferma a «aggiungete ServerAliveInterval 30» e lascia fuori le parti utili. La parola chiave è un timer lato client che scatta solo quando il canale è rimasto silenzioso, conta le sonde senza risposta invece dei secondi, e vive in un file dove vince il primo valore corrispondente. Sbagliate queste tre proprietà e una sessione VPN sana cade comunque, mentre una morta resta appesa.

Le due direzioni appartengono a demoni diversi

ServerAliveInterval viene letto dal vostro client ssh. ClientAliveInterval viene letto da sshd dall'altra parte e sonda nella direzione opposta, dal server al client. Non sono alias e non collaborano, quindi impostare l'uno non ha alcun effetto sul comportamento dell'altro estremo. Confonderli è la ragione abituale per cui una correzione sembra funzionare su un host e non sul successivo.

Entrambi accettano zero. A zero il client non invia assolutamente nulla, e lato server un ClientAliveCountMax pari a zero disattiva la disconnessione che altrimenti seguirebbe ai controlli senza risposta.

Che cosa dimostra una sonda e che cosa no

Trascorso l'intervallo configurato senza che arrivino dati dal server, il client invia una piccola richiesta attraverso il canale cifrato esistente e attende una risposta. ServerAliveCountMax stabilisce quante di queste possono restare senza risposta prima che la sessione venga abbattuta. Con un intervallo di 60 e un conteggio di 3 il client si arrende dopo circa tre minuti di silenzio, e quella cifra è una proprietà della vostra configurazione, non uno standard di rete. Lasciate l'intervallo al valore predefinito 0 e nessuna sonda viene mai inviata, per questo un client standard può restare su una connessione morta all'infinito.

Poiché lo scambio avviene dentro il trasporto SSH, una risposta dimostra che il processo SSH dell'altro estremo sta ancora leggendo e scrivendo. Non dice nulla sul programma che avete avviato dentro quella sessione: un client di database, una porta inoltrata o uno script di lunga durata possono essere bloccati mentre il trasporto risponde allegramente alle sonde.

TCPKeepAlive è un meccanismo separato un livello più sotto. Se ne occupa il kernel, non è cifrato, e un estremo il cui demone SSH è bloccato può comunque soddisfarlo. Per questo la sonda a livello SSH è il segnale più significativo quando vi interessa la sessione e non il socket.

L'ordine decide quale valore sopravvive

OpenSSH applica il primo valore che ottiene per ogni parametro, quindi un blocco Host specifico deve comparire prima di qualsiasi blocco più ampio che corrisponderebbe anch'esso. Mettete i valori predefiniti con caratteri jolly in fondo al file, non in cima, e ricordate che un blocco Match più in basso non può sovrascrivere un valore già impostato. Il riferimento alla configurazione del client OpenSSH enuncia direttamente la regola del primo valore, e vale la pena leggerlo una volta prima di riorganizzare una configurazione condivisa.

Le opzioni della riga di comando battono il file, il che rende economico un esperimento temporaneo:

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

Per vedere che cosa ha realmente risolto il client invece di ciò che credete di aver scritto, chiedetegli di scaricare la configurazione effettiva. L'output contiene i valori uniti per quel nome host ed è il modo più rapido per intercettare un blocco precedente finito nel posto sbagliato:

ssh -G office-shell | grep -i alive

Che cosa fanno i keepalive attraverso un tunnel

Il traffico periodico impedisce a una mappatura NAT o firewall con stato di scadere, il che è un beneficio reale su una VPN il cui gateway scarta i flussi inattivi dopo qualche minuto. Le sonde che arrivano ogni 60 secondi rinnovano quella mappatura senza trasportare dati applicativi.

Non possono ricostruire un percorso che è sparito. Quando l'interfaccia del tunnel scompare le sonde falliscono come tutto il resto, e la sessione termina esaurito il conteggio. Il rilevamento di vitalità e il recupero del percorso sono problemi diversi, e solo il primo è configurabile in ssh_config. Ciò che intervallo e conteggio vi comprano davvero è la rapidità con cui il client se ne accorge, ed è la parte che l'utente vive come un blocco.

Le connessioni multiplexate aggiungono una piega. Con ControlMaster in gioco le sonde appartengono alla connessione principale, e una nuova sessione su un principale esistente eredita ciò che quel principale ha negoziato. Se il principale del mux è bloccato, aprire un'altra finestra non testerà di nuovo il percorso.

Confermare l'impostazione da un capo all'altro

Sul server, scaricate la configurazione effettiva del demone invece di leggere il file e indovinare quale include ha vinto:

sshd -T | grep -i clientalive

Poi osservate una sessione reale con l'output di debug attivo. Il client stampa una riga di timeout quando il conteggio si esaurisce, e i timestamp intorno mostrano se il silenzio è stato continuo o se le sonde non sono mai state inviate. Una sessione che muore senza traffico di sonde di solito ha la parola chiave in un blocco che non ha mai corrisposto.

Vale la pena aggiungere due controlli per ogni host che raggiungete solo attraverso un tunnel: confermate che l'intervallo risolto sia quello che intendevate, e confermate che quell'intervallo moltiplicato per il conteggio sia più breve del timeout di inattività sul gateway VPN. Quando il secondo numero è maggiore, il gateway scarta prima il flusso in silenzio e la sonda SSH non ha mai la possibilità di segnalare nulla.