SSH ServerAliveInterval over een VPN: welke kant stuurt de probe?

De meeste SSH-keepalive-adviezen stoppen bij «voeg ServerAliveInterval 30 toe» en laten de nuttige delen weg. Het sleutelwoord is een timer aan de clientkant die alleen afgaat als het kanaal stil is geweest, hij telt onbeantwoorde probes in plaats van seconden, en hij staat in een bestand waarin de eerste overeenkomende waarde wint. Vergis je in die drie eigenschappen en een gezonde VPN-sessie valt alsnog weg, terwijl een dode blijft hangen.

De twee richtingen horen bij verschillende daemons

ServerAliveInterval wordt gelezen door je ssh-client. ClientAliveInterval wordt gelezen door sshd aan de andere kant en peilt de andere richting op, van server naar client. Het zijn geen aliassen en ze werken niet samen, dus het instellen van de ene heeft geen effect op het gedrag van de andere kant. Ze door elkaar halen is de gebruikelijke reden dat een oplossing op de ene host lijkt te werken en op de volgende niet.

Beide accepteren nul. Bij nul stuurt de client helemaal niets, en aan de serverkant schakelt een ClientAliveCountMax van nul de verbinding uit die anders op onbeantwoorde controles zou volgen.

Wat een probe bewijst, en wat niet

Nadat het ingestelde interval is verstreken zonder dat er data van de server komt, stuurt de client een klein verzoek door het bestaande versleutelde kanaal en wacht op een antwoord. ServerAliveCountMax bepaalt hoeveel daarvan onbeantwoord mogen blijven voordat de sessie wordt afgebroken. Met een interval van 60 en een telling van 3 geeft de client het na ongeveer drie minuten stilte op, en dat getal is een eigenschap van jouw configuratie, geen netwerkstandaard. Laat je het interval op de standaardwaarde 0 staan, dan wordt er nooit een probe verstuurd, en daarom kan een standaardclient eindeloos op een dode verbinding blijven zitten.

Omdat de uitwisseling in het SSH-transport plaatsvindt, bewijst een antwoord dat het SSH-proces van de tegenpartij nog leest en schrijft. Over het programma dat je in die sessie hebt gestart zegt het niets: een databaseclient, een doorgestuurde poort of een langlopend script kan vastzitten terwijl het transport vrolijk probes beantwoordt.

TCPKeepAlive is een apart mechanisme een laag lager. De kernel regelt het, het is niet versleuteld, en een tegenpartij waarvan de SSH-daemon vastzit kan er nog steeds aan voldoen. Daarom is de probe op SSH-niveau het zinvolste signaal wanneer je om de sessie geeft en niet om de socket.

De volgorde bepaalt welke waarde overleeft

OpenSSH past de eerste waarde toe die het voor elke parameter krijgt, dus een specifiek Host-blok moet vóór elk breder blok staan dat ook zou passen. Zet standaardwaarden met jokertekens onderaan het bestand, niet bovenaan, en onthoud dat een Match-blok verderop een al ingestelde waarde niet kan overschrijven. De OpenSSH-referentie voor clientconfiguratie noemt de regel van de eerste waarde rechtstreeks, en het is de moeite waard die één keer te lezen voordat je een gedeelde configuratie herstructureert.

Opties op de commandoregel winnen van het bestand, wat een tijdelijk experiment goedkoop maakt:

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

Om te zien wat de client werkelijk heeft opgelost in plaats van wat je denkt dat je hebt geschreven, vraag je hem de effectieve configuratie te dumpen. De uitvoer bevat de samengevoegde waarden voor die hostnaam en is de snelste manier om een verdwaald eerder blok te pakken:

ssh -G office-shell | grep -i alive

Wat keepalives door een tunnel doen

Periodiek verkeer voorkomt dat een stateful NAT- of firewallmapping verloopt, wat een echt voordeel is op een VPN waarvan de gateway inactieve stromen na een paar minuten laat vallen. Probes die elke 60 seconden binnenkomen, verversen die mapping zonder toepassingsgegevens te dragen.

Ze kunnen een pad dat weg is niet opnieuw opbouwen. Als de tunnelinterface verdwijnt, falen de probes zoals al het andere, en de sessie eindigt zodra de telling op is. Het detecteren van leven en het herstellen van het pad zijn verschillende problemen, en alleen het eerste is configureerbaar in ssh_config. Wat het interval en de telling je echt opleveren, is hoe snel de client het merkt, en dat is het deel dat een gebruiker als een hang ervaart.

Gemeultiplext verbindingen voegen een plooi toe. Met ControlMaster in het spel horen de probes bij de hoofdverbinding, en een nieuwe sessie over een bestaande hoofdverbinding erft wat die hoofdverbinding heeft onderhandeld. Als de mux-hoofd vastzit, test een ander venster openen het pad niet opnieuw.

De instelling van begin tot eind bevestigen

Dump op de server de effectieve daemonconfiguratie in plaats van het bestand te lezen en te raden welke include heeft gewonnen:

sshd -T | grep -i clientalive

Kijk daarna naar een echte sessie met debug-uitvoer aan. De client drukt een time-outregel af wanneer de telling op is, en de tijdstempels eromheen laten zien of de stilte doorlopend was of de probes helemaal nooit zijn verstuurd. Een sessie die sterft zonder probe-verkeer heeft het sleutelwoord meestal in een blok dat nooit heeft gepast.

Twee controles zijn de moeite waard voor elke host die je alleen via een tunnel bereikt: bevestig dat het opgeloste interval het bedoelde is, en bevestig dat dat interval maal de telling korter is dan de idle-time-out op de VPN-gateway. Als het tweede getal groter is, laat de gateway de stroom eerst stil vallen en krijgt de SSH-probe nooit de kans iets te melden.