Jakie są najlepsze praktyki migrowania konfiguracji ASA do wersji 8.3 i dalej?
Utworzyłem ręcznie nowy plik konfiguracyjny z następującymi zmianami:
Moim następnym krokiem byłoby uaktualnienie z wersji 8.2 do 8.3, odnotowując wszelkie błędy. Czy zamiast czyszczenia konfiguracji łatwiej byłoby wykonać to ponownie wiersz po wierszu?
Odpowiedzi:
Podaj wystarczająco krótki zestaw konfiguracji, ręczna zmiana konfiguracji powinna być dopuszczalną opcją. Możesz nawet wziąć istniejącą konfigurację i spróbować wdrożyć ją ponownie za pośrednictwem ASDM, aby zobaczyć, co zwraca nowy GUI.
Jeśli twoja konfiguracja składa się z wielu stron lub ma dużą liczbę obiektów, najlepiej zaimplementować ją w polu testowym, aby zobaczyć, co powraca jako komunikat o błędzie przed wprowadzeniem go do produkcji.
W przeciwieństwie do migracji z PIX-to-ASA, Cisco nigdy nie wypuściło narzędzia kontroli poczytalności.
Zdecydowanie zaleciłbym przebudowanie konfiguracji w celu jej wyczyszczenia. Często reguły są wprowadzane i stają się przestarzałe lub nigdy nie są używane. To idealna okazja, aby zacząć od nowa z czystym kontem.
Ostatnia aktualizacja, którą zrobiłem, zajęła około tygodnia, aby ponownie napisać zasady, ale były one znacznie czystsze i oznaczone.
Niedawno to przeszliśmy i przebudowałem konfigurację od zera. Moja konfiguracja miała tylko około 6 stron, więc nie była straszna. Umożliwiło to także pewną konsolidację w grupy obiektów i kontrolę reguł istniejących w ASA.
Jeśli twoja konfiguracja jest zbyt duża, możesz spróbować skonfigurować 8.2 w GNS3, stosując ją, a następnie aktualizując. Nigdy nie próbowałem aktualizacji ASA w GNS3, ale 8.2, 8.3 i 8.4 działały poprawnie w GNS3.
Inną opcją, jeśli masz parę Aktywny / Czuwanie, byłoby zerwanie pary podczas konserwacji i uaktualnienie Czuwania. Gdy wszystko się potwierdzi, ustaw je jako podstawowe i po ulepszeniu przenieś drugą jednostkę w tryb gotowości. Jeśli test się nie powiedzie, zmień na starszą jednostkę rezerwową i przywróć ją do starej pary.