SSH ServerAliveInterval VPN-i kohal: milline pool saadab kontrolli?

Enamik SSH-ühenduse elushoidmise nõuandeid lõpeb kohas «lisa ServerAliveInterval 30» ja jätab kasulikud osad välja. Märksõna on kliendipoolne taimer, mis käivitub ainult siis, kui kanal on vaikne olnud, see loeb vastamata jäänud kontrolle, mitte sekundeid, ja see elab failis, kus võidab esimene sobiv väärtus. Eksige nende kolme omaduse puhul ja terve VPN-seanss katkeb ikkagi, samal ajal kui surnud seanss jääb rippuma.

Kaks suunda kuuluvad eri deemonitele

ServerAliveInterval loeb teie ssh-klient. ClientAliveInterval loeb sshd kaugemas otsas ja kontrollib vastassuunas, serverist kliendi poole. Need ei ole aliased ja ei tee koostööd, seega ühe seadistamine ei mõjuta teise otsa käitumist. Nende segiajamine on tavaline põhjus, miks parandus tundub ühes hostis töötavat ja järgmises mitte.

Mõlemad aktsepteerivad nulli. Nulli korral ei saada klient üldse midagi, ja serveripoolses otsas lülitab null-väärtusega ClientAliveCountMax välja katkestuse, mis muidu vastamata kontrollidele järgneks.

Mida kontroll tõestab ja mida mitte

Kui etteantud intervall on möödunud ilma, et serverist andmeid saabuks, saadab klient olemasoleva krüpteeritud kanali kaudu väikese päringu ja ootab vastust. ServerAliveCountMax määrab, kui paljud neist võivad jääda vastamata enne seansi lõpetamist. Intervalli 60 ja loenduga 3 annab klient alla umbes kolme minuti vaikuse järel ning see arv on teie seadistuse omadus, mitte võrgustandard. Jätke intervall vaikeväärtusele 0 ja ühtegi kontrolli ei saadeta kunagi, mistõttu tavaline klient võib lõputult surnud ühenduse otsas istuda.

Kuna vahetus toimub SSH-transpordi sees, tõestab vastus, et teise poole SSH-protsess loeb ja kirjutab endiselt. See ei ütle midagi programmi kohta, mille te selles seansis käivitasite: andmebaasiklient, edasisuunatud port või pikalt töötav skript võivad olla kinni kiilunud, samal ajal kui transport rõõmsalt kontrollidele vastab.

TCPKeepAlive on eraldi mehhanism ühe kihi võrra allpool. Seda käsitleb tuum, see ei ole krüpteeritud ja vastaspool, mille SSH-deemon on kinni jäänud, suudab selle ikkagi täita. Seetõttu on SSH-tasandi kontroll sisukam signaal, kui hoolite seansist, mitte soklist.

Järjekord otsustab, milline väärtus jääb püsima

OpenSSH rakendab iga parameetri jaoks esimest saadud väärtust, seega konkreetne Host-plokk peab ilmuma enne ükskõik millist laiemat plokki, mis samuti sobiks. Pange metamärkidega vaikeväärtused faili lõppu, mitte algusesse, ja pidage meeles, et allpool olev Match-plokk ei saa enam määratud väärtust üle kirjutada. OpenSSH kliendi seadistuse viide sõnastab esimese väärtuse reegli otse, ja seda tasub üks kord lugeda enne jagatud seadistuse ümberkorraldamist.

Käsurea valikud võidavad faili üle, mis teeb ajutise katse odavaks:

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

Et näha, mida klient tegelikult lahendas, mitte seda, mida te arvate end kirjutanud olevat, laske tal väljastada kehtiv seadistus. Väljund sisaldab selle hostinime jaoks ühendatud väärtusi ja on kiireim viis tabada eksinud varasemat plokki:

ssh -G office-shell | grep -i alive

Mida elushoidjad tunnelis teevad

Perioodiline liiklus hoiab ära olekuga NAT-i või tulemüüri vastenduse aegumise, mis on tõeline kasu VPN-il, mille lüüs viskab tegevusetud vood mõne minuti järel välja. Iga 60 sekundi järel saabuvad kontrollid värskendavad seda vastendust ilma rakenduse andmeid kandmata.

Nad ei suuda taastada teed, mis on kadunud. Kui tunneliliides kaob, ebaõnnestuvad kontrollid nagu kõik muu, ja seanss lõpeb, kui loend on ammendatud. Elususe tuvastamine ja tee taastamine on eri probleemid ning ainult esimest saab ssh_config-is seadistada. Mida intervall ja loend teile tegelikult ostavad, on see, kui kiiresti klient seda märkab, ja just seda kasutaja kogeb hangumisena.

Multipksitud ühendused lisavad volti. Kui ControlMaster on mängus, kuuluvad kontrollid põhiühendusele ja olemasoleva põhiühenduse kaudu avatud uus seanss pärib selle, mida põhiühendus läbi rääkis. Kui mux-põhi on kinni, ei testi teise akna avamine teed uuesti.

Seadistuse kinnitamine otsast otsani

Serveris väljastage deemonile kehtiv seadistus, selle asemel et lugeda faili ja oletada, milline include võitis:

sshd -T | grep -i clientalive

Seejärel jälgige tõelist seanssi silumisväljundiga. Klient trükib ajalõpu rea, kui loend on otsas, ja selle ümber olevad ajatemplid näitavad, kas vaikus oli pidev või kontrolle ei saadetudki. Seanss, mis sureb ilma igasuguse kontrolliliikluseta, hoiab märksõna tavaliselt plokis, mis ei sobitunud kunagi.

Iga hosti jaoks, kuhu pääsete ainult tunnelit pidi, tasub lisada kaks kontrolli: veenduge, et lahendatud intervall on see, mida kavatsesite, ja veenduge, et see intervall korrutatuna loendiga on lühem kui VPN-lüüsi tegevusetuse ajalõpp. Kui teine arv on suurem, viskab lüüs voo kõigepealt vaikselt välja ja SSH-kontroll ei saa kunagi võimalust midagi teatada.