SSH ServerAliveInterval over en VPN: hvilken ende sender sonden?

De fleste SSH-keepalive-råd stopper ved «legg til ServerAliveInterval 30» og utelater de nyttige delene. Nøkkelordet er en timer på klientsiden som bare utløses når kanalen har vært stille, den teller ubesvarte sonder i stedet for sekunder, og den bor i en fil der den første samsvarende verdien vinner. Tar du feil på disse tre egenskapene, faller en sunn VPN-økt likevel, mens en død blir hengende.

De to retningene tilhører forskjellige daemoner

ServerAliveInterval leses av ssh-klienten din. ClientAliveInterval leses av sshd på den andre siden og sonderer den andre veien, fra server til klient. De er ikke aliaser og samarbeider ikke, så å sette den ene har ingen virkning på oppførselen til den andre enden. Å forveksle dem er den vanlige grunnen til at en rettelse ser ut til å virke på én vert og ikke på den neste.

Begge godtar null. Ved null sender klienten ingenting i det hele tatt, og på serversiden deaktiverer en ClientAliveCountMax på null frakoblingen som ellers ville følge ubesvarte kontroller.

Hva en sonderende prøve beviser, og hva den ikke gjør

Når det angitte intervallet har gått uten at data har kommet fra serveren, sender klienten en liten forespørsel gjennom den eksisterende krypterte kanalen og venter på svar. ServerAliveCountMax fastsetter hvor mange av dem som kan forbli ubesvarte før økten rives ned. Med et intervall på 60 og et antall på 3 gir klienten opp omkring tre minutters stillhet, og det tallet er en egenskap ved konfigurasjonen din, ikke en nettverksstandard. Lar du intervallet stå på standardverdien 0, sendes aldri noen sonde, og det er grunnen til at en vanlig klient kan sitte på en død forbindelse på ubestemt tid.

Siden utvekslingen foregår inne i SSH-transporten, beviser et svar at motpartens SSH-prosess fortsatt leser og skriver. Det sier ingenting om programmet du startet inne i den økten: en databaseklient, en videresendt port eller et langvarig skript kan være fastlåst mens transporten glad svarer på sonder.

TCPKeepAlive er en egen mekanisme ett lag lenger ned. Kjernen håndterer den, den er ikke kryptert, og en motpart der SSH-daemonen har hengt seg, kan fortsatt oppfylle den. Derfor er sonden på SSH-nivå det mer meningsfulle signalet når du bryr deg om økten og ikke om sokkelen.

Rekkefølgen avgjør hvilken verdi som overlever

OpenSSH bruker den første verdien den får for hver parameter, så en spesifikk Host-blokk må stå før enhver bredere blokk som også ville samsvare. Legg standardverdier med jokertegn nederst i filen, ikke øverst, og husk at en Match-blokk lenger ned ikke kan overstyre en verdi som allerede er satt. Referansen for OpenSSH-klientkonfigurasjon sier regelen om første verdi direkte, og det er verdt å lese den én gang før du omorganiserer en delt konfigurasjon.

Kommandolinjevalg vinner over filen, noe som gjør et midlertidig eksperiment billig:

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

For å se hva klienten faktisk løste ut i stedet for hva du tror du skrev, be den dumpe den effektive konfigurasjonen. Utdataene inneholder de sammenslåtte verdiene for det vertsnavnet og er den raskeste måten å fange en bortkommen tidligere blokk:

ssh -G office-shell | grep -i alive

Hva keepalives gjør over en tunnel

Periodisk trafikk hindrer at en tilstandsfull NAT- eller brannmurssammenkobling utløper, noe som er en reell fordel på en VPN der gatewayen slipper inaktive strømmer etter noen minutter. Sonder som ankommer med 60 sekunders mellomrom fornyer den sammenkoblingen uten å bære noen applikasjonsdata.

De kan ikke bygge opp en vei som er borte. Når tunnelgrensesnittet forsvinner, feiler sondene som alt annet, og økten avsluttes når antallet er brukt opp. Levedyktighetsdeteksjon og gjenoppretting av veien er forskjellige problemer, og bare det første kan konfigureres i ssh_config. Det intervallet og antallet faktisk kjøper deg, er hvor raskt klienten merker det, og det er den delen en bruker opplever som en henging.

Multipleksede forbindelser legger til en fold. Med ControlMaster i spill tilhører sondene hovedforbindelsen, og en ny økt over en eksisterende hoved arver det den hovedforbindelsen forhandlet. Hvis mux-hoveden er fastlåst, vil åpning av et annet vindu ikke teste veien på nytt.

Bekrefte innstillingen fra ende til annen

På serveren dumper du daemonens effektive konfigurasjon i stedet for å lese filen og gjette hvilken include som vant:

sshd -T | grep -i clientalive

Se deretter på en ekte økt med feilsøkingsutdata slått på. Klienten skriver ut en tidsavbruddslinje når antallet er brukt opp, og tidsstemplene rundt viser om stillheten var sammenhengende eller om sondene aldri ble sendt. En økt som dør uten sondetrafikk har vanligvis nøkkelordet i en blokk som aldri samsvarte.

To kontroller er verdt å legge til for enhver vert du bare når gjennom en tunnel: bekreft at det oppløste intervallet er det du mente, og bekreft at det intervallet multiplisert med antallet er kortere enn inaktivitetstidsavbruddet på VPN-gatewayen. Når det andre tallet er større, slipper gatewayen strømmen stille først, og sonden får aldri sjansen til å rapportere noe.