SSH ServerAliveInterval VPN-en át: melyik vég küldi a próbát?

Az SSH-kapcsolat életben tartására adott tanácsok többsége ott áll meg, hogy «adja hozzá a ServerAliveInterval 30-at», és kihagyja a hasznos részeket. A kulcsszó egy kliensoldali időzítő, amely csak akkor lép működésbe, ha a csatorna csendes volt, a megválaszolatlan próbákat számolja a másodpercek helyett, és olyan fájlban él, amelyben az első egyező érték nyer. Ha ebben a három tulajdonságban téved, egy egészséges VPN-munkamenet is megszakad, míg egy halott függve marad.

A két irány különböző daemonokhoz tartozik

A ServerAliveIntervalt az ssh-kliense olvassa. A ClientAliveIntervalt a túloldali sshd olvassa, és az ellenkező irányban, a kiszolgálótól a kliens felé próbál. Nem álnevek, és nem működnek együtt, ezért az egyik beállítása nincs hatással a másik vég viselkedésére. Összekeverésük a szokásos oka annak, hogy egy javítás az egyik hoszton működni látszik, a következőn pedig nem.

Mindkettő elfogad nullát. Nullánál a kliens egyáltalán nem küld semmit, a kiszolgáló oldalán pedig a nulla ClientAliveCountMax kikapcsolja azt a bontást, amely egyébként a megválaszolatlan ellenőrzések után következne.

Mit bizonyít egy próba, és mit nem

Miután a beállított intervallum eltelik anélkül, hogy adat érkezne a kiszolgálótól, a kliens egy kis kérést küld a meglévő titkosított csatornán, és válaszra vár. A ServerAliveCountMax határozza meg, hogy ezek közül hány maradhat válasz nélkül, mielőtt a munkamenet megszakad. 60 intervallummal és 3 számmal a kliens körülbelül három perc csend után feladja, és ez a szám a saját beállításának tulajdonsága, nem hálózati szabvány. Ha az intervallumot az alapértelmezett 0 értéken hagyja, soha nem küld próbát, ezért egy szokásos kliens korlátlanul ülhet egy halott kapcsolaton.

Mivel a csere az SSH-szállítás belsejében zajlik, egy válasz bizonyítja, hogy a túloldali SSH-folyamat még olvas és ír. Semmit nem mond arról a programról, amelyet a munkameneten belül indított: egy adatbáziskliens, egy továbbított port vagy egy hosszan futó szkript is elakadhat, miközben a szállítás vidáman válaszol a próbákra.

A TCPKeepAlive egy külön mechanizmus egy réteggel lejjebb. A kernel kezeli, nincs titkosítva, és egy olyan vég, amelynek SSH-daemonja elakadt, még mindig kielégítheti. Ezért az SSH-szintű próba a jelentőségteljesebb jelzés, ha a munkamenet fontos Önnek, nem a socket.

A sorrend dönti el, melyik érték marad érvényben

Az OpenSSH az első kapott értéket alkalmazza minden paraméterre, ezért egy konkrét Host blokknak minden olyan szélesebb blokk előtt kell szerepelnie, amely szintén illeszkedne. A helyettesítő karakteres alapértékeket a fájl aljára tegye, ne a tetejére, és ne feledje, hogy egy lejjebb lévő Match blokk nem írhat felül egy már beállított értéket. Az OpenSSH klienskonfigurációs referenciája közvetlenül kimondja az első érték szabályát, és érdemes egyszer elolvasni, mielőtt egy megosztott konfigurációt átszervez.

A parancssori kapcsolók felülírják a fájlt, ami olcsóvá tesz egy ideiglenes kísérletet:

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

Ha látni akarja, mit oldott meg a kliens valójában, és nem azt, amit hisz, hogy írt, kérje meg, hogy dobja ki az érvényes konfigurációt. A kimenet az adott hosztnévhez összevont értékeket tartalmazza, és ez a leggyorsabb módja egy elkóborolt korábbi blokk elkapásának:

ssh -G office-shell | grep -i alive

Mit tesznek a keepalive-ok egy alagúton

Az időszakos forgalom megakadályozza egy állapotot követő NAT- vagy tűzfal-leképezés lejáratát, ami valódi előny egy olyan VPN-en, amelynek átjárója néhány perc után eldobja a tétlen folyamokat. A 60 másodpercenként érkező próbák frissítik ezt a leképezést anélkül, hogy alkalmazásadatot vinnének.

Nem tudnak újraépíteni egy eltűnt útvonalat. Amikor az alagút-interfész eltűnik, a próbák úgy meghiúsulnak, mint minden más, és a munkamenet véget ér, amikor a szám kimerül. Az életbenlét-érzékelés és az útvonal helyreállítása különböző problémák, és csak az első konfigurálható az ssh_config-ban. Amit az intervallum és a szám valóban megvásárol, az az, hogy milyen gyorsan veszi észre a kliens, és a felhasználó ezt akadásként éli meg.

A multiplexelt kapcsolatok egy redőt adnak hozzá. Ha a ControlMaster játékban van, a próbák a fő kapcsolathoz tartoznak, és egy meglévő fő kapcsolat fölötti új munkamenet örökli, amit az a fő kapcsolat kialkudott. Ha a mux fő kapcsolata elakadt, egy másik ablak megnyitása nem próbálja újra az útvonalat.

A beállítás ellenőrzése elejétől a végéig

A kiszolgálón dobja ki a daemon érvényes konfigurációját, ahelyett hogy a fájlt olvasná és találgatná, melyik include nyert:

sshd -T | grep -i clientalive

Ezután figyeljen meg egy valódi munkamenetet bekapcsolt hibakeresési kimenettel. A kliens kiír egy időtúllépési sort, amikor a szám kimerül, és a körülötte lévő időbélyegek megmutatják, hogy a csend folyamatos volt-e, vagy a próbákat egyáltalán nem küldték el. Egy próbaforgalom nélkül meghaló munkamenetben a kulcsszó általában olyan blokkban van, amely soha nem illeszkedett.

Két ellenőrzést érdemes hozzáadni minden olyan hoszthoz, amelyet csak alagúton keresztül ér el: erősítse meg, hogy a feloldott intervallum a szándékolt érték, és hogy ez az intervallum a számmal megszorozva rövidebb, mint a VPN-átjáró tétlenségi időtúllépése. Ha a második szám nagyobb, az átjáró előbb csendben eldobja a folyamot, és az SSH-próba soha nem kap esélyt, hogy bármit jelenthessen.