Tunelowana trasa domyślna na Cisco ASA: kiedy naprawdę obowiązuje

Użytkownik dostępu zdalnego nie dociera do niczego za ASA, podczas gdy ten sam serwer odpowiada na pingi z wewnętrznego LAN-u. Tunel się podnosi, klient dostaje adres z puli, a pakiet i tak wychodzi przez internetową trasę domyślną albo znika. Ten wzorzec zwykle oznacza, że odszyfrowany ruch nie znalazł własnej trasy i spadł na zwykłą trasę domyślną. Poprawką nie jest kolejna reguła NAT; poprawką jest tunelowana trasa domyślna.

Zacznij od objawu, nie od konfiguracji

Patrz, gdzie idzie pakiet, a nie gdzie się spodziewałeś, że pójdzie. Przechwycenie na interfejsie zewnętrznym podczas nieudanej sesji pokazuje odszyfrowany pakiet zmierzający do bramy ISP z nietkniętym jeszcze adresem z puli albo nie pokazuje nic, bo wyszukiwanie się nie powiodło. W obu przypadkach tunel nie jest problemem.

Tunel wygląda zdrowo w show vpn-sessiondb i właśnie dlatego ludzie wciąż debugują IKE.

Od odrzucenia przez ACL odróżnia to kierunek. Odrzucenie ACL jest logowane i liczone, a brakująca trasa daje niepowodzenie wyszukiwania bez pasującego wpisu. Uruchom show route dla celu klienta i przeczytaj, co ASA faktycznie wybrała, w tym czy wybrano trasę domyślną i którą.

Czym różni się wyszukiwanie tunelowane

Przewodnik Cisco po statycznym routingu na ASA 9.23 dokumentuje osobną trasę domyślną dla odszyfrowanego ruchu VPN, który nie ma trasy statycznej ani nauczonej. Słowo kluczowe tunneled oznacza tę trasę, więc odszyfrowany pakiet może spaść na inny następny skok niż ten, którego ASA używa do własnego transportu. Trasy bardziej szczegółowe nadal wygrywają, dlatego klient może dotrzeć przez wewnętrzną bramę do 10.0.0.0/8 i stracić wszystko inne.

Minimalny układ utrzymuje dwie trasy domyślne z różnymi następnymi skokami. Jedna niesie ruch samej ASA, druga niesie odszyfrowany ruch, który nie ma lepszej trasy. Oba następne skoki nadal muszą być osiągalne z interfejsu, do którego je podłączasz.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Jeśli obie trasy domyślne wskazują ten sam następny skok, słowo kluczowe nic nie zmienia, a objaw się nie przesunie.

Ograniczenia, które decydują, czy to zadziała

Ten sam przewodnik dopuszcza tylko jedną tunelowaną trasę domyślną i stwierdza, że ECMP nie jest dla niej obsługiwany, więc nie można rozkładać ruchu na tę ścieżkę. Wymienia też ograniczenia dotyczące śledzenia tras, weryfikacji ścieżki zwrotnej oraz niektórych przepływów inspekcji i zarządzania. Przeczytaj je w kontekście zainstalowanego wydania, zanim zaprojektujesz rozwiązanie wokół tej funkcji. Projekt, który je ignoruje, zwykle zawodzi w jednym konkretnym miejscu, a nie wszędzie, i dlatego objaw wygląda na przerywany.

Weryfikacja ścieżki zwrotnej to ta, która gryzie w projektach asymetrycznych. Jeśli odpowiedź przyszłaby innym interfejsem, niż oczekuje ASA, pakiet jest odrzucany, zanim routing zacznie mieć znaczenie. Napraw topologię lub ścieżkę powrotną, zamiast wyłączać weryfikację, by wymusić następny skok.

Śledzenie tras to osobna pułapka: śledzony obiekt zwykle chroni zwykłą trasę domyślną, a nie tunelowaną.

Czego słowo kluczowe nie robi

Nie wybiera adresu źródłowego, którego ASA używa do zbudowania IKE. Zewnętrzny punkt końcowy tunelu podlega własnemu wyborowi interfejsu i źródła platformy, a tunelowana trasa domyślna nie ma w tej decyzji udziału. Zmiana jej nie naprawi phase 1, który wychodzi z niewłaściwego adresu.

Nie zamienia też następnego skoku w proxy. Jeśli cel oczekuje wymiany HTTP CONNECT, wysyłanie surowych pakietów IP do hosta proxy daje tylko host, który ich nie routuje. Skonfiguruj zamiast tego mechanizm proxy obsługiwany przez klienta.

Nie tworzy też przekazywania w dół. Brama, na którą wskazujesz, nadal potrzebuje trasy powrotnej do puli VPN oraz tłumaczenia źródła tam, gdzie wymaga tego projekt.

Zweryfikuj ścieżkę od początku do końca

Gdy trasa jest już na miejscu, sprawdź po kolei cztery rzeczy: show route dla celu, którego potrzebuje pula, przechwycenie na interfejsie w stronę nowego następnego skoku, przechwycenie na samej bramie oraz ścieżkę powrotną z tej bramy do adresu z puli. Pierwsze dwie dowodzą, że ASA wybrała tę ścieżkę, a ostatnie dwie, że ktoś na niej odpowiada.

Jeśli brama odpowiada, ale klient nigdy nie widzi odpowiedzi, sprawdź tłumaczenie źródła i trasę powrotną, zanim ponownie dotkniesz tablicy routingu.

Zapisz wydanie, na którym weryfikowałeś, bo lista ograniczeń zależy od wersji, a projekt działający na jednej gałęzi może wymagać innej ścieżki na innej. Ta notatka żyje dłużej niż fragment konfiguracji.