Zastąp starsze tagowanie VLAN przed SFOS 22 MR2

Interfejsy bridge w Sophos Firewall są przydatne, gdy istniejąca sieć warstwy 2 ma pozostać przezroczysta lub gdy migrację trzeba przeprowadzić bez natychmiastowej zmiany adresów IP. Jeśli wcześniej tagi VLAN skonfigurowano na bridge poleceniem system vlan-tag, przed aktualizacją do SFOS 22.0 MR2 lub nowszej wersji należy zastąpić je interfejsami VLAN w WebAdmin. Nie jest to zmiana kosmetyczna: w GA i MR1 może przestać działać ruch kierowany do firewalla lub przez niego generowany, a od MR2 starsza konfiguracja blokuje aktualizację.

Problem NC-181672 dotyczy interfejsów bridge z konfiguracją CLI VLAN tag w SFOS 22.0 GA i SFOS 22.0 MR1: ruch oznaczony VLAN pochodzący z Sophos Firewall lub kończący się na zaporze nie jest przetwarzany poprawnie. Może to na przykład wpływać na Active Directory, DNS, Device Access, STAS, LDAP, RADIUS lub dostęp do zarządzania, mimo że bridge nadal przekazuje normalny ruch.

Starsze tagowanie VLAN przez CLI jest przestarzałe: konfiguracja blokuje aktualizację do SFOS 22.0 MR2 lub nowszej wersji, a zawierającej ją kopii zapasowej nie można odtworzyć w SFOS 22.0 GA ani w wersji nowszej. Kontrolę należy więc wykonać przed aktualizacją i przed utworzeniem przeznaczonej dla niej kopii zapasowej. Artykuł Kontrola aktualizacji do SFOS 22 dokumentuje zweryfikowane wydanie docelowe MR2 Build 546, ścieżkę aktualizacji i inne blokady zależne od wersji. Jeśli planowany jest inny build docelowy, przed zmianą sprawdzić osobno ścieżkę aktualizacji i blokady obowiązujące dla tego buildu; danych MR2 nie wolno przenosić bez weryfikacji.

Ten artykuł nie jest ogólnym omówieniem sieci VLAN. Planowanie stref, interfejsów, sieci VLAN, Bridge i LAG warto zacząć od artykułu Konfiguracja stref i interfejsów w Sophos Firewall. Standardową konfigurację, zabezpieczenie i weryfikację opisuje Konfiguracja interfejsu Bridge w Sophos Firewall. Tutaj chodzi konkretnie o szczególny przypadek sieci VLAN na Bridge po aktualizacji do SFOS 22.

Kiedy ten temat jest istotny

Sprawdzenie ma sens, gdy łączy się kilka punktów:

• Zapora działa na SFOS 22.0 GA lub SFOS 22.0 MR1.
• Istnieje interfejs mostkowy, na przykład br0.
• Sieci VLAN były historycznie budowane przy użyciu konfiguracji tagów CLI VLAN, takiej jak system vlan-tag, lub zostały przejęte ze starej konfiguracji.
• Same usługi zapory sieciowej muszą osiągnąć tagowany VLAN.
• Po aktualizacji AD, DNS, uwierzytelnianie, monitorowanie lub dostęp do zarządzania działają tylko częściowo.
• Wydaje się, że normalny ruch klientów przez most nadal trwa.
• Planowana jest aktualizacja do SFOS 22.0 MR2 lub nowszej wersji albo jest ona blokowana przez legacy CLI VLAN tagging.

Punkt dotyczący nadal działającego ruchu klientów jest ważny: jeśli most będzie nadal przekazywał ruch między sieciami, początkowo problem nie będzie wyglądał na awarię mostu. W praktyce łatwo jest szukać w niewłaściwym miejscu, np. w regułach firewalla, DNS, STAS czy kontrolerze domeny.

Zrozum kierunek ruchu objętego problemem

Należy rozróżnić trzy rodzaje ruchu:

• Ruch przekazywany przez most: Klient w VLAN 100 rozmawia z serwerem w VLAN 100. To może nadal działać, ale nie dowodzi, że ruch do zapory działa.
• Ruch do zapory: Klient używa zapory jako serwera DNS lub miejsca docelowego WebAdmin. To właśnie ten ruch może zostać dotknięty, ponieważ kończy się na zaporze sieciowej.
• Ruch z zapory: Zapora wysyła zapytania do miejsc docelowych AD, DNS, LDAP, RADIUS, NTP lub Syslog. Jest to również istotne, ponieważ nadawcą jest sama zapora sieciowa.

Jeśli na dwóch hostach testowana jest tylko jedna aplikacja, nie można z całą pewnością zidentyfikować błędu. Test musi celowo obejmować usługę kończącą się na Sophos Firewall lub utworzoną przez zaporę ogniową.

Typowe objawy

Możliwe objawy to:

• Reguły oparte na użytkownikach nie działają już niezawodnie, ponieważ nie można uzyskać stabilnego dostępu do AD, STAS lub LDAP.
• Zapytania DNS kierowane do zapory sieciowej nie powiodły się z poszczególnych sieci VLAN.
• Ping lub HTTPS w lokalnych usługach zapory nie działa z VLAN, mimo że reguły zapory wyglądają wiarygodnie.
• Monitorowanie lub Syslog wydaje się niekompletne, jeśli zapora musi dotrzeć do celu w oznaczonym VLAN.
• Packet Capture pokazuje, że ruch pomiędzy systemami końcowymi jest widoczny, ale same usługi zapory ogniowej nie odpowiadają zgodnie z oczekiwaniami.
• Po aktualizacji SFOS-22 objawy występują bez świadomej zmiany czegokolwiek w przełączniku lub regułach zapory.

Takich symptomów nie należy natychmiast rozwiązywać za pomocą reguł szerokiego zezwolenia lub zatwierdzeń dostępu do urządzenia. Po pierwsze, musi być jasne, czy ma to wpływ na sam projekt interfejsu.

Szybkie rozgraniczenie przed konwersją

Przed przeniesieniem adresu IP mostu lub utworzeniem nowych interfejsów VLAN na moście należy zawęzić przyczynę. Nie każdy problem po aktualizacji jest automatycznie przypadkiem SFOS-22-Bridge-VLAN.

Klasyfikacja praktyczna:

• Tylko pojedyncza aplikacja między dwoma hostami nie działa: Bardziej prawdopodobne przyczyny to reguła zapory, NAT, system docelowy lub trasa powrotna. Najpierw przetestuj regułę zapory sieciowej i pod kątem upuszczeń przeanalizuj upuszczone pakiety.
• WebAdmin, DNS lub ping do zapory sieciowej z VLAN nie działa: Sprawdź Device Access, strefę, usługę lokalną lub most VLAN w specjalnym przypadku. Następnie osobno przetestuj ruch do zapory sieciowej.
• Zapora sieciowa nie osiąga AD, LDAP, RADIUS, DNS lub Syslog w VLAN: Sprawdź ruch z zapory, routingu, DNS lub mostu VLAN w specjalnym przypadku. Skorzystaj z testów bezpośrednio z konfiguracji firewalla i odpowiednich logów serwisowych.
• Działa normalny ruch klientów, ale usługi samej zapory sieciowej nie: Bardziej prawdopodobny staje się przypadek specjalny Bridge VLAN. Sprawdź projekt mostu, starą konfigurację znacznika CLI VLAN i interfejs VLAN dla mostu.
• W ogóle nie ma pasujących wpisów w dzienniku: Sprawdź rejestrowanie, filtr, usługę lokalną lub szczególny przypadek bridge/NAT, w którym ruch nie jest rejestrowany. Połącz Log Viewer, Packet Capture i odpowiednie Sophos Firewall dzienniki usług.

W przypadku problemów z DNS ważne jest również, czy klienci używają zapory sieciowej jako mechanizmu rozpoznawania nazw, czy też zapora sama korzysta z tras żądań DNS do serwerów wewnętrznych. Drugi przypadek dotyczy ruchu z zapory i może wyglądać inaczej niż normalny ruch klienta w przypadku problemów z mostem VLAN. Podstawy znajdziesz w Konfigurowanie tras żądań DNS na Sophos Firewall.

Jeżeli szybkie rozgraniczenie wyraźnie wskazuje na lokalne usługi firewalla lub ruch generowany przez firewall, to i tak warto zaplanować konwersję. Korekta mostu bez kopii zapasowej, okna konserwacyjnego i alternatywnej ścieżki dostępu jest zbyt ryzykowna dla produktywnych sieci.

Udokumentuj istniejący projekt

Przed wprowadzeniem zmian należy udokumentować aktualny stan. Szczególnie ważne są:

• Nazwa interfejsu mostu, na przykład br0.
• Członkowie mostu, tj. uczestniczące interfejsy fizyczne, sieci VLAN, interfejsy RED lub grupy LAG.
• Adres IP mostu, jeśli jest przypisany.
• Identyfikatory VLAN-ów przechodzących przez most.
• Profil portu przełącznika: Tagged VLAN, Native VLAN, Trunk lub port dostępowy.
• Usługi kończące się na firewallu: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Usługi, do których musi dotrzeć firewall: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Jeśli struktura pochodzi ze starej migracji, warto także sprawdzić, czy sieci VLAN zostały skonfigurowane poprzez konfigurację CLI. To właśnie o tym dziedzictwie często nie myśli się już, gdy zapora sieciowa jest aktualizowana jedynie przez lata.

⚠️ Nie należy spontanicznie eksperymentować z interfejsami mostowymi i sieciami VLAN podczas codziennych operacji. Nieprawidłowa zmiana może mieć wpływ na dostęp do zarządzania, DNS, uwierzytelnianie lub całe sieci klienckie. Przed korektą wymagana jest kopia zapasowa, okno serwisowe i alternatywna ścieżka dostępu.

Pułapki specyficzne dla bridge przed korektą

Przed zmianą należy dokładnie sprawdzić trzy ograniczenia bridge.

Po pierwsze: bridge bez adresu IP może odrzucać ruch, jeśli ruch pasuje do reguły zapory z filtrowaniem web proxy albo do reguły NAT. Takie odrzucenia nie są logowane. Jeśli reguła NAT nadal jest potrzebna, musi być zawężona tak, aby source translation dla bridge bez adresu IP pozostała ustawiona na Original. W przeciwnym razie można szukać w Log Viewer odrzucenia, którego tam nigdy nie będzie.

Po drugie: VLAN filtering na bridge dotyczy tylko ruchu bridged, a nie ruchu routowanego. Jeśli Filter VLANs jest włączone, ale nie wpisano dozwolonych VLAN IDs, tagowany ruch ze wszystkich VLANs jest odrzucany; ruch nietagowany jest z tego wyłączony. Podczas testów może to wyglądać jak niespójny problem VLAN.

Po trzecie: interfejsy bridge nie zastępują każdego projektu. Ograniczenia dotyczą Dynamic DNS, DHCP client, PPPoE i IPsec VPN. Jeśli jedna z tych funkcji jest częścią docelowego projektu, workaround bridge nie powinien być stosowany osobno; projekt interfejsów należy ponownie ocenić.

Utwórz obsługiwane interfejsy VLAN

Obsługiwany workaround polega na utworzeniu interfejsów VLAN w Network > Interfaces z interfejsem bridge jako interfejsem nadrzędnym. Interfejsami nadrzędnymi mogą być interfejsy fizyczne, RED, bridge i LAG.

Przed SFOS 18.0 polecenie system vlan-tag było wymagane do włączenia komunikacji tagowanej VLAN przez interfejsy bridge. Od SFOS 18.0 funkcjonalność VLAN-over-bridge jest w pełni dostępna w WebAdmin. Podczas inwentaryzacji i usuwania starszej konfiguracji należy jednak uwzględnić istotne ograniczenie: dokumentacja tagów VLAN dla SFOS 22 i 23 opisuje reset z argumentami wskazującymi interfejs jednocześnie jako wyświetlanie konfiguracji. Nie można z tego wywnioskować ani że samodzielne polecenie system vlan-tag show jest zapytaniem niezmieniającym konfiguracji, ani że system vlan-tag reset bez argumentów jest poleceniem usuwającym starszą konfigurację o znanym zakresie działania. Sama dostępność polecenia w danym kontekście CLI również nie potwierdza tych właściwości.

Przed każdą operacją CLI służącą do inwentaryzacji lub usuwania starszej konfiguracji należy na podstawie jednoznacznej dokumentacji dla zainstalowanego buildu lub przez Sophos Support potwierdzić dokładną metodę inwentaryzacji bez zmiany konfiguracji oraz obowiązującą składnię usuwania starszej konfiguracji. Potwierdzenie musi obejmować dokładny kontekst CLI, wymagane uprawnienia i argumenty, objęte operacją interfejsy lub węzły, a także skutki i zakres usuwania konfiguracji. Jeśli te kwestie nie zostały wyjaśnione, należy udokumentować wyłącznie stan widoczny w WebAdmin w Network > Interfaces i zatrzymać procedurę przed usuwaniem starszej konfiguracji lub aktualizacją. Brak wpisów w WebAdmin nie dowodzi, że starsze tagi CLI nie istnieją; nierozstrzygniętą kwestię inwentaryzacji należy wyjaśnić z Sophos Support, zamiast wypróbowywać domniemane polecenie wyświetlania lub resetowania.

Nowe lub uporządkowane projekty nie powinny już opierać się na system vlan-tag. Jeśli takie tagi CLI nadal istnieją, należy je udokumentować, przenieść do interfejsów VLAN w WebAdmin i dopiero potem kontynuować aktualizację firmware. Zmniejsza to zarówno specjalny przypadek mostu w SFOS 22, jak i późniejsze blokady aktualizacji.

Przykłady:

• VLAN 100: br0.100
• VLAN 200: br0.200

Podczas tworzenia VLAN w WebAdmin kluczowe są trzy pola: Interface musi być bridgem, Zone musi odpowiadać celowi bezpieczeństwa VLAN, a VLAN ID musi być unikalny. WebAdmin dopuszcza VLAN IDs od 1 do 4094; tego samego VLAN ID nie należy planować więcej niż raz na tym samym parent interface.

Proces zależy od tego, czy sam most ma już adres IP.

Jeśli most nie potrzebuje adresu IP

Jeśli most ma jedynie przekazywać w sposób przezroczysty, można go obsługiwać bez własnego adresu IP. Adres IP dla dotkniętego VLAN znajduje się wówczas w interfejsie VLAN, na przykład br0.100.

Praktyczny proces:

1. Wyeksportuj kopię zapasową do celów dokumentacyjnych, ale nie zakładaj, że będzie można jej użyć do wycofania zmiany w SFOS 22.
2. Udokumentuj bieżący mostek i konfigurację VLAN.
3. W Network > Interfaces wybierz Add interface > Add VLAN.
4. Wybierz most jako interfejs nadrzędny, na przykład br0.
5. Wprowadź identyfikator VLAN.
6. Wybieraj świadomie swoją strefę.
7. Ustaw adres IP na interfejsie VLAN, jeśli firewall ma być bramą lub udostępniać lokalną usługę w tym VLAN-ie.
8. Sprawdź Device Access dla strefy.
9. Sprawdź reguły zapory sieciowej i reguły NAT.
10. Sprawdź zmianę na kliencie testowym i utwórz nową kopię zapasową dopiero po pomyślnym zakończeniu testów.

Strefa to nie tylko porządek w WebAdmin. Ta decyzja ma wpływ na reguły zapory sieciowej, Device Access, dzienniki i wiele późniejszych kroków rozwiązywania problemów. Jeśli VLAN ma służyć jako sieć zarządzająca, serwerowa lub kliencka, powinno to być widoczne w strefie.

Jeśli most miał wcześniej produktywny adres IP

Jeżeli most obecnie korzysta z adresu IP, który w przyszłości musi być dostępny w VLAN, należy zachować szczególną ostrożność. Istnieją dwa czyste warianty konwersji: most otrzymuje inny adres IP lub most pozostaje bez adresu IP. Poprzedni adres produkcyjny jest następnie przypisywany do interfejsu VLAN.

Jest to zmiana obarczona ryzykiem niepowodzenia. Warto wcześniej wyjaśnić:

• Z jakiego adresu można dotrzeć do WebAdmin?
• Którzy klienci używają zapory sieciowej jako domyślnej Gateway?
• Które ustawienia DNS lub DHCP wskazują na ten adres?
• Jakie zasady dostępu do urządzeń obowiązują w poprzedniej strefie?
• Czy istnieje drugi dostęp do zarządzania z sieci, której to nie dotyczy?

W przypadku odległych lokalizacji nie należy planować tej zmiany bez lokalnej ścieżki powrotnej. Jeśli dostęp do WebAdmin i SSH odbywa się właśnie przez adres IP bridge objęty zmianą, błąd może przerwać dostęp administracyjny.

Usuń starszą konfigurację i przygotuj aktualizację

Kolejność ma kluczowe znaczenie: po wyjaśnieniu opisanych powyżej kwestii należy najpierw utworzyć wszystkie potrzebne interfejsy VLAN w Network > Interfaces, wskazując bridge jako Parent Interface, w razie potrzeby przenieść dotychczasowy adres IP bridge na odpowiedni interfejs VLAN oraz sprawdzić nową ścieżkę ruchu danych i zarządzania. W środowisku HA należy wcześniej za pomocą obsługiwanego widoku stanu upewnić się, że węzeł peer i synchronizacja działają prawidłowo, oraz wykonać kopię zapasową każdego węzła w zakresie przewidzianym przez platformę i procedury wsparcia. Jeśli stan węzła peer lub synchronizacji wskazuje na błąd albo jest niejasny, należy zatrzymać procedurę przed usuwaniem starszej konfiguracji lub aktualizacją i eskalować problem. Nie należy wymyślać poleceń HA ani synchronizacji.

Dopiero gdy mapowanie jest udokumentowane, alternatywny dostęp jest aktywny i wszystkie warunki HA są spełnione, można usunąć starsze ustawienie metodą potwierdzoną dla zainstalowanego buildu w dokumentacji lub przez Sophos Support. Potwierdzenie dokładnej składni, kontekstu CLI, skutków oraz zakresu obejmującego interfejsy i węzły musi być dostępne przed wykonaniem operacji; ten artykuł nie dopuszcza do wykonania polecenia reset bez określenia warunków jego użycia. Jeśli brakuje potwierdzenia, należy ograniczyć się do inwentaryzacji w WebAdmin i zatrzymać procedurę przed usuwaniem starszej konfiguracji lub aktualizacją.

Następnie należy za pomocą metody inwentaryzacji wcześniej potwierdzonej jako niezmieniająca konfiguracji sprawdzić, czy starsze ustawienie zostało usunięte w zamierzonym zakresie. Same testy ruchu tego nie dowodzą. Jeśli starsza konfiguracja nadal jest widoczna, jej usunięcie nie powiedzie się lub stan konfiguracji jest niejednoznaczny, należy zatrzymać procedurę: nie rozpoczynać jeszcze aktualizacji i nie zatwierdzać nowej kopii zapasowej jako punktu odtwarzania wolnego od starszej konfiguracji. Należy zachować zebrane dane z inwentaryzacji, ewentualne wyniki poleceń, wyniki kontroli wstępnej aktualizacji i bieżącą konfigurację oraz eskalować problem do Sophos Support; nie należy wypróbowywać nieudokumentowanych poleceń CLI.

Ze sprzecznego opisu resetu nie można również wywnioskować niezawodnej metody wycofania operacji na poziomie poleceń. Pomyślne wyniki inwentaryzacji i testów ruchu potwierdzają usunięcie starszej konfiguracji, a nie możliwość wycofania operacji. Po usunięciu starszego ustawienia nie należy tworzyć go ponownie za pomocą zgadywanego polecenia. Jeśli zmianę trzeba wycofać, należy zatrzymać procedurę i zaangażować Sophos Support w odtworzenie zatwierdzone przez producenta na pierwotnej, obsługiwanej wersji firmware; zmiany w WebAdmin należy cofać wyłącznie w ramach tego zatwierdzonego planu.

Jeśli testy odbiorcze i ponowna inwentaryzacja zakończą się pomyślnie, należy utworzyć nową kopię zapasową, powtórzyć kontrolę wstępną aktualizacji i dopiero wtedy zaktualizować system do SFOS 22.0 MR2 lub nowszej wersji. Aby uzyskać stan możliwy do odtworzenia w przyszłości, obowiązuje ta sama potwierdzona procedura usuwania starszej konfiguracji: usunąć starsze ustawienie na firewallu źródłowym, w razie potrzeby utworzyć interfejs VLAN z bridge jako Parent Interface, sprawdzić konfigurację i dopiero potem utworzyć nową kopię zapasową. Nie naprawia to starej kopii zapasowej zawierającej system vlan-tag.

Sprawdź Device Access i reguły firewalla po zmianie

Po utworzeniu interfejsu VLAN nie wystarczy po prostu przetestować adres IP. Reguły Device Access i zapory muszą pasować do nowego interfejsu i projektu strefy.

Aby sprawdzić:

• Administration > Device access: Czy usługi Ping/Ping6, DNS, HTTPS, SSH, User Portal lub VPN Portal są dozwolone tylko w odpowiednich strefach?
• Rules and policies > Firewall rules: Czy istnieją zasady dotyczące nowej strefy?
• Rules and policies > NAT rules: Czy ruch jest tłumaczony nieoczekiwanie?
• Network > DNS lub trasy żądań DNS: Czy zapora sieciowa dociera do właściwych serwerów DNS lub AD?
• Authentication > Servers: Czy AD, LDAP lub RADIUS będą dostępne po zmianie? W przypadku lokalnych usług zapory ogniowej odpowiednim, szczegółowym artykułem jest Device Access bezpieczna konfiguracja Sophos Firewall. Sophos Firewall Testuj regułę z Log Viewer i Packet Capture pomaga w analizie reguł.

Walidacja po korekcie

Czysty test powinien zawierać więcej niż jeden sygnał ping.

Test z VLAN-u objętego problemem

Z klienta w VLAN-ie objętym problemem:

1. Sprawdź osiągalność bramy domyślnej.
2. Przetestuj adres IP firewalla na nowym interfejsie VLAN za pomocą polecenia ping, jeśli jest to dozwolone.
3. Przetestuj DNS na zaporze, jeśli zapora służy jako narzędzie do rozpoznawania nazw DNS.
4. Testuj WebAdmin lub portal tylko z dozwolonych sieci zarządzających.
5. Sprawdź typowe połączenie aplikacji lub serwera.
6. Sprawdź w Log Viewer właściwy identyfikator reguły i strefę.

Testuj z zapory sieciowej

Oddzielne testy są wymagane dla ruchu generowanego przez samą zaporę:

• Przetestuj serwery AD lub LDAP w Authentication > Servers.
• Sprawdź rozwiązywanie nazw DNS przez firewall.
• Sprawdź NTP, Syslog lub cel monitorowania, jeśli te usługi znajdują się w VLAN.
• W Diagnostics > Packet capture sprawdź interfejs VLAN. Generated oznacza pakiety utworzone przez firewall, a Consumed pakiety przeznaczone dla niego; porównaj też In interface, Out interface, Rule ID, Status i Reason.

Jeśli ma to wpływ na STAS lub reguły oparte na użytkownikach, należy również sprawdzić instrukcję Konfiguracja STAS na Sophos Firewall. Przy aktualizacjach do SFOS 22 ten punkt należy również do kontroli aktualizacji SFOS 22.

Powrót i zakończenie

Przed zmianą należy zapisać dotychczasowy adres IP bridge, strefę, identyfikatory VLAN, konfigurację portów przełącznika oraz zależne reguły i usługi. Potrzebny jest również alternatywny lub lokalny dostęp do zarządzania oraz zatwierdzony przez producenta plan odtwarzania. Dopóki nie wykonano potwierdzonej operacji usuwania starszej konfiguracji przez CLI, zaplanowane zmiany w WebAdmin można cofnąć w udokumentowanej kolejności: najpierw usunąć przeniesiony adres IP z nowego interfejsu VLAN, a dopiero potem ponownie przypisać go do bridge; następnie przywrócić strefę, reguły, Device Access i profil portu przełącznika oraz sprawdzić dostęp do zarządzania i osiągalność bramy. Nie cofa to usunięcia konfiguracji przez CLI.

Sprzeczny opis resetu nie potwierdza możliwości odwrócenia operacji na poziomie poleceń. Jeśli testy odbiorcze po potwierdzonym usunięciu starszej konfiguracji nie zakończą się pomyślnie, należy zatrzymać procedurę i nie tworzyć ponownie starszego ustawienia. Należy eskalować problem w celu odtworzenia zatwierdzonego przez producenta na pierwotnej, obsługiwanej wersji firmware. W środowisku HA nie należy usuwać starszej konfiguracji z węzłów ani ich aktualizować, dopóki stan węzła peer lub synchronizacji wskazuje na błąd albo jest niejasny; należy zachować wymaganą kopię zapasową każdego węzła. Bez wymaganego wcześniejszego potwierdzenia metody inwentaryzacji, składni usuwania konfiguracji, kontekstu, skutków i zakresu należy ograniczyć się do inwentaryzacji w WebAdmin i zatrzymać procedurę przed usuwaniem starszej konfiguracji lub aktualizacją.

Po pomyślnym zakończeniu testów odbiorczych należy utworzyć nową kopię zapasową. Stara kopia zapasowa zawierająca starsze tagowanie VLAN przez CLI nie umożliwia wycofania zmiany w SFOS 22.0 GA ani w nowszych wersjach. Jeśli starsza konfiguracja pozostaje mimo migracji w WebAdmin lub kontrola wstępna aktualizacji nadal ją zgłasza, nie należy eksperymentować z kolejnymi zmianami CLI, lecz zachować konfigurację i komunikat oraz zaangażować Sophos Support.

Typowe błędy

Typowe pułapki:

• Testuj tylko ruch klient-serwer: Most wygląda na sprawny, chociaż ma to wpływ na lokalne usługi zapory sieciowej. Przetestuj także ruch do i z zapory ogniowej.
• Przeniesienie adresu IP mostu bez planu: WebAdmin, DNS lub Gateway może zawieść. Przygotuj kopie zapasowe, okna konserwacyjne i alternatywny dostęp.
• Nieprawidłowy wybór strefy dla nowego interfejsu VLAN: Reguły, Device Access i logi nie pasują. Wybierz strefę ze względu na bezpieczeństwo, a nie na przyzwyczajenie.
• Device Access otwarte zbyt szeroko: Problem wydaje się rozwiązany, ale usługi zarządzania są niepotrzebnie dostępne. Local Service ACL zaplanuj konkretnie.
• Pominięcie kontroli portu przełącznika: VLAN dociera niepoprawnie lub bez oznaczenia. Sprawdź profil Tagged/Untagged, Native VLAN i Trunk.
• Zignorowanie starej konfiguracji CLI: Błąd pozostaje niewyjaśniony po aktualizacji. Udokumentuj stary projekt i migruj do interfejsów WebAdmin-VLAN.

Lista kontrolna

• Sprawdzono wersję SFOS i znaczenie znanego problemu.
• Udokumentowano interfejs mostu, elementy mostu i VLAN identyfikatory.
• Wyjaśniono, czy użyto starej konfiguracji znacznika CLI VLAN.
• Sprawdzono drops specyficzne dla bridge przy NAT/web proxy oraz VLAN filtering.
• Planowana aktualizacja do SFOS 22.0 MR2 lub nowszej wersji sprawdzona pod kątem legacy CLI VLAN tags.
• Zidentyfikowano usługi, których dotyczy problem, do i z zapory ogniowej.
• Backup każdego właściwego węzła i alternatywny dostęp administracyjny są dostępne; peer i synchronizacja HA są sprawne.
• Planowany interfejs VLAN z mostem jako interfejsem nadrzędnym.
• Sprawdzono reguły strefy, Device Access, zapory sieciowej i reguły NAT.
• Testy przeprowadzone z VLAN i z firewalla.
• Metoda inwentaryzacji niezmieniająca konfiguracji oraz dokładna składnia usuwania starszej konfiguracji, kontekst CLI, skutki i zakres potwierdzone przed każdą operacją CLI dla zainstalowanego buildu w dokumentacji lub przez Sophos Support; w przeciwnym razie wyłącznie inwentaryzacja w WebAdmin i zatrzymanie procedury przed usuwaniem starszej konfiguracji lub aktualizacją.
• Granica odtwarzania udokumentowana: ze sprzecznego opisu resetu nie można wywnioskować metody wycofania operacji na poziomie poleceń; po potwierdzonym usunięciu starszej konfiguracji i pomyślnych testach odbiorczych utworzono nową kopię zapasową.
• Wynik zapisany w dzienniku zmian lub w dokumentacji sieci.

Często zadawane pytania