Identity NAT w ASA a wyjątek NAT w IOS dla ruchu VPN

Na bramach Cisco zarówno identity NAT w ASA, jak i wyjątek klasyfikatora NAT w IOS zachowują adresy VPN. Reguły różnią się tym, gdzie tłumaczenie jest pomijane.

Oddział utrzymuje PAT internetowy i VPN typu site-to-site na tej samej bramie Cisco, a VPN przestaje działać w chwili dodania NAT. Adresy wewnątrz tunelu nie pasują już do tego, co chroni crypto ACL, albo peer widzi przetłumaczone adresy, do których nie ma trasy. Cisco rozwiązuje to w dwóch miejscach: ASA wybiera regułę NAT mapującą adres na niego samego, a IOS trzyma przepływ poza regułą tłumaczenia dzięki deny w ACL. Oba zachowują oryginalne adresy i żaden nie jest obejściem przetwarzania NAT.

Zapisz przepływ, zanim wybierzesz regułę

Zacznij od zapisania przepływu, który chcesz chronić: źródło w LAN, zdalny cel i dokładna para adresów chroniona przez politykę IPsec. Zrób to przed edycją reguły, bo ten zestaw pokazuje, który klasyfikator lub która reguła NAT powinny były pasować.

Potem znajdź regułę, która faktycznie pasowała, a nie tę, którą zamierzałeś. Na obu platformach NAT jest oceniany w określonej kolejności i wcześniejsza reguła może wygrać, zanim twój wyjątek zostanie sprawdzony. Wyjątek, który wygląda poprawnie, ale przegrywa z inną regułą, nigdy nie przekaże oczekiwanego pakietu polityce ochrony. Objaw jest identyczny jak przy braku wyjątku, dlatego przed zmianą konfiguracji trzeba odczytać kolejność reguł.

Identity NAT w ASA to reguła, nie obejście

W ASA identity NAT to reguła NAT, której przetłumaczony adres jest równy oryginalnemu. Jest wybierana jak każda inna reguła i nadal instaluje wpis tłumaczenia, więc pakiet nie pomija przetwarzania NAT. Zmienia się tylko to, że adresy w sieci pozostają takie same, a tego właśnie potrzebuje polityka IPsec.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Interfejsy reguły i jej ustawienie route-lookup muszą odpowiadać projektowi przekazywania. Reguła, która poprawnie mapuje adres, ale jest stosowana do niewłaściwej pary interfejsów, nie zostanie wybrana dla twojego przepływu. Route-lookup decyduje, czy przetłumaczony pakiet jest routowany, czy używany jest oryginalny cel, i to rozstrzyga, czy ruch powrotny wróci przez tunel.

Dostęp zarządzający do samej ASA to osobny przypadek. Jeśli używasz identity NAT dla ruchu zarządzającego, obowiązuje wymóg route-lookup zależny od wersji, a szeroki wyjątek skopiowany z przykładu VPN nie naprawi SSH.

Deny w ACL NAT w IOS oznacza: tutaj nie wybrano

W IOS NAT internetowy jest sterowany listą źródeł, a ta ACL jest klasyfikatorem, nie filtrem. Wiersz permit wybiera ruch do tłumaczenia; wiersz deny oznacza, że pakiet nie został tutaj wybrany. Ten deny nie jest poleceniem odrzucenia pakietu, jak deny w ACL interfejsu.

Nie wybrano tutaj jest też węższe niż nigdzie nie tłumaczono. Inna reguła NAT, inny interfejs albo route-map nadal mogą tłumaczyć przepływ, więc trzeba przeczytać całą tabelę NAT. Pakiet nadal potrzebuje trasy, pasującej crypto ACL i zezwolenia na rzeczywistych granicach kontroli dostępu.

Minimalny układ w IOS umieszcza deny nad permit na tej samej liście i kieruje regułę overload na tę listę. Wtedy crypto ACL chroni tę samą parę, którą deny wyłącza z tłumaczenia.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Jedno sprawdzalne pytanie dla obu modeli

Oba modele odpowiadają na to samo pytanie: która reguła pasowała do tego przepływu i które adresy opuściły interfejs? Przechwyć na interfejsie zewnętrznym i porównaj adres źródłowy przed bramą i po niej. Następnie sprawdź widok tunelu po stronie peera, bo SA może być podniesione, gdy chroniony przepływ jest tłumaczony gdzie indziej.

W ASA pokaż nat detail i tabelę tłumaczeń; w IOS pokaż ip nat translations i odpowiednie liczniki ACL. Reguła, która nigdy nie rośnie, nigdy nie została wybrana, a to wskazuje na kolejność, interfejs lub kierunek, a nie na konfigurację crypto.

Gdzie konfiguracja zwykle się psuje

Typowe błędy są mechaniczne. Deny stoi pod permit i nigdy nie pasuje. Klasyfikator jest stosowany w złym kierunku, więc przepływ powrotny jest tłumaczony. Reguła identity obejmuje właściwe adresy, ale niewłaściwą parę interfejsów. Crypto ACL chroni podsieć, która nie odpowiada już temu, co prezentuje reguła NAT.

Zapisz oryginalną i prezentowaną parę adresów obok właściciela reguły, aby następny inżynier zobaczył, dlaczego klasyfikator odmawia tłumaczenia, podczas gdy firewall zezwala aplikacji. Trzymaj to w zgłoszeniu zmiany, nie w osobistej notatce. Potem uruchom przepływ ponownie po każdej zmianie NAT, bo kolejność reguł jest częścią konfiguracji, nawet gdy treść reguły się nie zmieniła. Tunel, który się podnosi, nie dowodzi, że adresy przetrwały; dowodzi tego tylko przechwycony pakiet i widok peera po dekapsulacji.

Powiązane artykuły