Zdalny SSH przez VPN: czego tunel nie robi
VPN udostępnia serwer SSH i nic więcej. Trzy warunki decydują, czy to właściwe rozwiązanie, a etap awarii wskazuje, która warstwa zawiodła.
VPN daje serwerowi SSH prywatną ścieżkę i usuwa potrzebę publicznego nasłuchu na porcie 22. Nie uwierzytelnia hosta, nie autoryzuje użytkownika ani nie decyduje, które konta mogą się zalogować. To nadal zadanie SSH. Czy VPN jest właściwym sposobem dotarcia do serwera, zależy od trzech warunków, a tunel jest tylko jedną z możliwych odpowiedzi.
Co zmienia tunel, a co nadal rozstrzyga SSH
Tunel zmienia osiągalność: które adresy są dostępne i skąd. Nie zmienia tego, co dzieje się po nawiązaniu połączenia TCP, gdzie serwer przedstawia klucz hosta i prosi o tożsamość użytkownika.
Trzymaj obie warstwy osobno w głowie i w dokumentacji. Logowanie do VPN dowodzi, kto może korzystać z sieci. Nie mówi nic o tym, jakie konta istnieją na serwerze docelowym, i nie jest zgodą na logowanie do każdej osiągalnej maszyny.
Sposoby awarii też są rozdzielone i właśnie dlatego rozdział jest przydatny podczas incydentu.
Trzy warunki, które decydują o modelu dostępu
Po pierwsze: czy serwer musi być osiągalny dla osób spoza twojej sieci? Jeśli nie, prywatna ścieżka plus bastion lub mesh to mniejszy projekt. Po drugie: czy grupa klientów faktycznie uruchomi klienta VPN, łącznie z tymi na zarządzanych urządzeniach z ograniczeniami?
Po trzecie: potrzebujesz kontroli na poziomie usługi czy użytkownika? VPN daje zasięg sieci; SSH daje dostęp do kont. Jeśli wymaganie brzmi, że wykonawca dociera do jednego hosta i nigdzie indziej, to wymaganie autoryzacyjne i sam tunel go nie wyrazi.
Odpowiedz na te trzy pytania, a model wybierze się sam. Pomiń je, a skończysz z publicznie wystawionym SSH, żeby uniknąć wdrożenia klienta.
Potwierdź prywatną ścieżkę, zanim obwinisz SSH
Połącz się z zatwierdzonym VPN i użyj udokumentowanej prywatnej nazwy lub adresu celu. Następnie sprawdź wybraną trasę, uprawnienie bramy i trasę powrotną do klienta. Nazwa, która poprawnie się rozwiązuje, nie jest dowodem, że adres idzie zamierzonym tunelem, bo nakładające się prefiksy lokalne i zdalne mogą wysłać żądanie zupełnie gdzie indziej. Warto zapisać tę różnicę w runbooku.
Jeśli połączenie nigdy nie powstaje, potwierdź, że serwer nasłuchuje na interfejsie, którego oczekujesz, i że jego firewall hosta dopuszcza źródło, które faktycznie widzi. NAT bramy może przepisać to źródło, więc lista dozwolonych napisana dla adresu tunelowego klienta może nigdy nie pasować.
Ta niezgodność to najczęstsza samodzielnie wyrządzona awaria SSH przez VPN.
Czytaj etap awarii, nie zbiorczy błąd
Trzy etapy dają trzy różne komunikaty i tylko jeden z nich dotyczy danych logowania.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
Użyj dokładnego błędu i własnego logu serwera, zamiast resetować naraz dane logowania do VPN i SSH. Resetowanie obu to sposób, w jaki pięciominutowa diagnoza staje się dwudniowym incydentem tożsamości.
Tryb szczegółowy pokazuje, na który etap dotarłeś:
ssh -vv [email protected]Zachowaj klucze hosta i autoryzację bez zmian
Zweryfikuj klucz hosta zamierzonym zaufanym procesem, zwłaszcza po wymianie serwera. Nieoczekiwane ostrzeżenie o zmienionym kluczu to komunikat, którego nie wolno odrzucić tylko dlatego, że VPN się połączył, bo prywatny tunel nie czyni celu maszyną, którą uważasz za właściwą. Sprawdź odcisk palca w źródle zaufanym niezależnie od połączenia.
Po stronie serwera potwierdź, że konto jest autoryzowane i że oferowana jest ta metoda uwierzytelniania, którą skonfigurowałeś. Klucz obecny, ale ignorowany, to zwykle problem uprawnień lub konfiguracji, a nie sieci.
Ogranicz dostęp do usług do wymaganych tożsamości i utrzymuj autoryzowaną ścieżkę odzyskiwania na wypadek zmian w sieci.