Uruchamiasz klienta VPN przez SSH? Najpierw przypnij własną trasę

Łączysz się przez SSH z hostem budowania, uruchamiasz na nim klienta VPN, i sesja przestaje odpowiadać. Nic się nie zawiesiło i nic nie wygląda na źle skonfigurowane w oczywistym sensie. Klient zainstalował trasę domyślną, więc odpowiedzi do twojej stacji roboczej wychodzą teraz przez tunel, gdzie adres twojej stacji roboczej nie jest rutowalny. Ciekawe jest to, że ten wynik był przewidywalny, a poprawką jest jedna trasa zapisana przed startem klienta. Załóżmy serwer z jedną kartą sieciową, bramę 192.0.2.254 i administratora łączącego się z 203.0.113.9.

Zapisz ścieżkę, zanim zaczniesz

ip route show default wskazuje bieżącą bramę i interfejs, a ip route get 203.0.113.9 pokazuje, którego interfejsu i adresu źródłowego użyłoby jądro dla twojej sesji. Zachowaj oba wyniki. Po podniesieniu tunelu te dwa polecenia nadal powinny opisywać ścieżkę fizyczną, a jeśli opisują tunel, sesja już żyje na pożyczonym czasie.

Liczy się już nawiązane połączenie, więc nie weryfikuj tylko nowym logowaniem. Nowa sesja może na chwilę się udać dzięki stanowi, którego stara już nie ma.

Przypnij adres w konfiguracji samego klienta

Trasa dodana ręcznie znika po restarcie i ściga się z własnymi aktualizacjami tablicy klienta, więc umieść wyjątek tam, gdzie tablica jest zarządzana. W OpenVPN słowo kluczowe net_gateway rozwiązuje się do bramy, która istniała przed tunelem, więc route 203.0.113.9 255.255.255.255 net_gateway utrzymuje dokładnie jeden adres poza nim. WireGuard wymaga innego podejścia, bo wg-quick sam zarządza trasami: ustaw Table = off i dodaj wyjątek w PostUp, wraz z pasującym PostDown, który go usuwa. Obie formy wyrażają ten sam zamiar i obie ograniczają wyjątek do jednego adresu, zamiast osłabiać tunel dla wszystkiego.

Dla IPv6 ta sama idea bierze prefiks jednego hosta, a przypadek opakowanego transportu warto zapamiętać: jeśli zewnętrzne połączenie samego tunelu żyje pod stałym adresem, ten adres musi pozostać poza tunelem, który niesie, inaczej klient kieruje własny transport do siebie samego.

Albo wyjmij główną tablicę z równania

Gdy kilka usług na hoście musi zachować swoją normalną ścieżkę, przestań edytować główną tablicę i daj klientowi własną. Przestrzeń nazw sieci z parą veth robi to czysto: trasa domyślna klienta żyje w innym stosie i tylko procesy uruchomione w niej korzystają z tunelu. Routing polityczny dochodzi w podobne miejsce dla jednego celu, wysyłając pasujący ruch do dedykowanej tablicy, której domyślna trasa nadal wskazuje fizyczną bramę. Każde z podejść zostawia główną tablicę hosta bez nowej trasy domyślnej, i to właśnie ta właściwość utrzymuje SSH odpowiadający.

Oba są większą maszynerią niż jedna trasa do hosta i oba są warte zachodu, gdy więcej niż jedna rzecz na maszynie musi przetrwać tunel.

Załóż, że przypięcie może się nie udać

Trasa powiązana z twoim obecnym adresem publicznym psuje się w chwili, gdy dostawca przydzieli go ponownie. Zdalny serwer potrzebuje wtedy ścieżki, która nie zależy od tego adresu: konsoli, drugiego interfejsu zarządzania albo hosta przeskoku, który pozostaje poza tunelem.

Dwa zabezpieczenia kosztują dziesięć minut. Watchdog, który zatrzymuje klienta, jeśli w ciągu kilku minut nie pojawi się logowanie potwierdzające, zamienia zablokowanie w opóźnienie, a druga sesja SSH trzymana otwarta podczas zmiany dowodzi, że wyjątek działa, gdy tunel jest podniesiony. Same keepalive tu nie pomagają, bo ścieżka zniknęła, a nie jest bezczynna; czynią tylko śmierć łatwiejszą do zauważenia.

Weryfikuj w kolejności, która ma znaczenie

Podłącz tunel, potwierdź, że trasa do twojego adresu nadal wychodzi przez fizyczną bramę, a potem otwórz nową sesję. Jeśli nowa sesja działa, a stara mimo to ginie, przyczyną jest śledzenie połączeń lub zapora stanowa, a nie routing, co jest inną poprawką.

Zapisz przypięty adres i polecenie, które go dowiodło, w rejestrze zmian. Następna osoba, która uruchomi klienta na tym hoście, będzie potrzebować obu, a adres mógł się do tego czasu zmienić.