Jak modelować przepływ VPN za pomocą ASA packet-tracer

Packet-tracer na ASA odpowiada na wąskie pytanie: czy ten pakiet, wchodzący tutaj z tą krotką, byłby dozwolony i dokąd by trafił. Nie odpowiada, czy drugi koniec cokolwiek otrzymuje. Typowy błąd to podanie zewnętrznej krotki IKE, gdy tym, co chcesz przetestować, jest aplikacja jadąca wewnątrz tunelu. Najpierw popraw krotkę, przeczytaj fazy, a potem zdobądź rzeczywiste dowody na wszystko, czego symulator nie widzi.

Poniższy przegląd zakłada, że ACL, reguła NAT i kontekst tunnel-group są przed tobą. Bez nich wynik opisuje politykę, której nie możesz sprawdzić.

Krok 1: opisz przepływ wewnętrzny prostymi słowami

Opisz aplikację, zanim cokolwiek wpiszesz. Host po stronie wewnętrznej, który otwiera SSH do serwera za bramą zdalną, to jeden wewnętrzny przepływ TCP z konkretnym portem źródłowym. To ten przepływ oceniają ACL i filtr VPN, więc to ten przepływ wpisujesz.

Zapisz go jako zdanie, a następnie przetłumacz pole po polu:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Krok 2: wybierz interfejs wejściowy i kierunek

Wejście to interfejs, na którym pakiet przychodzi, a nie ten, przez który wychodzi. Dla hosta LAN, który inicjuje, to interfejs inside. Dla pakietu powrotnego tej samej sesji to interfejs outside, a krotka się odwraca. Wpisanie celu jako źródła to drugi najczęstszy sposób na uzyskanie przekonującego, ale nieistotnego ALLOW.

Porty też mają kierunek. Port usługi należy do pola celu w zainicjowanym żądaniu, a port efemeryczny klienta należy do pola źródła. Model z celem TCP 500 opisuje aplikację TCP nasłuchującą na 500; nie staje się testem IKE tylko dlatego, że liczba pojawia się w poleceniu.

Krok 3: czytaj fazy po kolei

Każda faza w wyniku to decyzja z właścicielem: wyszukanie trasy, ACL, NAT, potem wybór VPN lub tunelu. Czytaj je w wydrukowanej kolejności i zatrzymaj się na pierwszej fazie, która nie zgadza się z projektem.

NAT często zaskakuje. Jeśli przetłumaczone źródło wypada poza crypto ACL, które wybiera ruch dla tunelu, przepływ może zostać dozwolony i nigdy nie zostanie enkapsulowany. Ślad drukuje przetłumaczony adres, więc porównaj go z interesującym ruchem tunelu, a nie z adresem oryginalnym.

Krok 4: sprawdź, które obejścia wybrałeś

Forma detailed przyjmuje opcje pomijające kontrole, a Cisco dokumentuje opcję bypass-checks obejmującą ACL, filtr VPN, uRPF i kontrole podszywania się IPsec. ALLOW uzyskany z tymi obejściami mówi, że trasa i NAT by działały, a nie że polityka przepuściłaby rzeczywisty pakiet. Zapisz opcje obok wyniku.

Jeśli potrzebujesz odpowiedzi polityki, uruchom bez obejść. Jeśli izolujesz pytanie o routing, uruchom z nimi i oznacz wynik jako odpowiedź routingową.

Krok 5: domknij lukę rzeczywistą wymianą

Symulowane zezwolenie kończy się na ASA. To, czy brama zdalna odszyfrowała pakiet, czy serwer przyjął połączenie i czy wróciła odpowiedź, to osobne obserwacje. Użyj liczników punktów końcowych lub wąskiego przechwycenia na zatwierdzonej ścieżce.

Niektóre opcje trace i replay przesyłają pakiety lub zachowują stan. Postępuj zgodnie z udokumentowanym zachowaniem dla twojej wersji i zatwierdzonej procedury diagnostycznej, zamiast traktować każdy wariant jako wyszukiwanie tylko do odczytu.

Czego ślad nadal nie może ci powiedzieć

Trzymaj cztery rzeczy w jednej notatce: krotkę, pasującą regułę NAT, tunel lub politykę, która powinna nieść przepływ, oraz obserwację specyficzną dla kierunku. Bez nich późniejszy inżynier nie odróżni lokalnej decyzji polityki od ustalonej płaszczyzny sterowania i od działającej usługi. Pierwsza porażka po której następuje sukces, też nie dowodzi, że tunel musiał się w międzyczasie podnieść; zapisz fazę i zmianę stanu.

Zacznij od krotki wewnętrznej, zatrzymaj się na pierwszej fazie sprzecznej z projektem i dopiero wtedy sięgnij po dowody z punktów końcowych. Ślad jest wyrocznią polityki, nie potwierdzeniem dostarczenia.