ServerAliveInterval SSH prin VPN: care capăt trimite sonda?

Majoritatea sfaturilor pentru menținerea vie a unei sesiuni SSH se opresc la «adăugați ServerAliveInterval 30» și lasă deoparte părțile utile. Cuvântul-cheie este un temporizator din partea clientului care se declanșează doar când canalul a fost liniștit, el numără sonde fără răspuns în loc de secunde, și trăiește într-un fișier în care câștigă prima valoare care se potrivește. Greșiți aceste trei proprietăți și o sesiune VPN sănătoasă tot cade, în timp ce una moartă rămâne atârnată.

Cele două direcții aparțin unor demoni diferiți

ServerAliveInterval este citit de clientul dumneavoastră ssh. ClientAliveInterval este citit de sshd de cealaltă parte și sondează în direcția opusă, de la server la client. Nu sunt aliasuri și nu cooperează, așa că setarea unuia nu are niciun efect asupra comportamentului celuilalt capăt. Confundarea lor este motivul obișnuit pentru care o corecție pare să funcționeze pe un host și nu pe următorul.

Ambele acceptă zero. La zero clientul nu trimite absolut nimic, iar pe partea de server un ClientAliveCountMax de zero dezactivează deconectarea care altfel ar urma verificărilor fără răspuns.

Ce dovedește o sondă și ce nu

După ce trece intervalul configurat fără să sosească date de la server, clientul trimite o cerere mică prin canalul criptat existent și așteaptă un răspuns. ServerAliveCountMax stabilește câte dintre ele pot rămâne fără răspuns înainte ca sesiunea să fie închisă. Cu un interval de 60 și un număr de 3 clientul renunță după aproximativ trei minute de liniște, iar acea cifră este o proprietate a configurației dumneavoastră, nu un standard de rețea. Lăsați intervalul la valoarea implicită 0 și nu se trimite niciodată vreo sondă, de aceea un client obișnuit poate sta la nesfârșit pe o conexiune moartă.

Deoarece schimbul se desfășoară în interiorul transportului SSH, un răspuns dovedește că procesul SSH al celeilalte părți încă citește și scrie. Nu spune nimic despre programul pe care l-ați pornit în acea sesiune: un client de bază de date, un port redirecționat sau un script de lungă durată pot fi blocate în timp ce transportul răspunde vesel la sonde.

TCPKeepAlive este un mecanism separat cu un strat mai jos. Este gestionat de kernel, nu este criptat, iar un capăt al cărui demon SSH este blocat îl poate satisface în continuare. De aceea sonda la nivel de SSH este semnalul mai semnificativ când vă interesează sesiunea, nu socketul.

Ordinea decide care valoare supraviețuiește

OpenSSH aplică prima valoare pe care o obține pentru fiecare parametru, așa că un bloc Host specific trebuie să apară înaintea oricărui bloc mai larg care s-ar potrivi și el. Puneți valorile implicite cu metacaractere la sfârșitul fișierului, nu la început, și rețineți că un bloc Match mai jos nu poate suprascrie o valoare deja stabilită. Referința de configurare a clientului OpenSSH enunță direct regula primei valori, iar aceasta merită citită o dată înainte de a reorganiza o configurație partajată.

Opțiunile din linia de comandă înving fișierul, ceea ce face ieftin un experiment temporar:

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

Pentru a vedea ce a rezolvat de fapt clientul, nu ce credeți că ați scris, cereți-i să descarce configurația efectivă. Ieșirea conține valorile fuzionate pentru acel nume de host și este cea mai rapidă cale de a prinde un bloc anterior rătăcit:

ssh -G office-shell | grep -i alive

Ce fac keepalive-urile printr-un tunel

Traficul periodic împiedică expirarea unei mapări NAT sau de firewall cu stare, ceea ce este un beneficiu real pe un VPN al cărui gateway aruncă fluxurile inactive după câteva minute. Sondele care sosesc la fiecare 60 de secunde reîmprospătează acea mapare fără a transporta date de aplicație.

Nu pot reconstrui o cale care a dispărut. Când interfața tunelului dispare, sondele eșuează ca orice altceva, iar sesiunea se termină odată ce numărul este epuizat. Detectarea vieții și recuperarea căii sunt probleme diferite, și doar prima este configurabilă în ssh_config. Ce vă cumpără de fapt intervalul și numărul este cât de repede observă clientul, iar aceasta este partea pe care utilizatorul o trăiește ca o blocare.

Conexiunile multiplexate adaugă o cută. Cu ControlMaster în joc, sondele aparțin conexiunii principale, iar o sesiune nouă peste una principală existentă moștenește ce a negociat acea principală. Dacă principala mux este blocată, deschiderea unei alte ferestre nu va testa din nou calea.

Confirmarea setării de la un capăt la altul

Pe server, descărcați configurația efectivă a demonului în loc să citiți fișierul și să ghiciți care include a câștigat:

sshd -T | grep -i clientalive

Apoi urmăriți o sesiune reală cu ieșirea de depanare activată. Clientul tipărește o linie de expirare când numărul se epuizează, iar marcajele de timp din jur arată dacă liniștea a fost continuă sau dacă sondele nu au fost trimise deloc. O sesiune care moare fără niciun trafic de sonde are de obicei cuvântul-cheie într-un bloc care nu s-a potrivit niciodată.

Merită adăugate două verificări pentru orice host la care ajungeți doar printr-un tunel: confirmați că intervalul rezolvat este cel dorit și că acel interval înmulțit cu numărul este mai scurt decât timpul de inactivitate de pe gateway-ul VPN. Când al doilea număr este mai mare, gateway-ul aruncă mai întâi fluxul în liniște și sonda SSH nu are niciodată ocazia să raporteze ceva.