Failback na ASA: co naprawdę się przemieszcza, gdy trasa wraca
Powrót trasy na ścieżkę główną nie oznacza, że stare przepływy się przeniosły. Obserwujcie razem uplink, tunel, tablicę połączeń i wynik aplikacji.
Na ASA z dwoma uplinkami failback nie jest odwrotnością failover. Trasa do peera się zmienia, a potem platforma musi pogodzić trzy odrębne maszyny stanu: tablicę routingu, asocjacje bezpieczeństwa IKE i IPsec oraz tablicę połączeń. Każda może zostawać w tyle za pozostałymi i właśnie to opóźnienie większość ludzi opisuje jako tunel, który nie wraca.
Co failback naprawdę zmienia
Wyszukanie trasy to część widoczna. Gdy monitorowany obiekt wraca do zdrowia, monitorowana trasa do zewnętrznego adresu peera wraca, a następny pakiet wysłany przez ASA znów idzie łączem głównym. Wszystko potem zależy od tego, czy istniejący stan zgadza się z nową ścieżką.
ARP i NAT to ciche zależności. Nowy next hop potrzebuje rozwiązywalnej bramy i tłumaczenia, które nadal pasuje do drugiego końca, inaczej pierwsze pakiety po failbacku nie docierają nigdzie, a trasa wygląda dobrze, choć nic nie działa.
Cztery widoki na jednej osi czasu
Zapisujcie te same cztery rzeczy przed przejściem, w jego trakcie i po nim, bo jeden zrzut nie powie, która warstwa się poruszyła.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
Trasa, która nigdy się nie zmieniła, oraz trasa, która zmieniła się, gdy starsze połączenie zachowało swój stan przekazywania, dają tę samą skargę i zupełnie inne dowody.
Dlaczego stare połączenia zostają na ścieżce zapasowej
ASA nie zrywa przepływu dlatego, że zmieniła się trasa. Ustanowione połączenia zachowują decyzję o przekazywaniu, z którą zostały utworzone, a platforma oferuje osobne mechanizmy na to, jak długo jest to dozwolone: floating-connection timeout i connection holddown. przewodnik Cisco po ustawieniach połączeń w ASA 9.24 firmy Cisco traktuje je jako dwa różne pytania i dokładnie tak się one zachowują. Jedno rządzi przetrwaniem istniejącego przepływu, drugie tym, kiedy nowe przepływy mogą korzystać z preferowanej ścieżki.
Przeczytajcie wartości obowiązujące w waszej wersji, zanim zmienicie którąkolwiek z nich. Obniżenie ich zamyka sesje, których ludzie jeszcze używają. Podwyższenie sprawia, że failback wygląda, jakby nigdy nie nastąpił, bo nowe połączenia przez cały ten czas idą starą ścieżką.
Tunel nie negocjuje ponownie kluczy, bo wróciła trasa
Asocjacje bezpieczeństwa IPsec mają własny wynegocjowany czas życia i przeżywają zmianę trasy, która je niosła. Tunel może więc pozostać podniesiony podczas failbacku, choć jego adresacja zewnętrzna nie pasuje już do używanej ścieżki; to argument za DPD i za rozwiązaniami, które przypinają adres peera zamiast pozwalać mu pływać.
Projekty crypto-map i VTI zachowują się tutaj inaczej, a dokumentacja Cisco dla 9.24 VTI opisuje opcję opartą na trasach. Stare ogólne twierdzenie, że ASA nie potrafi uruchamiać VPN-ów opartych na trasach, nie obowiązuje w obsługiwanych wersjach.
Czytaj dowody w tej kolejności
Zacznijcie od płaszczyzny sterowania: show route dla wybranej ścieżki, show interface dla stanu łącza i liczniki monitora SLA dla monitorowanego obiektu. Potem przeczytajcie show crypto ikev2 sa, albo odpowiednik dla IKEv1, żeby zobaczyć, który peer żyje, a następnie show crypto ipsec sa dla przepływów chronionych. Następnie zawęźcie tablicę połączeń za pomocą show conn address <host> i porównajcie kolumnę interfejsu w starych i nowych wpisach. Zapisujcie wyniki z znacznikami czasu, bo ich kolejność jest diagnozą.
Zakończcie testem aplikacji: jeden przepływ, który już istniał, i jeden utworzony po powrocie trasy. Jeśli stary przepływ zawodzi, a nowy działa, macie historię stanu połączenia. Jeśli zawodzą oba, tunel albo polityka są błędne, a tablica połączeń to odwracanie uwagi.
Utrzymujcie ten zapis w tej samej formie we wszystkich trzech fazach i zanotujcie dokładną wersję. Gdy oś czasu stale wskazuje jedno przejście, wyślijcie zapis do wsparcia, zamiast zgadywać identyfikator błędu.