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, tę wewnętrzną kontrolę aktualizacji trzeba odświeżyć przed zmianą; 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.

Ostatni punkt 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, którego dotyczy problem, kierunek ruchu

Trzeba wyraźnie oddzielić trzy rodzaje ruchu.

Rodzaje ruchu różnią się znacznie:

• Ruch przeszedł 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 znaki 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 mostu IP 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 jest, że reguła zapory sieciowej, NAT, system docelowy lub ścieżka zwrotna. 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 niezalogowany most/NAT przypadek specjalny. 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.

Dołącz 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.
• IP adres mostu, jeśli jest dostępny.
• VLAN identyfikatory, które przechodzą przez most.
• Przełącz profil portu: 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, Centrala, 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 bridgem jako parent. Interfejsy fizyczne, RED, bridge i LAG są prawidłowymi parents.

Przed SFOS 18.0 polecenie system vlan-tag było wymagane do włączenia tagowanego ruchu VLAN przez bridge. Od SFOS 18.0 VLAN-over-bridge jest dostępne w WebAdmin. Dla poniższego polecenia CLI nie określono Device Console, Advanced Shell, numeru menu, promptu ani poziomu uprawnień. Używaj wyłącznie obsługiwanego kontekstu CLI firewalla, w którym polecenie jest dostępne. Jeśli nie jest dostępne, zatrzymaj się i zapytaj Sophos Support zamiast zgadywać powłokę lub kontekst. Najpierw sprawdź starą konfigurację tym poleceniem tylko do odczytu:

system vlan-tag show

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 znajdować się w tej usłudze VLAN Gateway lub lokalnej.
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 WebAdmin i SSH przebiegają dokładnie przez most, którego dotyczy problem IP, błąd może przerwać dostęp administracyjny.

Usuń starszą konfigurację i przygotuj aktualizację

Najpierw utwórz wymagane interfejsy VLAN w Network > Interfaces z bridgem jako parent, w razie potrzeby przenieś IP bridge do właściwego interfejsu VLAN i sprawdź ścieżki danych oraz zarządzania. W HA potwierdź w obsługiwanym interfejsie stanu, że peer i synchronizacja są sprawne, oraz wykonaj backup każdego węzła, gdy wymaga tego platforma i procedura wsparcia. Jeśli stan jest niesprawny lub niejasny, zatrzymaj się przed resetem lub aktualizacją i eskaluj; nie wymyślaj poleceń HA ani synchronizacji. Po udokumentowaniu mapowania, uruchomieniu alternatywnego dostępu i spełnieniu warunków HA usuń ustawienie w tym samym obsługiwanym kontekście CLI opisanym powyżej:

system vlan-tag reset

Ponownie uruchom system vlan-tag show. Jeśli konfiguracja pozostaje, reset nie powiedzie się lub wynik jest niejednoznaczny, zatrzymaj się: nie uruchamiaj aktualizacji ani nie zatwierdzaj nowego backupu jako oczyszczonego punktu. Zapisz wynik, precheck i konfigurację i eskaluj do Sophos Support bez nieudokumentowanych poleceń. Nie istnieje udokumentowane odwrócenie system vlan-tag reset na poziomie polecenia: pomyślne kontrole potwierdzają oczyszczenie, nie wycofanie. Po resecie nie odtwarzaj ustawienia legacy za pomocą domniemanego polecenia. Jeśli zmianę trzeba wycofać, zatrzymaj się i eskaluj w celu zatwierdzonego przez producenta odtworzenia na pierwotnym obsługiwanym firmware. Po udanych testach utwórz nowy backup, powtórz precheck i dopiero wtedy aktualizuj. Backup do przyszłego odtworzenia utwórz po takim samym oczyszczeniu firewalla źródłowego, opcjonalnym utworzeniu interfejsu VLAN i walidacji. Nie naprawia to starego backupu z system vlan-tag.

Device Access i później sprawdź reguły zapory sieciowej

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 portale Ping/Ping6, DNS, HTTPS, SSH, User Portal lub VPN 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 od dotkniętego VLAN

Sprawdź od klienta w dotkniętym VLAN:

1. Osiągnij wartość domyślną Gateway.
2. Przetestuj zaporę IP 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ź, czy Log Viewer pasuje do identyfikatora reguły i strefy.

Testuj z zapory sieciowej

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

• Przetestuj serwery AD lub LDAP w Authentication > Servers.
• Sprawdź rozdzielczość DNS poprzez zaporę sieciową.
• 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ż zaznaczyć opcję Skonfiguruj STAS na Sophos Firewall. W przypadku ulepszeń SFOS-22 ten punkt należy również do SFOS 22 sprawdzania ulepszeń.

Powrót i zakończenie

Przed zmianą zapisz adres IP i strefę bridge, identyfikatory VLAN, profil portu switcha oraz zależne reguły i usługi. Przygotuj alternatywny lub lokalny dostęp oraz zatwierdzony przez producenta plan odzyskiwania. Przed system vlan-tag reset zaplanowane zmiany WebAdmin można cofnąć w udokumentowanej kolejności: najpierw usuń przeniesiony IP z interfejsu VLAN, potem przypisz go do bridge; przywróć strefę, reguły, Device Access i profil switcha oraz sprawdź łączność. Nie odwraca to resetu. Po resecie brak udokumentowanego odwrócenia na poziomie polecenia: po nieudanym teście zatrzymaj się i eskaluj w celu zatwierdzonego odtworzenia na pierwotnym obsługiwanym firmware. W HA nie resetuj ani nie aktualizuj żadnego węzła przy niesprawnym lub niejasnym stanie peer/synchronizacji i zachowaj właściwy backup każdego węzła.

Po udanej weryfikacji utwórz nowy backup. Stary backup z legacy CLI VLAN tagging nie jest drogą powrotu dla SFOS 22.0 GA lub nowszego. Jeśli precheck nadal zgłasza konfigurację, zapisz ją i komunikat, a następnie skontaktuj się z Sophos Support zamiast próbować kolejnych nieudokumentowanych zmian CLI.

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.
• Przesuń most IP bez planu: WebAdmin, DNS lub Gateway może zawieść. Przygotuj kopie zapasowe, okna konserwacyjne i alternatywny dostęp.
• Nieprawidłowo wybierz strefę 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.
• Nie sprawdzaj portu przełącznika: VLAN dociera niepoprawnie lub bez oznaczenia. Sprawdź profil Tagged/Untagged, Native VLAN i Trunk.
• Zignoruj ​​starą konfigurację 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.
• Granica odzyskiwania udokumentowana: brak udokumentowanego odwrócenia system vlan-tag reset; po korekcie utworzono nowy backup.
• Wynik zapisany w dzienniku zmian lub w dokumentacji sieci.

Często zadawane pytania