Sprawdzenie Bridge-VLAN na Sophos Firewall po SFOS 22

Interfejsy Bridge na Sophos Firewall są przydatne, gdy istniejąca sieć warstwy 2 ma być kontynuowana w sposób przejrzysty lub gdy migracja ma być przeprowadzona bez natychmiastowej zmiany IP. Jednak z VLAN-ami na bridge projekt szybko staje się podatny na błędy: pojawia się wtedy przekazywanie między sieciami, ruch do samej zapory, Device Access, DNS, AD, uwierzytelnianie i często stare konfiguracje CLI.

Właśnie w tym miejscu pojawia się ważny przypadek operacyjny w SFOS 22. Sophos wymienia w aktualnej liście znanych problemów problem, w którym Bridge-Interfaces z konfiguracjami CLI VLAN tag w SFOS 22.0 GA i SFOS 22.0 MR1 nie przetwarzają poprawnie ruchu VLAN-tagged, gdy ten ruch pochodzi od samej Sophos Firewall lub kończy się na zaporze. Może to dotyczyć na przykład Active Directory, DNS, Device Access, STAS, LDAP, RADIUS lub dostępu do zarządzania, mimo że normalny ruch jest przekazywany przez bridge.

Ten artykuł nie jest ogólnym rozdziałem o podstawach VLAN. Do planowania stref, interfejsów, VLAN-ów, bridge i LAG-ów najpierw pasuje Konfigurowanie stref i interfejsów Sophos Firewall. Tutaj skupiamy się na szczególnym przypadku Bridge-VLAN po SFOS 22.

Kiedy ten temat jest istotny

Sprawdzenie ma sens, gdy występuje kilka punktów jednocześnie:

• Zapora działa na SFOS 22.0 GA lub SFOS 22.0 MR1.
• Istnieje interfejs bridge, na przykład br0.
• VLAN-y zostały historycznie skonfigurowane za pomocą CLI VLAN tag configuration, jak system vlan-tag, lub przejęte z starej konfiguracji.
• Usługi samej zapory muszą dotrzeć do tagowanego VLAN-u.
• Po aktualizacji AD, DNS, uwierzytelnianie, monitorowanie lub dostęp do zarządzania działają tylko częściowo.
• Normalny ruch klienta przez bridge wydaje się nadal działać.

Ostatni punkt jest ważny: jeśli bridge nadal przekazuje ruch między sieciami, problem początkowo nie wydaje się być błędem bridge. W praktyce szybko szuka się w niewłaściwym miejscu, na przykład w regułach zapory, DNS, STAS lub kontrolerze domeny.

Zrozumienie dotkniętego kierunku ruchu

Trzeba wyraźnie rozdzielić trzy rodzaje ruchu.

Jeśli testowana jest tylko jedna aplikacja między dwoma hostami, błąd nie jest pewnie wykrywany. Test musi świadomie obejmować usługę, która kończy się na Sophos Firewall lub jest generowana przez zaporę.

Typowe objawy

Możliwe oznaki to:

• Reguły oparte na użytkownikach nie działają już niezawodnie, ponieważ AD, STAS lub LDAP nie są stabilnie osiągalne.
• Zapytania DNS do zapory zawodzą z poszczególnych VLAN-ów.
• Ping lub HTTPS do lokalnych usług zapory nie działa z VLAN-u, mimo że reguły zapory wyglądają na sensowne.
• Monitorowanie lub Syslog wydaje się niekompletne, gdy zapora musi dotrzeć do celu w tagowanym VLAN-ie.
• Packet Capture pokazuje, że ruch między systemami końcowymi jest widoczny, ale usługi samej zapory nie odpowiadają zgodnie z oczekiwaniami.
• Po aktualizacji do SFOS 22 objawy występują, mimo że na przełączniku lub w regułach zapory nic świadomie nie zmieniono.

Takie objawy nie powinny być natychmiast odpowiadane szerokimi regułami Allow lub Device Access. Najpierw trzeba ustalić, czy sam projekt interfejsu jest dotknięty.

Szybkie rozgraniczenie przed przebudową

Zanim przesunie się IP bridge lub utworzy nowe interfejsy VLAN na bridge, należy zawęzić przyczynę. Nie każdy problem po aktualizacji jest automatycznie przypadkiem Bridge-VLAN SFOS 22.

Dla problemów DNS dodatkowo ważne jest, czy klienci używają zapory jako resolvera, czy zapora sama używa DNS Request Routes do wewnętrznych serwerów. Drugi przypadek dotyczy ruchu z zapory i może wyglądać inaczej przy problemach Bridge-VLAN niż normalny ruch klienta. Podstawy znajdują się w Konfigurowanie DNS Request Routes na Sophos Firewall.

Jeśli szybkie rozgraniczenie wyraźnie wskazuje na lokalne usługi zapory lub ruch generowany przez zaporę, przebudowa powinna być mimo to zaplanowana. Korekta bridge bez kopii zapasowej, okna konserwacyjnego i alternatywnej ścieżki dostępu jest zbyt ryzykowna w sieciach produkcyjnych.

Dokumentowanie istniejącego projektu

Przed zmianami należy udokumentować stan obecny. Szczególnie ważne są:

• Nazwa interfejsu bridge, na przykład br0.
• Członkowie bridge, czyli zaangażowane fizyczne interfejsy, VLAN-y, interfejsy RED lub LAG.
• Adres IP bridge, jeśli istnieje.
• ID VLAN-ów, które przechodzą przez bridge.
• Profil portu przełącznika: Tagged VLAN-y, Native VLAN, Trunk lub Access Port.
• Usługi kończące się na zaporze: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Usługi, które zapora musi osiągnąć: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Jeśli projekt pochodzi z dawnej migracji, należy dodatkowo sprawdzić, czy VLAN-y zostały skonfigurowane za pomocą CLI. Dokładnie ta spuścizna często nie jest już w pamięci, gdy zapora była aktualizowana przez lata.

⚠️ Na interfejsach bridge i VLAN-ach nie należy eksperymentować spontanicznie w codziennej pracy. Błędna zmiana może wpłynąć na dostęp do zarządzania, DNS, uwierzytelnianie lub całe sieci klientów. Przed korektą potrzebna jest kopia zapasowa, okno konserwacyjne i alternatywna ścieżka dostępu.

Obchodzenie problemu: Tworzenie interfejsów VLAN na bridge

Praktycznym sposobem jest tworzenie interfejsów VLAN w Network > Interfaces i używanie interfejsu bridge jako interfejsu nadrzędnego.

Przykłady:

Przebieg zależy od tego, czy bridge sam już ma adres IP.

Gdy bridge nie potrzebuje adresu IP

Jeśli bridge ma tylko przekazywać ruch w sposób przejrzysty, może działać bez własnego adresu IP. Adres IP dla dotkniętego VLAN-u znajduje się wtedy na interfejsie VLAN, na przykład br0.100.

Praktyczny przebieg:

1. Utwórz kopię zapasową.
2. Udokumentuj aktualną konfigurację bridge i VLAN.
3. W Network > Interfaces dodaj nowy interfejs VLAN.
4. Wybierz bridge jako interfejs nadrzędny, na przykład br0.
5. Wprowadź ID VLAN.
6. Świadomie wybierz strefę.
7. Ustaw adres IP na interfejsie VLAN, jeśli zapora ma być bramą lub lokalną usługą w tym VLAN-ie.
8. Sprawdź Device Access dla strefy.
9. Sprawdź reguły zapory i reguły NAT.
10. Zweryfikuj z klientem testowym.

Strefa to nie tylko porządek w WebAdmin. Ta decyzja wpływa na reguły zapory, Device Access, logi i wiele późniejszych kroków rozwiązywania problemów. Jeśli VLAN jest przeznaczony jako sieć zarządzania, serwerowa lub kliencka, powinno to być widoczne w strefie.

Gdy bridge obecnie ma produkcyjny adres IP

Jeśli bridge obecnie używa adresu IP, który w przyszłości musi być osiągalny w VLAN-ie, należy postępować szczególnie ostrożnie. Dla przebudowy są dwie czyste opcje: bridge otrzymuje inny adres IP lub bridge pozostaje bez adresu IP. Dotychczasowy produkcyjny adres zostaje następnie przypisany do interfejsu VLAN.

To zmiana z ryzykiem awarii. Przedtem należy ustalić:

• Przez jaki adres osiągany jest WebAdmin?
• Którzy klienci używają zapory jako domyślnej bramy?
• Jakie ustawienia DNS lub DHCP wskazują na ten adres?
• Jakie reguły Device Access są powiązane z dotychczasową strefą?
• Czy istnieje drugi dostęp do zarządzania z sieci nieobjętej problemem?

W przypadku lokalizacji zdalnych ta zmiana nie powinna być planowana bez lokalnej ścieżki powrotnej. Jeśli WebAdmin i SSH działają przez dokładnie ten dotknięty adres bridge, błąd może przerwać dostęp administracyjny.

Sprawdzenie Device Access i reguł zapory po zmianie

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

Do sprawdzenia:

• Administration > Device access: Czy Ping/Ping6, DNS, HTTPS, SSH, User Portal lub VPN Portal są dozwolone tylko w odpowiednich strefach?
• Rules and policies > Firewall rules: Czy istnieją reguły dla nowej strefy?
• Rules and policies > NAT rules: Czy ruch jest nieoczekiwanie tłumaczony?
• Network > DNS lub DNS Request Routes: Czy zapora osiąga właściwe serwery DNS lub AD?
• Authentication > Servers: Czy AD, LDAP lub RADIUS są osiągalne po zmianie?

Dla lokalnych usług zapory odpowiednim artykułem pogłębiającym jest Bezpieczna konfiguracja Device Access na Sophos Firewall. Dla analizy reguł pomocny jest Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Walidacja po korekcie

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

Test z dotkniętego VLAN-u

Z klienta w dotkniętym VLAN-ie sprawdź:

1. Osiągnij domyślną bramę.
2. Przetestuj IP zapory na nowym interfejsie VLAN za pomocą ping, jeśli dozwolone.
3. Przetestuj DNS przeciwko zaporze, jeśli zapora działa jako resolver DNS.
4. Przetestuj WebAdmin lub Portal tylko z dozwolonych sieci zarządzania.
5. Sprawdź typową aplikację lub połączenie z serwerem.
6. Skontroluj Log Viewer pod kątem odpowiedniej ID reguły i strefy.

Test z zapory

Dla ruchu generowanego przez zaporę potrzebne są osobne testy:

• Przetestuj serwer AD lub LDAP w Authentication > Servers.
• Sprawdź rozwiązywanie DNS przez zaporę.
• Sprawdź NTP, Syslog lub cel monitorowania, jeśli te usługi znajdują się w VLAN-ie.
• Użyj Packet Capture na interfejsie VLAN, jeśli nie jest jasne, czy pakiety opuszczają zaporę.

Jeśli STAS lub reguły oparte na użytkownikach są dotknięte, dodatkowo należy sprawdzić Konfigurowanie STAS na Sophos Firewall. Przy aktualizacjach do SFOS 22 ten punkt również należy do SFOS 22 Upgrade Check.

Częste błędy

Lista kontrolna

• Sprawdzono wersję SFOS i znaczenie znanego problemu.
• Udokumentowano interfejs bridge, członków bridge i ID VLAN.
• Wyjaśniono, czy użyto starej konfiguracji CLI VLAN tag.
• Zidentyfikowano dotknięte usługi do i z zapory.
• Dostępna kopia zapasowa i alternatywny dostęp do zarządzania.
• Zaplanowano interfejs VLAN z bridge jako interfejsem nadrzędnym.
• Sprawdzono strefę, Device Access, reguły zapory i reguły NAT.
• Przeprowadzono testy z VLAN-u i z zapory.
• Wynik zapisano w dzienniku zmian lub dokumentacji sieciowej.

FAQ