Pełny tunel zabił twoją sesję SSH: przypnij trasę powrotną

Uruchom OpenVPN klienta na maszynie, na której pracujesz przez SSH, i w połowie polecenia sesja zamarza. Tunel zgłasza połączenie, host dociera przez niego do internetu, a twoje naciśnięcia klawiszy nadal docierają, podczas gdy nic nie wraca. Zmieniło się nie tunel: to droga powrotna pakietów adresowanych do ciebie, która teraz pasuje do nowej trasy domyślnej i wchodzi w tunel, którego zdalna brama nie użyje, by dotrzeć do twojego biurka.

Co tak naprawdę instaluje redirect-gateway

W swojej def1 postaci redirect-gateway dodaje 0.0.0.0/1 i 128.0.0.0/1 zamiast nadpisywać trasę domyślną. Te dwie połowy pokrywają całą przestrzeń adresową, a obie pozostają dłuższymi prefiksami niż 0.0.0.0/0, więc każde miejsce docelowe bez bardziej szczegółowego dopasowania trafia teraz do tunelu. To mechanizm, który warto zapamiętać, bo każda poprawka poniżej działa przez zainstalowanie bardziej szczegółowego dopasowania.

Twój adres administracyjny jest jednym z tych miejsc docelowych.

Serwer VPN przekazuje ruch swoich klientów w stronę internetu. Nie ma trasy do publicznego adresu, z którego się łączysz, i nie ma powodu traktować tych pakietów inaczej niż ruchu przychodzącego od klienta, więc je odrzuca. Tymczasem wysłane przez ciebie żądanie i tak dotarło do hosta, i dlatego sesja wygląda na żywą tylko z jednej strony.

ip route show table main | head -n 20
ip route get 198.51.100.23

Znajdź swój adres źródłowy i drogę sprzed tunelu

Na serwerze wylistuj ustanowione połączenie SSH i zanotuj adres peera, z którego przyszło. To ten adres musi pokryć twoja trasa powrotna, i nie zawsze jest to ten, którego się spodziewasz: host przeskoku, brama NAT albo translator operatora mogą podstawić inne źródło.

Następnie znajdź fizyczną bramę i interfejs, które niosły ruch, zanim tunel się zaczął. W def1 układzie trasa domyślna nadal jest obecna pod połówkami trasy domyślnej, więc informacja jest dostępna, choć czytanie długiej tabeli tras na oko zaprasza błędy.

Zapisz obie wartości i nazwę interfejsu razem, bo trasa, którą zaraz dodasz, potrzebuje wszystkich trzech. Jeśli host używał reguły trasowania politycznego do wyboru łącza nadrzędnego, zwykła trasa może w ogóle nie zostać sprawdzona, a ta możliwość zmienia poprawkę.

Przypnij trasę do hosta, która bije połówki trasy domyślnej

Trasa /32 jest dłuższa niż każda z dwóch połówek trasy domyślnej, więc odpowiedzi na twój adres wybierają ją zamiast tunelu. Następny skok to brama sprzed tunelu, a urządzeniem jest fizyczny interfejs, co utrzymuje pakiet na drodze, której używał przed powstaniem tunelu.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Sprawdź zapytaniem, a nie oglądaniem tabeli: odpowiedź musi wymieniać eth0 i bramę, nigdy tun0.

OpenVPN już dodaje trasę do hosta pod własny adres serwera VPN z tego samego powodu, więc wzorzec jest znany, a adres administracyjny to po prostu kolejny wyjątek. Nie sięgaj po route-nopull , żeby to naprawić, bo odrzuca wypychane trasy potrzebne tunelowi, w tym sieć zdalną i opcje DNS.

Zadbaj, by przetrwało ponowne połączenie

Trasa dodana ręcznie znika, gdy klient łączy się ponownie i instaluje swoją, co zamienia poprawkę w nawracającą awarię. Podepnij polecenie do czegoś, co działa po zainstalowaniu tras.

Zarówno skrypt route-up jak i hak pre-up menedżera sieci działają, a wiarygodnym sprawdzeniem jest ponowne połączenie i to samo zapytanie.

W Windows odpowiednikiem jest trwała trasa dodana z -p, która przeżywa restarty, ale po zmianie sieci nadal musi wskazywać właściwą bramę. Niezależnie od platformy zapisz przyczynę obok trasy: następny administrator musi wiedzieć, że istnieje po to, by chronić sesję zarządzania, a nie dlatego, że wymagał tego projekt sieci.

Kiedy przypięta trasa wciąż nie wystarcza

Filtrowanie drogi powrotnej może odrzucić pakiet, który wchodzi jednym interfejsem, a wychodzi drugim, i dokładnie to tworzy przypięta trasa. Zanim cokolwiek wyłączysz globalnie, sprawdź efektywną wartość rp_filter , i wolij naprawić asymetrię niż wyłączać sprawdzanie. Stosuje się ustawienie dla interfejsu, a tryb loose często tylko rejestruje asymetrię zamiast odrzucać pakiet. Przeczytaj oba, zanim uznasz, że filtr jest twoją winą.

Hosty z trasowaniem politycznym potrzebują reguły obok trasy, bo baza reguł wybiera tabelę, zanim sprawdzona zostanie trasa w niej. Trasa w tabeli main jest niewidoczna dla przepływu pasującego do reguły wskazującej inną tabelę. Przeczytaj reguły, zanim cokolwiek dodasz do main. Jeśli reguła już obejmuje ruch zarządzania, wyjątek należy do tabeli tej reguły.

Podczas testów trzymaj otwartą konsolę poza pasmem i sprawdź ponownie z drugiego logowania, zanim odłączysz to, którego używasz. Trasa, która wysyła twój własny ruch zarządzania do tunelu, przecina połączenie, przez które ją naprawiasz. Powrót oznacza wtedy konsolę szeregową albo rozruch ratunkowy, co jest złą wymianą za pominięcie jednego kroku weryfikacji.