VPN między lokalizacjami działa, ale logi ASA nie docierają: sprawdź adres źródłowy

Wewnętrzne hosty docierają do zdalnego kolektora i ich linie syslog pojawiają się. Komunikaty samego ASA o tych samych sesjach nigdy nie docierają. Ani kolektor, ani tunel nie mają problemu, i właśnie to myli. Zapora wysyła swoje logi ze źródła, którego tunel nigdy nie miał chronić.

Co dociera, a co nie

Zacznij od rozdzielenia dwóch przepływów, które na pulpicie wyglądają identycznie. Ruch przekazywany przechodzi przez ASA: host LAN wysyła do kolektora, ASA dopasowuje to do polityki tunelu, szyfruje, a kolektor widzi adres hosta. Ruch generowany zaczyna się na samym ASA: urządzenie buduje pakiet syslog, wybiera interfejs wyjściowy i źródło, a dopiero potem pyta, czy pasuje jakakolwiek polityka tunelu. Pierwszy przepływ dowodzi, że tunel działa, i nic nie mówi o drugim.

Zdarzenie zbuforowane na urządzeniu też nie jest dowodem zdalnego dostarczenia, bo log może istnieć lokalnie i nigdy nie zostać wysłany. Sprawdź liczniki odbioru kolektora, zanim obwinisz tunel, bo pusty licznik to inne ustalenie niż rosnący.

Wygenerowany komunikat to nie ruch przekazywany

Gdy ASA sam tworzy pakiet, nie pośredniczy za host LAN. Źródło pochodzi z interfejsu wyjściowego lub z jawnego ustawienia źródła, a pakiet wchodzi w to samo wyszukiwanie trasy i te same kontrole polityki co wszystko inne, co wysyła urządzenie. To oznacza, że selektor VPN musi zawierać adres, którego ASA faktycznie używa, a to często jego interfejs zewnętrzny, a nie wewnętrzna podsieć.

Jeśli polityka chroni 10.20.0.0/24, a ASA używa jako źródła swojego adresu zewnętrznego, pakiet logu albo wychodzi jawnym tekstem w stronę kolektora, do którego nie może dotrzeć, albo jest odrzucany. Oba wyniki wyglądają identycznie od strony kolektora. To samo rozumowanie dotyczy ruchu zarządzania, dlatego management-access jest osobną decyzją projektową.

Które źródło ASA kładzie do sieci

Znajdź źródło empirycznie, a nie przez założenie. Przechwycenie na interfejsie wyjściowym podczas komunikatu testowego pokazuje rzeczywiste źródło i cel, i kosztuje mniej czasu niż czytanie trzech sekcji konfiguracji. Porównaj ten adres z lokalnym selektorem tunelu.

Niektóre wersje pozwalają przypiąć źródło logowania do interfejsu, a dokumentacja poleceń dla twojej wersji jest autorytetem co do tego, czy ta opcja istnieje i co zmienia. Polecenie source-interface z innej platformy Cisco nie jest automatycznie ważne na ASA.

Jeśli zmienisz źródło, zrób to świadomie i zapisz, bo listy ACL kolektora i każda korelacja oparta na syslog zależą od niego.

Dopasuj selektor do przepływu logów

Gdy źródło jest znane, sprawdź trzy rzeczy po kolei: ACL kryptograficzny lub selektor oparty na polityce, który decyduje, który ruch jest interesujący, trasę, która decyduje, dokąd trafia pakiet, oraz każdą regułę NAT, która może przepisać źródło przed szyfrowaniem. Pakiet zgodny z trasą, ale nie z selektorem, nie jest tunelowany, a pakiet przepisany przez NAT może nie pasować do żadnego z nich.

Strona kolektora ma własne wymagania: ACL zezwalający na źródło ASA, trasa powrotna i usługa nasłuchująca na porcie, który skonfigurowałeś. Transport też tu ma znaczenie, bo logowanie TCP i TLS zachowuje się inaczej niż UDP na częściowo zablokowanej ścieżce. Zmieniaj jeden element naraz, inaczej następne przechwycenie nie powie ci, która zmiana miała znaczenie.

Zweryfikuj u kolektora, a potem zapisz źródło

Potwierdź, że komunikat dociera, a następnie zapisz adres źródłowy, którego użył ASA, selektor, który go przeniósł, i poziom istotności, z którym testowałeś.

Ten zapis zamienia następną zmianę ACL kolektora lub edycję selektora w dwuminutowe sprawdzenie zamiast ponownego odkrywania. Dokumentuje też, który z dwóch przepływów został kiedykolwiek zweryfikowany, i właśnie tę część pomija większość runbooków. Jeśli komunikat nadal nie dociera, obniż tymczasowo próg istotności i testuj wobec jednego celu.

Dokumentacja FAQ dotyczących logowania ASA firmy Cisco opisuje przypadek ze źródłem zewnętrznym, który wymaga odpowiedniej definicji ruchu chronionego, a jego przykład ze źródłem wewnętrznym obejmuje zarówno host logowania po stronie wewnętrznej, jak i management-access po stronie wewnętrznej. Traktuj udokumentowaną kombinację i kontekst oprogramowania razem, zamiast zakładać, że jedna skopiowana linia pasuje do każdej konfiguracji.

Tunel, który przenosi ruch LAN, to nie tunel, który przenosi własny głos zapory.