SSH zrywa się na VPN co minutę? To nie keepalive

Sesja umierająca w powtarzalnym interwale zwykle traci stan firewalla, a nie keepalive. Prześledź oba kierunki, zanim dotkniesz MTU lub timerów.

SSH łączy się, działa około minuty, po czym za każdym razem zastyga w mniej więcej tym samym interwale. Typowe wyjaśnienie to timeout bezczynności, więc ludzie obniżają MTU i ustawiają keepalive po stronie klienta. Łącze WireGuard, nad którym pracowałem, miało już to wszystko za sobą: mniejsze MTU tunelu, ustawienia client-alive, skonfigurowany keepalive tunelu. Zerwania trwały bez zmian. Przyczyną okazała się asymetryczna trasa LAN, a ten wzorzec warto rozpoznać, bo pokonuje każde rozwiązanie oparte na timerach.

Keepalive dowodzi, że twój host nadal chce wysyłać. Nie może sprawić, by urządzenie utrzymujące stan zobaczyło odpowiedź, która nigdy przez nie nie przechodzi.

Mit: keepalive naprawiają ciche zerwanie

Keepalive SSH istnieją dla jednego zadania: powstrzymania czegoś, co liczy ciszę, przed usunięciem bezczynnej sesji. Robią to dobrze. Nie rozwiązują problemu urządzenia utrzymującego stan, które zobaczyło pierwszy pakiet w jednym kierunku, a potem nigdy nie zobaczyło odpowiedzi, bo nic, co wysyła klient, nie zmienia interfejsu używanego przez odpowiedź.

Zmiana MTU to drugie popularne rozwiązanie i ma ten sam tryb awarii. Obniżenie MTU pomaga przy fragmentacji i problemach z MTU ścieżki, a trasie nie robi nic. Jeśli twoje timery i MTU są już rozsądne, a zerwanie nadal występuje w powtarzalnym interwale, interwał mówi ci o timeoucie gdzieś, a nie o rozmiarze pakietu. Zapisz interwał i porównaj go z timeoutami stanu na każdym urządzeniu na ścieżce.

Sygnałem jest regularność w połączeniu z sesją, która pozostaje użyteczna w tym interwale. Timeouty bezczynności uderzają, gdy nic się nie dzieje; ten uderza, gdy piszesz.

Co naprawdę robi dodatkowa brama

Umieść laptopa i bramę VPN w tej samej sieci LAN, z osobnym firewallem LAN jako bramą domyślną. Laptop wysyła ruch kierowany do VPN do firewalla, firewall przekazuje go do bramy, i odpowiedzi bramy wracają prosto przez LAN do laptopa. Ta druga odnoga nigdy nie przechodzi przez firewall, więc jego tablica stanu trzyma połowę połączenia.

Poniższe adresy odzwierciedlają ten układ:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Przekierowania i obsługa stanu zamieniają wtedy działający handshake w połączenie, które umiera później, a nie od razu. Opóźnienie to starzenie się wpisu stanu lub niepowodzenie surowszej kontroli, dlatego interwał wygląda tak mechanicznie.

Nic z tego nie pojawia się w konfiguracji klienta, dlatego jego poszukiwanie zwykle zaczyna się w złym pliku.

Wybierz jedną świadomą ścieżkę

Dla powyższego układu routowanie zdalnej podsieci bezpośrednio do bramy VPN usuwa połowę połączenia:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

To adresy przykładowe. Następny skok musi być osiągalny w twojej sieci LAN, prefiks musi być zamierzoną siecią zdalną, a drugie polecenie pokazuje wynik, zanim na nim polegniesz. Jeśli brama nie jest w twojej podsieci, ta trasa nie jest poprawką, której chcesz.

Jeśli firewall ma pilnować ruchu między tymi systemami, routowanie wokół niego jest złym projektem. Zamiast tego pozwól obu kierunkom przekraczać granicę i skonfiguruj trasy po każdej stronie tak, aby droga powrotna się zgadzała. Celem jest jedna świadoma ścieżka, a nie mniej kontroli stanu.

notatki o routingu asymetrycznym firmy Netgate opisują tę samą asymetrię na poziomie interfejsu i problemy ze stanem, które tworzy, więc przeczytaj je, zanim globalnie poluzujesz obsługę stanu. Zerwania czasowe podobne do tego przypadku nie są same w sobie dowodem. Potraktuj artykuł jako opis jednego trybu awarii, a potem udowodnij, że twoja sieć do niego pasuje, zanim zmienisz globalną politykę stanu.

Przetestuj z obu końców

Przeczytaj trasę laptopa do celu i trasę celu z powrotem do laptopa; to dwie osobne decyzje i prawdopodobnie tylko jedna z nich jest błędna. Ping, który udaje się z samej bramy, może całkowicie ukryć problem, bo pochodzi z maszyny, której ścieżka jest już poprawna. Potrzebujesz obu kierunków tak, jak widzą je dwa końce rzeczywistej sesji.

Po poprawce otwórz ponownie SSH i trzymaj sesję otwartą znacznie dłużej niż interwał, który wcześniej zawodził. Następnie uczyń trasę trwałą w zatwierdzonej konfiguracji sieci, bo jednorazowe polecenie nie jest planem restartu, a problem wróci przy następnym restarcie z nową zagadką.

Kiedy asymetria jest w porządku

Routing asymetryczny jest normalny w wielu sieciach i nie jest zepsuty z definicji. Staje się problemem, gdy śledzenie stanu, translacja lub polityka zależą od widzenia ścieżki, której nie widzą, a każde z nich ma inne lekarstwo. Sprawdź, czego naprawdę wymaga urządzenie pośrednie, zanim przeprojektujesz wokół niego.

Trwała odpowiedź nazywa dwie ścieżki, urządzenie, które musi widzieć obie, i trasę, która to umożliwia. Jeśli nie potrafisz nazwać urządzenia, jeszcze nie znalazłeś przyczyny.

Powiązane artykuły