SSH ServerAliveInterval oor 'n VPN: watter kant stuur die peiling?

Die meeste SSH-lewendhou-advies stop by »voeg ServerAliveInterval 30 by« en laat die nuttige dele uit. Die sleutelwoord is 'n kliëntkant-tydhouer wat net afvuur wanneer die kanaal stil was, dit tel onbeantwoorde peilings eerder as sekondes, en dit woon in 'n lêer waar die eerste ooreenstemmende waarde wen. Kry daardie drie eienskappe verkeerd en 'n gesonde VPN-sessie val steeds, terwyl 'n dooie een bly hang.

Die twee rigtings hoort by verskillende daemone

ServerAliveInterval word deur jou ssh-kliënt gelees. ClientAliveInterval word deur sshd aan die oorkant gelees en peil die ander rigting, van bediener na kliënt. Hulle is nie aliasse nie en werk nie saam nie, so om die een te stel het geen uitwerking op die gedrag van die ander kant nie. Om hulle te verwar is die gewone rede waarom 'n regstelling op een gasheer werk en nie op die volgende nie.

Albei aanvaar nul. Op nul stuur die kliënt glad niks, en aan die bedienerkant skakel 'n ClientAliveCountMax van nul die ontkoppeling af wat andersins op onbeantwoorde kontroles sou volg.

Wat 'n peiling bewys, en wat dit nie doen nie

Nadat die ingestelde interval verby is sonder dat enige data van die bediener af kom, stuur die kliënt 'n klein versoek deur die bestaande geënkripteerde kanaal en wag vir 'n antwoord. ServerAliveCountMax stel hoeveel van dié onbeantwoord mag bly voordat die sessie afgebreek word. Met 'n interval van 60 en 'n telling van 3 gee die kliënt op ná omtrent drie minute se stilte, en dié syfer is 'n eienskap van jou opstelling eerder as 'n netwerkstandaard. Laat die interval op sy verstekwaarde van 0 en geen peiling word ooit gestuur nie, wat is waarom 'n standaardkliënt onbepaald op 'n dooie verbinding kan sit.

Omdat die uitruiling binne die SSH-vervoer plaasvind, bewys 'n antwoord dat die eweknie se SSH-proses nog lees en skryf. Dit sê niks oor die program wat jy binne daardie sessie begin het nie: 'n databasis-kliënt, 'n deurgevoerde poort of 'n langdurige script kan vasgekeer wees terwyl die vervoer gelukkig peilings beantwoord.

TCPKeepAlive is 'n aparte meganisme een laag laer. Die kern hanteer dit, dit is nie geënkripteer nie, en 'n eweknie wie se SSH-daemon vasgehaak is, kan dit steeds bevredig. Dit is waarom die peiling op SSH-vlak die sinvoller sein is wanneer jy om die sessie gee eerder as om die sok.

Volgorde bepaal watter waarde oorleef

OpenSSH pas die eerste waarde toe wat dit vir elke parameter kry, so 'n spesifieke Host-blok moet voor enige wyer blok verskyn wat ook sou pas. Sit wildcard-verstekke onderaan die lêer, nie bo nie, en onthou dat 'n Match-blok verder af nie 'n waarde kan oorheers wat reeds gestel is nie. Die OpenSSH-kliëntopstellingsverwysing stel die eerste-waarde-reël reguit, wat dit werd is om een keer te lees voordat jy 'n gedeelde opstelling herorganiseer.

Opdragreël-opsies wen oor die lêer, wat 'n tydelike eksperiment goedkoop maak:

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

Om te sien wat die kliënt werklik opgelos het in plaas van wat jy dink jy geskryf het, vra dit om die effektiewe opstelling uit te gooi. Die uitset hou die saamgevoegde waardes vir daardie gasheernaam en is die vinnigste manier om 'n verdwaalde vroeëre blok te vang:

ssh -G office-shell | grep -i alive

Wat lewendhouers oor 'n tonnel doen

Periodieke verkeer hou 'n toestandvolle NAT- of vuurmuur-kaarte van verval, wat 'n werklike voordeel is op 'n VPN wie se poort onaktiewe strome ná 'n paar minute laat val. Peilings wat elke 60 sekondes aankom, verfris daardie kaarte sonder om enige toepassingsdata te dra.

Hulle kan nie 'n pad herbou wat weg is nie. Wanneer die tonnelkoppelvlak verdwyn, misluk die peilings soos alles anders, en die sessie eindig sodra die telling uitgeput is. Lewendheidbespeuring en padherstel is verskillende probleme, en net die eerste is in ssh_config opstelbaar. Wat die interval en telling werklik koop, is hoe vinnig die kliënt dit agterkom, en dit is die deel wat 'n gebruiker as 'n hang ervaar.

Gemultiplekse verbindings voeg 'n rimpel by. Met ControlMaster in die spel behoort die peilings aan die meesterverbinding, en 'n nuwe sessie oor 'n bestaande meester erf wat daardie meester beding het. As die mux-meester vasgekeer is, sal die oopmaak van nog 'n venster nie die pad weer toets nie.

Die instelling van begin tot end bevestig

Op die bediener, gooi die effektiewe daemon-opstelling uit eerder as om die lêer te lees en te raai watter insluiting gewen het:

sshd -T | grep -i clientalive

Kyk dan na 'n werklike sessie met ontfoutingsuitset aangeskakel. Die kliënt druk 'n tydverstrykingslyn wanneer die telling opraak, en die tydstempels daaromheen wys of die stilte aaneenlopend was of die peilings glad nooit gestuur is nie. 'n Sessie wat sterf sonder enige peilverkeer het gewoonlik die sleutelwoord in 'n blok wat nooit gepas het nie.

Twee kontroles is die moeite werd om by te voeg vir enige gasheer wat jy net deur 'n tonnel bereik: bevestig dat die opgeloste interval die een is wat jy bedoel het, en bevestig dat daardie interval vermenigvuldig met die telling korter is as die onaktiewe tydverstryking op die VPN-poort. Wanneer die tweede getal groter is, laat die poort die stroom eerste stilweg val en kry die SSH-peiling nooit 'n kans om iets te rapporteer nie.