SSH ServerAliveInterval over en VPN: hvilken ende sender sonden?

Det meste SSH-keepalive-råd stopper ved »tilføj ServerAliveInterval 30« og udelader de nyttige dele. Nøgleordet er en timer på klientsiden, der kun udløses, når kanalen har været tavs, den tæller ubesvarede sonder i stedet for sekunder, og den bor i en fil, hvor den første matchende værdi vinder. Tager du fejl af disse tre egenskaber, falder en sund VPN-session alligevel, mens en død hænger ved.

De to retninger tilhører forskellige dæmoner

ServerAliveInterval læses af din ssh-klient. ClientAliveInterval læses af sshd på den anden side og sender sonder den anden vej, fra server til klient. De er ikke aliaser og samarbejder ikke, så indstilling af den ene har ingen virkning på den anden sides adfærd. At forveksle dem er den sædvanlige grund til, at en rettelse ser ud til at virke på en vært og ikke på den næste.

Begge accepterer nul. Ved nul sender klienten slet intet, og på serversiden deaktiverer en ClientAliveCountMax på nul den afbrydelse, der ellers ville følge efter ubesvarede kontrolbeskeder.

Hvad en sonde beviser, og hvad den ikke gør

Når det indstillede interval er gået, uden at der er kommet data fra serveren, sender klienten en lille anmodning gennem den eksisterende krypterede kanal og venter på svar. ServerAliveCountMax fastlægger, hvor mange af dem der må forblive ubesvarede, før sessionen rives ned. Med et interval på 60 og et antal på 3 giver klienten op omkring tre minutters tavshed, og det tal er en egenskab ved din konfiguration, ikke en netværksstandard. Lad intervallet stå på standardværdien 0, og der sendes aldrig nogen sonde, hvilket er grunden til, at en almindelig klient kan sidde på en død forbindelse i det uendelige.

Fordi udvekslingen foregår inde i SSH-transporten, beviser et svar, at modpartens SSH-proces stadig læser og skriver. Det siger intet om det program, du startede inde i den session: en databaseklient, en videresendt port eller et langvarigt script kan være fastlåst, mens transporten glad svarer på sonder.

TCPKeepAlive er en separat mekanisme et lag længere nede. Kernen håndterer den, den er ikke krypteret, og en modpart, hvis SSH-dæmon er gået i stå, kan stadig opfylde den. Derfor er sonden på SSH-niveau det mere meningsfulde signal, når du bekymrer dig om sessionen frem for soklen.

Rækkefølgen afgør, hvilken værdi der overlever

OpenSSH anvender den første værdi, den får for hver parameter, så en specifik Host-blok skal stå før enhver bredere blok, der også ville matche. Læg standardværdier med jokertegn nederst i filen, ikke øverst, og husk, at en Match-blok længere nede ikke kan tilsidesætte en værdi, der allerede er sat. Referencen for OpenSSH-klientkonfiguration angiver reglen om den første værdi direkte, og det er værd at læse den én gang, før du omorganiserer en delt konfiguration.

Kommandolinjeindstillinger vinder over filen, hvilket gør et midlertidigt eksperiment billigt:

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

For at se, hvad klienten faktisk har løst, i stedet for hvad du tror, du skrev, så bed den om at dumpe den effektive konfiguration. Outputtet indeholder de sammenflettede værdier for det værtsnavn og er den hurtigste måde at fange en vildfaren tidligere blok:

ssh -G office-shell | grep -i alive

Hvad keepalives gør over en tunnel

Periodisk trafik forhindrer, at en stateful NAT- eller firewall-mapping udløber, hvilket er en reel fordel på en VPN, hvis gateway dropper inaktive flows efter et par minutter. Sonder, der ankommer med 60 sekunders mellemrum, fornyer den mapping uden at bære applikationsdata.

De kan ikke genopbygge en vej, der er forsvundet. Når tunnelinterfacet forsvinder, fejler sonderne som alt andet, og sessionen slutter, når antallet er opbrugt. Livstegnsregistrering og gendannelse af vejen er forskellige problemer, og kun det første kan konfigureres i ssh_config. Det, intervallet og antallet reelt køber dig, er hvor hurtigt klienten bemærker det, og det er den del, en bruger oplever som et hæng.

Multipleksede forbindelser tilføjer en fold. Med ControlMaster i spil tilhører sonderne masterforbindelsen, og en ny session over en eksisterende master arver, hvad den master forhandlede. Hvis mux-masteren er fastlåst, vil åbning af et andet vindue ikke teste vejen igen.

Bekræftelse af indstillingen fra ende til anden

På serveren dumper du dæmonens effektive konfiguration i stedet for at læse filen og gætte, hvilket include der vandt:

sshd -T | grep -i clientalive

Se derefter en rigtig session med fejlretningsoutput slået til. Klienten udskriver en timeout-linje, når antallet løber ud, og tidsstemplerne omkring den viser, om tavsheden var sammenhængende, eller om sonderne aldrig blev sendt. En session, der dør uden sondetrafik, har normalt nøgleordet i en blok, der aldrig matchede.

To kontroller er værd at tilføje for enhver vært, du kun når gennem en tunnel: bekræft, at det opløste interval er det, du havde til hensigt, og bekræft, at det interval ganget med antallet er kortere end idle-timeouten på VPN-gatewayen. Når det andet tal er større, dropper gatewayen først flowet i al stilhed, og sonden får aldrig en chance for at rapportere noget.