ServerAliveInterval fan SSH oer in VPN: hokker kant stjoert de probe?

It measte SSH-keepalive-advys hâldt op by »foegje ServerAliveInterval 30 ta« en lit de nuttige dielen weilitten. It kaaiwurd is in timer oan de kliïntkant dy't allinnich ôfgiet as it kanaal stil west hat, hy telt unbeantwurde probes yn stee fan sekonden, en hy libbet yn in bestân wêr't de earste oerienkommende wearde wint. Meitsje dy trije eigenskippen ferkeard en in sûne VPN-sesje falt dochs, wylst in deade hingjen bliuwt.

De twa rjochtingen hearre by ferskillende daemons

ServerAliveInterval wurdt lêzen troch jo ssh-klient. ClientAliveInterval wurdt lêzen troch sshd oan 'e oare kant en probet de oare kant út, fan tsjinner nei klient. It binne gjin aliassen en se wurkje net gear, dus it ynstellen fan de iene hat gjin effekt op it gedrach fan 'e oare kant. Se trochinoar helje is de gewoane reden dat in ferbettering op 'e iene host liket te wurkjen en op 'e folgjende net.

Beide akseptearje nul. By nul stjoert de klient hielendal neat, en oan 'e tsjinnerkant skeakelt in ClientAliveCountMax fan nul de ferbining út dy't oars op unbeantwurde kontrôles folgje soe.

Wat in probe bewiist, en wat net

Nei't it ynstelde ynterval foarby is sûnder dat der gegevens fan 'e tsjinner komme, stjoert de klient in lyts fersyk troch it besteande fersifere kanaal en wachtet op antwurd. ServerAliveCountMax stelt fêst hoefolle fan dy unbeantwurde bliuwe meie foar't de sesje ôfbrutsen wurdt. Mei in ynterval fan 60 en in teller fan 3 jout de klient it op nei likernôch trije minuten stilte, en dat sifer is in eigenskip fan jo konfiguraasje, gjin netwurkstandert. Lit it ynterval op syn standertwearde 0 en der wurdt nea in probe stjoerd, dêrom kin in standertklient ûnbeheind op in deade ferbining sitte.

Om't de útwikseling binnen it SSH-transport rint, bewiist in antwurd dat it SSH-proses fan 'e oare kant noch lêst en skriuwt. It seit neat oer it programma dat jo yn dy sesje start hawwe: in databankklient, in trochstjoerde poarte of in langrinnend skript kin fêstsitte wylst it transport lokkich probes beantwurdet.

TCPKeepAlive is in apart meganisme ien laach leger. De kearn behannelet it, it is net fersifere, en in tsjinpartij waans SSH-daemon fêstsit kin it noch altyd foldwaan. Dêrom is de probe op SSH-nivo it sinfolste sinjaal as jo om de sesje jouwe yn stee fan om 'e socket.

De folchoarder beslút hokker wearde oerlibbet

OpenSSH past de earste wearde ta dy't it foar elke parameter krijt, dus in spesifyk Host-blok moat foar elk breder blok komme dat ek passe soe. Set standertwearden mei wildcards ûnderoan it bestân, net boppe-oan, en tink derom dat in Match-blok fierder nei ûnderen in al ynstelde wearde net oerhearskje kin. De OpenSSH-referinsje foar klientkonfiguraasje neamt de regel fan 'e earste wearde direkt, en it is wurdich dy ien kear te lêzen foar't jo in dielde konfiguraasje op 'e nij yndiele.

Opdrachtline-opsjes winne fan it bestân, wat in tydlik eksperimint goedkeap makket:

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

Om te sjen wat de klient echt oplost hat yn stee fan wat jo tinke dat jo skreaun hawwe, freegje him de effektive konfiguraasje út te dumpen. De útfiere befettet de gearfoege wearden foar dy hostnamme en is de fluchste manier om in fertoarne earder blok te fangen:

ssh -G office-shell | grep -i alive

Wat keepalives oer in tunnel dogge

Periodyk ferkear hâldt in steatfol NAT- of firewall-kaart foar it ferrinnen, wat in echte winst is op in VPN wêrfan't de poarte inactive streams nei in pear minuten falle lit. Probes dy't elke 60 sekonden komme ferfarskje dy kaart sûnder applikaasjegegevens te dragen.

Se kinne gjin paad wer opbouwe dat fuort is. As de tunnelinterface ferdwynt, mislearje de probes lykas al it oare, en de sesje einiget sadree't de teller op is. Libbensdeteksje en paadherstel binne ferskillende problemen, en allinnich it earste is konfigurearber yn ssh_config. Wat it ynterval en de teller jo echt keapje, is hoe fluch de klient it merkt, en dat is it diel dat in brûker as in hingjen belibbet.

Multiplekse ferbiningen foegje in frommes ta. Mei ControlMaster yn it spul hearre de probes by de haadferbining, en in nije sesje oer in besteande haad erft wat dy haad úthannele hat. As de mux-haad fêstsit, sil it iepenjen fan in oar finster it paad net wer testen.

De ynstelling fan begjin oant ein befêstigje

Dump op 'e tsjinner de effektive daemonkonfiguraasje yn stee fan it bestân te lêzen en te rieden hokker include wûn hat:

sshd -T | grep -i clientalive

Sjoch dan nei in echte sesje mei debug-útfier oan. De klient printsje in rigel oer tiidferrin as de teller op is, en de tiidstimpels deromhinne litte sjen oft de stilte oanhâldend wie of de probes hielendal net stjoerd binne. In sesje dy't stjert sûnder probeferkear hat it kaaiwurd meastentiids yn in blok dat nea paste.

Twa kontrôles binne it wurdich ta te foegjen foar elke host dy't jo allinnich troch in tunnel berikke: befêstigje dat it oploste ynterval is wat jo bedoelden, en befêstigje dat dat ynterval fermannichfâldige mei de teller koarter is as de idle-timeout op 'e VPN-poarte. As it twadde getal grutter is, lit de poarte de stream earst stil falle en kriget de SSH-probe nea de kân om eat te rapportearjen.