Zachowaj lokalny SSH, gdy host używa wychodzącego VPN

Mały serwer Linux używa wychodzącego VPN dla hostowanej aplikacji, a administrator nadal chce się do niego dostać przez SSH z sąsiedniego biurka. To rozsądne wymaganie i zwykle nie wymaga ani przekierowania portów, ani adresu dostawcy, ani dziury w tunelu. Potrzebny jest natomiast szlak zarządzania zaprojektowany celowo, a nie odziedziczony po tym, co klient VPN zrobił z tabelą routingu.

Poniższe kroki zakładają, że administrator jest w tej samej sieci LAN.Zarządzanie zdalne to inny problem z inną odpowiedzią.

Powiąż SSH z adresem, którego używają administratorzy

Zacznij od nasłuchiwacza.ss -ltnp | grep :22 pokazuje, do czego jest przypisany sshd, a nasłuchiwacz na 0.0.0.0 przyjmuje połączenia z każdego interfejsu, także z tunelu. Powiązanie z adresem LAN jest węższe i czyni zamiar widocznym:ListenAddress 192.168.10.20 w sshd_config, a następnie test konfiguracji i przeładowanie. Literówka w tym adresie jest bardziej widoczna niż symbol wieloznaczny, ponieważ sshd odmawia startu, gdy adres nie istnieje.

Zachowaj sprawdzanie klucza hosta i uwierzytelnianie każdego użytkownika dokładnie takie, jakie są. „To tylko sieć lokalna” nie jest metodą uwierzytelniania, a kanał zarządzania, który pomija weryfikację klucza, bo trasa jest krótka, jest kanałem zarządzania czekającym na nadużycie. Rezerwacja DHCP lub adres statyczny czyni cel przewidywalnym, nie czyniąc go publiczną tożsamością serwera.

Trzymaj trasę LAN poza tunelem

Host z adresem w 192.168.10.0/24 ma trasę połączoną dla tego prefiksu, a bardziej szczegółowa trasa wygrywa z domyślną trasą VPN w tej samej tabeli. Dlatego lokalny SSH często działa dalej sam, gdy tunel się podnosi. Sprawdź to, zamiast zakładać:ip route get 192.168.10.50 nazywa interfejs i adres źródłowy, których użyłby kernel, a odpowiedzią powinno być urządzenie LAN, nie tunel. Powtórz sprawdzenie także z maszyny administratora, bo to jej własna tabela decyduje, czy pakiety w ogóle dotrą. Dwa hosty na tym samym kablu mogą się nie zgadzać, który kierunek jest osiągalny.

Założenie łamie się w dwóch miejscach. Reguła routingu opartego na polityce może wysłać ruch do tabeli, której trasa domyślna wskazuje do tunelu, zanim zostanie sprawdzona tabela główna. Klient VPN z funkcją blokady lub kill switch może także blokować ruch, który nie wchodzi do tunelu, niezależnie od tego, co mówi tabela routingu.

Routowane VLAN-y zarządzania to drugi przypadek. Jeśli administrator siedzi w 192.168.50.0/24 za lokalnym routerem, serwer potrzebuje jawnej trasy dla tego prefiksu przez 192.168.10.1, a ta trasa musi przetrwać ponowne połączenie. Trzymaj wyjątek konkretnie dla prefiksu zarządzania; szeroki wyjątek dla zakresów prywatnych niweczy cel tunelu.

Zrób wyjątek w zaporze tak wąski jak reguła

Jeśli host ma zaporę, zezwól na SSH tylko ze źródła zarządzania i tylko na interfejsie LAN. Reguła zezwalająca na port 22 zewsząd jest szersza niż wymaganie i trudniejsza do uzasadnienia w przeglądzie. Na hoście nftables reguła należy do łańcucha wejściowego z dopasowanym interfejsem i źródłem; na hoście iptables odpowiednikiem jest para dopasowań na -i i -s. Skomentuj regułę grupą administratorów, której służy, aby następny audyt nie musiał zgadywać, dlaczego port 22 jest otwarty.

Sprawdź też własny filtr klienta VPN. Niektóre klienty instalują reguły, które z założenia odrzucają lokalny ruch, a poprawna reguła zapory na odrzuceniu na poziomie klienta niczego nie zmienia. Przeczytaj konfigurację klienta, zanim zmodyfikujesz zaporę hosta, bo dwa filtry w szeregu dają awarię, która nie przypomina żadnego z nich.

Przetestuj oba stany

Wykonaj test dwa razy: raz z podłączonym tunelem i raz z odłączonym. W każdym stanie potwierdź nasłuchiwacz, trasę i rzeczywiste logowanie SSH z maszyny administratora. Ścieżka, która działa tylko wtedy, gdy tunel jest podniesiony, nie jest lokalną ścieżką zarządzania; to zbieg okoliczności.

Następnie uruchom tunel ponownie, gdy sesja SSH jest otwarta. Sesja, która przetrwa, dowodzi, że routing jest stabilny; sesja, która padnie, mówi ci, że klient przy ponownym połączeniu przepisuje trasy lub filtry, co warto wiedzieć przed incydentem, a nie w jego trakcie.

Zapisz adres źródłowy, z którego testowałeś, bo reguła napisana dla 192.168.10.50 zawodzi po cichu, gdy laptop administratora przeniesie się do innej podsieci.

Zapisz ścieżkę odzyskiwania w runbooku

Zdecyduj teraz, co się stanie, jeśli wychodzący VPN zepsuje lokalną ścieżkę. Dostęp przez konsolę, drugi adres zarządzania lub udokumentowana procedura zatrzymania klienta to wszystko uzasadnione odpowiedzi, a każda z nich jest lepsza niż odkrycie problemu w chwili, gdy trzeba się zalogować. Jeśli serwer jest zdalny, lokalna ścieżka nie istnieje, a właściwym rozwiązaniem jest osobna zatwierdzona trasa dostępu zdalnego lub bastion, a nie wystawiony publiczny port.

Trzymaj dwie role oddzielnie w dokumentacji: lokalny SSH dla administratora, który jest w pobliżu, i wychodzący tunel dla ruchu aplikacji. Gdy te role są zapisane, przyszła zmiana którejkolwiek z nich ma oczywiste miejsce sprawdzenia, a następna osoba nie musi od nowa odkrywać, dlaczego serwer z VPN nadal odpowiada na swoim adresie LAN.