SSH ServerAliveInterval през VPN: кой край изпраща проверката?

Повечето съвети за поддържане на SSH връзката жива спират до «добави ServerAliveInterval 30» и оставят полезните части настрана. Ключовата дума е таймер от страна на клиента, който се задейства само когато каналът е тих, той брои неотговорени проверки, а не секунди, и живее във файл, където първата съвпадаща стойност печели. Сбъркайте тези три свойства и здрава VPN сесия пак ще падне, докато мъртва ще виси.

Двете посоки принадлежат на различни демони

ServerAliveInterval се чете от вашия ssh клиент. ClientAliveInterval се чете от sshd от другата страна и проверява в обратната посока, от сървъра към клиента. Те не са псевдоними и не си сътрудничат, така че настройката на едното не влияе на поведението на другия край. Объркването им е обичайната причина поправка да изглежда работеща на един хост и да не работи на следващия.

И двете приемат нула. При нула клиентът не изпраща нищо изобщо, а от страна на сървъра ClientAliveCountMax нула изключва прекъсването, което иначе би последвало неотговорените проверки.

Какво доказва проверката и какво не

След като изтече зададеният интервал без данни от сървъра, клиентът изпраща малка заявка през съществуващия криптиран канал и чака отговор. ServerAliveCountMax определя колко от тях могат да останат без отговор, преди сесията да бъде прекъсната. При интервал 60 и брой 3 клиентът се отказва някъде след около три минути тишина и тази стойност е свойство на вашата конфигурация, а не мрежов стандарт. Оставете интервала на стойността по подразбиране 0 и никога няма да бъде изпратена проверка, поради което стандартен клиент може да стои на мъртва връзка безкрайно.

Понеже обменът тече вътре в SSH транспорта, отговорът доказва, че SSH процесът на отсрещната страна още чете и пише. Той не казва нищо за програмата, която сте стартирали в тази сесия: клиент на база данни, пренасочен порт или дълго работещ скрипт могат да са зациклили, докато транспортът спокойно отговаря на проверките.

TCPKeepAlive е отделен механизъм един слой по-надолу. Ядрото го обработва, не е криптиран и отсрещна страна, чийто SSH демон е заседнал, пак може да го удовлетвори. Затова проверката на ниво SSH е по-смисленият сигнал, когато ви е грижа за сесията, а не за сокета.

Редът решава коя стойност оцелява

OpenSSH прилага първата стойност, която получи за всеки параметър, затова конкретен блок Host трябва да се появи преди всеки по-широк блок, който също би съвпаднал. Сложете стойностите по подразбиране с шаблони в долната част на файла, не в горната, и помнете, че блок Match по-надолу не може да отмени вече зададена стойност. Справочникът за конфигурация на клиента OpenSSH посочва правилото за първата стойност пряко и си струва да се прочете веднъж, преди да пренаредите споделена конфигурация.

Опциите на командния ред надделяват над файла, което прави временния експеримент евтин:

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

За да видите какво всъщност е решил клиентът, а не какво мислите, че сте написали, накарайте го да изведе ефективната конфигурация. Изходът съдържа обединените стойности за това име на хост и е най-бързият начин да хванете заблуден по-ранен блок:

ssh -G office-shell | grep -i alive

Какво правят keepalive-ите през тунел

Периодичният трафик не позволява на NAT или защитна стена със състояние да изтече преобразуването, което е истинска полза при VPN, чийто шлюз изхвърля бездейните потоци след няколко минути. Проверките, пристигащи на всеки 60 секунди, обновяват това преобразуване, без да носят приложни данни.

Те не могат да възстановят път, който е изчезнал. Когато интерфейсът на тунела изчезне, проверките се провалят като всичко останало и сесията приключва, щом броят се изчерпи. Откриването на живост и възстановяването на пътя са различни проблеми и само първият се конфигурира в ssh_config. Това, което интервалът и броят всъщност ви купуват, е колко бързо клиентът забелязва, а точно това потребителят усеща като забиване.

Мултиплексираните връзки добавят подробност. При включен ControlMaster проверките принадлежат на главната връзка и нова сесия през съществуващ главен процес наследява каквото той е договорил. Ако главният mux е заседнал, отварянето на друг прозорец няма да тества пътя отново.

Потвърждаване на настройката от край до край

На сървъра изведете ефективната конфигурация на демона, вместо да четете файла и да гадаете кой включен файл е спечелил:

sshd -T | grep -i clientalive

След това наблюдавайте реална сесия с включен отладочен изход. Клиентът отпечатва ред за таймаут, когато броят се изчерпи, а времевите отпечатъци около него показват дали тишината е била непрекъсната, или проверките изобщо не са били изпращани. Сесия, която умира без трафик от проверки, обикновено държи ключовата дума в блок, който никога не е съвпаднал.

Две проверки си струва да добавите за всеки хост, до който стигате само през тунел: потвърдете, че решената стойност на интервала е тази, която сте искали, и че този интервал, умножен по броя, е по-кратък от таймаута за бездействие на VPN шлюза. Когато второто число е по-голямо, шлюзът първо тихо изхвърля потока и проверката на SSH изобщо не получава шанс да съобщи нещо.