SSH do zdalnej ASA przez VPN oddziału: krok po kroku

Kierujesz klienta SSH na wewnętrzny adres zdalnej ASA i sesja ginie przy połączeniu. Zapora odpowiada z własnej lokalizacji, tunel się pojawia, a mimo to nic nie nasłuchuje na porcie 22. W większości takich przypadków pakiet nigdy nie dociera do dopuszczenia zarządzania, bo testowana ścieżka nigdy nie została zaprojektowana jako ścieżka zarządzania. Przejdź poniższy przepływ po kolei, a usterka przestanie się przenosić.

Wybierz adres, którym naprawdę zarządzasz

Trzy projekty wyglądają podobnie i zachowują się różnie: osiągnięcie publicznego adresu ASA skierowanego do VPN, osiągnięcie wewnętrznego interfejsu przez IPsec i osiągnięcie dedykowanego interfejsu zarządzania. Zapisz adres źródłowy administratora, dokładny adres docelowy i TCP 22, zanim dotkniesz jakiegokolwiek uprawnienia. Wszystko dalsze zależy od tej pary.

Tunel przenoszący dwie sieci VLAN serwerów może wcale nie przenosić adresu interfejsu zapory ani podsieci zarządzania administratora. Sprawdź listę ruchu interesującego dla polityki oddział-do-oddziału i potwierdź, że własny adres ASA występuje jako cel, a nie tylko podsieci przez niego przechodzące.

Ponieważ celem jest sama zapora, dopuszczenie zarządzania jest oddzielone od reguł ruchu przekazywanego. ACL, który wpuszcza klientów do serwerów za ASA, nie włącza samodzielnie administracji SSH urządzenia, a naprawa reguły przekazywania nie przesunie tej usterki.

management-access jest związany z interfejsem

Polecenie management-access mówi ASie, aby przyjmowała połączenia zarządzania do nazwanego interfejsu, gdy przychodzą przez VPN. Nie tworzy trasy, nie dodaje uprawnienia SSH i nie działa na wszystkich interfejsach naraz. Jeśli interfejs docelowy nie jest tym nazwanym, połączenie jest odrzucane przed uwierzytelnieniem.

Dwa wyjątki tu gryzą. Interfejsy tylko do zarządzania są poza tym mechanizmem, a przewodnik zarządzania ASA 9.20 zauważa, że domyślny stos CiscoSSH nie obsługuje SSH między interfejsami przez VPN, podczas gdy stos ASA SSH obsługuje. Potwierdź aktywny stos na wdrożonej wersji, zanim poświęcisz czas na trasy.

Cztery bramy przed monitem logowania

Między klientem a monitem o nazwę użytkownika stoją cztery niezależne bramy: zgodność trasy i tunelu dla pary zarządzania, ACL interfejsu zezwalająca na TCP 22 do adresu ASA, uprawnienie ssh obejmujące źródło administratora oraz uwierzytelnianie AAA dla tego użytkownika. Każda z nich może odrzucić pakiet, nie mówiąc klientowi, która brama się zamknęła.

Użyj packet-tracer, aby zobaczyć, która brama zawodzi, zanim cokolwiek zmienisz: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Ślad wskazuje ACL, etap NAT i decyzję to-the-box, co zwykle wystarcza, by oddzielić problem routingu od problemu dopuszczenia.

Napisz uprawnienie wąskie, nie szerokie

Ogranicz uprawnienie do zatwierdzonej podsieci administracyjnej i interfejsu odbierającego ruch tunelu: ssh 10.10.5.0 255.255.255.0 inside. Połącz je z metodą uwierzytelniania, taką jak aaa authentication ssh console LOCAL, i nazwanym kontem lokalnym, zamiast otwierać każde źródło na interfejsie zewnętrznym.

Utrzymuj spójność ACL interfejsu i uprawnienia ssh. Uprawnienie dla podsieci blokowanej przez ACL nadal zawodzi, a ACL zezwalająca na podsieć bez pasującego wpisu ssh zawodzi przy następnej bramie. Oba stwierdzenia opisują tę samą ścieżkę z różnych warstw, więc przejrzyj je razem w działającej konfiguracji.

Zweryfikuj z nazwanego hosta, potem znów zawęź

Otwórz nową sesję z nazwanego hosta zarządzania, a nie ze swojego biurka, i potwierdź na ASie, jakiego adresu źródłowego i interfejsu użyło połączenie. Sprawdź aktywne sesje i sekcję SSH działającej konfiguracji, gdy sesja jest otwarta, następnie ją zamknij i usuń wszelkie tymczasowe uprawnienie dodane do testów. Jeśli sesja się pojawia, ale spada zaraz po zalogowaniu, pozostałym problemem jest autoryzacja, a nie osiągalność. Zapisz interfejs i źródło w rejestrze zmian, aby następna osoba nie powtarzała diagnozy.

Utrzymuj konsolę lub inną niezależnie zatwierdzoną ścieżkę odzyskiwania dostępną przez całą zmianę. Gdy ścieżka prywatna zadziała, potwierdź, że publiczne źródła i niepowiązani użytkownicy VPN nie uzyskali tego samego dostępu, bo ścieżka zarządzania działająca dla wszystkich to inny problem niż ten, z którym zaczynałeś.