Dlaczego zapytania TACACS+ samej AS-y omijają tunel VPN oddziału

Tunel oddziału działa, użytkownicy uwierzytelniają się na zdalnym serwerze TACACS+, a logowanie samej zapory nadal kończy się przekroczeniem czasu. Przyczyna nie jest błąd w tunelu: tunel LAN-to-LAN przenosi ruch zgodny z jego selektorami, a ruch zarządzający, który AS-a generuje o sobie, to osobny strumień z własnym adresem źródłowym. Większość zespołów odkrywa to podczas okna zmian, gdy jedyne konto administratora jest tym, które zawodzi. Traktuj sesję AAA inicjowaną przez AS-ę jak strumień, który trzeba zaprojektować, a nie jak efekt uboczny łączności, która już działa.

AS-a jest klientem, a jej własny ruch potrzebuje własnej ścieżki

Gdy zapora kontaktuje się z serwerem TACACS+, jest klientem jak każdy inny, z tym że nikt celowo nie skonfigurował dla niej trasy. Jej pakiety pochodzą z adresu interfejsu na urządzeniu, są generowane lokalnie, a nie przekazywane, i muszą być routowane, tłumaczone i chronione polityką dokładnie jak ruch użytkowników. Tunel między lokalizacjami, który chroni podsieć użytkowników, nie chroni automatycznie tego źródła zarządzania, ponieważ wybór ruchu opiera się na adresach, a nie na intencji.

Zapisz adres, który według ciebie zobaczy serwer. Jeśli nie potrafisz go podać w jednym zdaniu, nie masz jeszcze projektu.

Interfejs w wierszu aaa-server to nie ozdoba

W AS-ie wpis hosta aaa-server przyjmuje powiązanie z interfejsem w nawiasach, a dokumentacja poleceń hosta AAA firmy Cisco opisuje je jako interfejs, na którym znajduje się serwer uwierzytelniania. To właśnie to powiązanie wiąże zapytanie z interfejsem i z polityką, którą ten interfejs stosuje. Wybór według interfejsu wychodzącego do internetu albo pozostawienie tego, co zostało z ostatniej migracji, daje adres źródłowy, dla którego zdalny serwer i tunel nigdy nie były budowane.

inside jest poprawną odpowiedzią tylko wtedy, gdy wskazany interfejs ma adres, którego projekt zamierza użyć jako źródła. Na urządzeniu oddziału często tak jest; na urządzeniu z kilkoma segmentami prywatnymi może nie.

Zmiana powiązania oznacza odtworzenie wpisu

Ta sama dokumentacja opisuje ograniczenie edycji, które zaskakuje ludzi podczas przełączeń: zmiana interfejsu na istniejącym hoście wymaga usunięcia i odtworzenia wpisu hosta. Konfiguracja, która wygląda na edytowaną, może nie zostać zastosowana, a następna próba logowania i tak wyjdzie ze starego adresu. Zaplanuj to jako usunięcie i dodanie z kopią oryginalnego wpisu przed sobą, a nie jako poprawkę na miejscu.

Jeśli zdefiniowano kilka serwerów, zmień jeden i przetestuj go, zanim ruszysz pozostałe, aby jeden błąd nie zablokował wszystkich ścieżek administracyjnych naraz.

Sprawdź selektory, tłumaczenie i ścieżkę powrotną razem

Trzy rzeczy muszą się zgadzać, aby zapytanie dotarło. Selektory ruchu tunelu, albo ochrona interfejsu tunelu, jeśli jej używasz, muszą obejmować własne źródło AS-y i adres serwera; lista selektorów zbudowana dla podsieci użytkowników zwykle tego nie zrobi. Każda reguła NAT na ścieżce musi spójnie tłumaczyć to źródło, ponieważ serwer autoryzuje tożsamość urządzenia sieciowego obejmującą adres, który widzi. A ścieżka powrotna musi istnieć, co w tunelu opartym na politykach oznacza, że drugi koniec ma pasujący selektor w przeciwnym kierunku.

Po stronie serwera potwierdź osobno tożsamość urządzenia, wspólny sekret i politykę administracyjną. TACACS+ utrzymuje uwierzytelnianie, autoryzację i rozliczanie jako odrębne operacje, więc odmowa, która przychodzi po zakończonej wymianie, jest odpowiedzią polityki, a nie awarią transportu. Odczytanie jej jako problemu sieciowego kieruje cię w niewłaściwe miejsce.

Podczas debugowania trzymaj sekret poza przechwyceniami, zgłoszeniami i transkryptami, i pamiętaj, że adres źródłowy, który rejestruje serwer, to ten, który musi wyjaśnić twój projekt.

Wprowadź zmianę, nie zamykając sobie drogi

Używaj konsoli lub niezależnej ścieżki zarządzania podczas zmiany zdalnego uwierzytelniania administracyjnego, i utrzymuj zatwierdzony lokalny wariant zapasowy, dopóki nowa ścieżka nie przeniesie prawdziwego logowania. Potem weryfikuj wąsko: jeden serwer, jedno urządzenie, jedno udane uwierzytelnienie z adresem źródłowym obserwowanym po obu stronach.

Zapisz strumień na jego własnej stronie: interfejs i adres źródłowy, zdalny serwer, chroniona ścieżka oraz osoba odpowiedzialna za politykę autoryzacji. Wtedy późniejszą zmianę interfejsu lub tunelu można ocenić bez zgadywania, którego z dwóch strumieni dotyczy.