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?
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.