ServerAliveInterval SSH przez VPN: który koniec wysyła sondę?

Większość porad dotyczących utrzymania sesji SSH przy życiu kończy się na «dodaj ServerAliveInterval 30» i pomija użyteczne części. Słowem kluczowym jest timer po stronie klienta, który uruchamia się tylko wtedy, gdy kanał był cichy, liczy nieodebrane sondy, a nie sekundy, i mieszka w pliku, w którym wygrywa pierwsza pasująca wartość. Pomyl te trzy właściwości, a zdrowa sesja VPN i tak padnie, podczas gdy martwa będzie wisieć.

Dwa kierunki należą do różnych demonów

ServerAliveInterval czyta twój klient ssh. ClientAliveInterval czyta sshd po drugiej stronie i sonduje w przeciwnym kierunku, od serwera do klienta. Nie są aliasami i nie współpracują, więc ustawienie jednego nie wpływa na zachowanie drugiego końca. Mylenie ich to zwykła przyczyna tego, że poprawka wydaje się działać na jednym hoście, a na następnym nie.

Oba akceptują zero. Przy zerze klient nie wysyła zupełnie nic, a po stronie serwera ClientAliveCountMax równy zero wyłącza rozłączenie, które w przeciwnym razie nastąpiłoby po nieodebranych sprawdzeniach.

Co dowodzi sonda, a czego nie

Gdy minie ustawiony interwał, a z serwera nie napłyną żadne dane, klient wysyła małe żądanie istniejącym szyfrowanym kanałem i czeka na odpowiedź. ServerAliveCountMax określa, ile z nich może pozostać bez odpowiedzi, zanim sesja zostanie zerwana. Przy interwale 60 i liczbie 3 klient poddaje się po około trzech minutach ciszy, a ta liczba jest właściwością twojej konfiguracji, a nie standardem sieciowym. Zostaw interwał na domyślnej wartości 0, a żadna sonda nigdy nie zostanie wysłana, dlatego standardowy klient może siedzieć na martwym połączeniu bez końca.

Ponieważ wymiana odbywa się wewnątrz transportu SSH, odpowiedź dowodzi, że proces SSH drugiej strony nadal czyta i pisze. Nie mówi nic o programie, który uruchomiłeś w tej sesji: klient bazy danych, przekierowany port albo długo działający skrypt mogą być zablokowane, podczas gdy transport wesoło odpowiada na sondy.

TCPKeepAlive to osobny mechanizm o warstwę niżej. Obsługuje go jądro, nie jest szyfrowany, a strona, której demon SSH utknął, nadal może go spełnić. Dlatego sonda na poziomie SSH jest bardziej wymownym sygnałem, gdy zależy ci na sesji, a nie na gnieździe.

Kolejność decyduje, która wartość przetrwa

OpenSSH stosuje pierwszą wartość, jaką otrzyma dla każdego parametru, więc konkretny blok Host musi pojawić się przed każdym szerszym blokiem, który też by pasował. Wartości domyślne z symbolami wieloznacznymi umieść na dole pliku, nie na górze, i pamiętaj, że blok Match niżej nie może nadpisać już ustawionej wartości. Dokumentacja konfiguracji klienta OpenSSH wprost podaje zasadę pierwszej wartości, i warto ją przeczytać raz przed reorganizacją współdzielonej konfiguracji.

Opcje wiersza poleceń wygrywają z plikiem, co czyni tymczasowy eksperyment tanim:

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

Aby zobaczyć, co klient naprawdę rozwiązał, a nie co myślisz, że wpisałeś, poproś go o zrzut efektywnej konfiguracji. Wynik zawiera scalone wartości dla tej nazwy hosta i jest najszybszym sposobem na złapanie zbłąkanego wcześniejszego bloku:

ssh -G office-shell | grep -i alive

Co robią keepalive przez tunel

Okresowy ruch nie pozwala wygasnąć mapowaniu stanowego NAT lub zapory ogniowej, co jest realną korzyścią w VPN, której brama po kilku minutach wyrzuca nieaktywne przepływy. Sondy przychodzące co 60 sekund odświeżają to mapowanie, nie niosąc żadnych danych aplikacji.

Nie potrafią odbudować ścieżki, która zniknęła. Gdy interfejs tunelu znika, sondy zawodzą jak wszystko inne, a sesja kończy się, gdy licznik się wyczerpie. Wykrywanie życia i odzyskiwanie ścieżki to różne problemy, a w ssh_config można ustawić tylko pierwszy. To, co interwał i licznik naprawdę ci kupują, to szybkość, z jaką klient to zauważy, i właśnie to użytkownik odczuwa jako zawieszenie.

Połączenia multipleksowane dodają fałdę. Gdy w grze jest ControlMaster, sondy należą do połączenia głównego, a nowa sesja przez istniejące główne dziedziczy to, co wynegocjowało. Jeśli główne muxa utknęło, otwarcie innego okna nie sprawdzi ścieżki ponownie.

Potwierdzenie ustawienia od początku do końca

Na serwerze zrzuć efektywną konfigurację demona zamiast czytać plik i zgadywać, który include wygrał:

sshd -T | grep -i clientalive

Potem obserwuj prawdziwą sesję z włączonym wyjściem debugowania. Klient wypisuje wiersz przekroczenia czasu, gdy licznik się wyczerpie, a znaczniki czasu wokół niego pokazują, czy cisza była ciągła, czy sondy w ogóle nie zostały wysłane. Sesja, która umiera bez żadnego ruchu sond, zwykle ma słowo kluczowe w bloku, który nigdy nie pasował.

Warto dodać dwa sprawdzenia dla każdego hosta, do którego docierasz tylko przez tunel: potwierdź, że rozwiązany interwał jest tym zamierzonym, i potwierdź, że ten interwał pomnożony przez liczbę jest krótszy niż limit bezczynności na bramie VPN. Gdy druga liczba jest większa, brama najpierw po cichu wyrzuca przepływ i sonda SSH nigdy nie ma szansy nic zgłosić.