Sophos Firewall Sprawdź sieci VLAN mostu dla SFOS 22

Interfejsy mostkowe na Sophos Firewall są praktyczne, jeśli istniejąca sieć warstwy 2 ma być kontynuowana w sposób przejrzysty lub gdy migracja ma zostać wdrożona bez natychmiastowych zmian IP. Jednak w przypadku sieci VLAN na moście projekt szybko staje się podatny na błędy: następuje przekazywanie między sieciami, ruch do samej zapory sieciowej, Device Access, DNS, AD, uwierzytelnianie i często stare konfiguracje CLI.

Dokładnie w tym momencie występuje ważny przypadek operacyjny z SFOS 22. Sophos wymienia problem na aktualnej liście znanych problemów, w którym interfejsy mostkowe z konfiguracjami znaczników CLI VLAN w SFOS 22.0 GA i SFOS 22.0 MR1 nie przetwarzają poprawnie ruchu oznaczonego VLAN, jeśli ten ruch pochodzi z samego Sophos Firewall lub kończy się na zaporze ogniowej. Może to na przykład mieć wpływ na Active Directory, DNS, Device Access, STAS, LDAP, RADIUS lub dostęp do zarządzania, mimo że przez most kierowany jest normalny ruch.

Sophos opisuje teraz także legacy CLI VLAN tagging jako deprecated. Takie konfiguracje odziedziczone mogą blokować aktualizacje do SFOS 22.0 MR2 i nowszych wersji. Dlatego ta kontrola jest nie tylko troubleshootingiem po aktualizacji, lecz także sensownym przygotowaniem przed następnym oknem serwisowym.

Ten artykuł nie jest ogólnym rozdziałem o VLAN podstawach. W przypadku planowania stref, interfejsów, sieci VLAN, mostów i grup LAG na początek sprawdza się opcja Sophos Firewall Skonfiguruj strefy i interfejsy. Dotyczy to szczególnie mostu VLAN specjalnego przypadku po 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ą

Sophos opisuje trzy ograniczenia bridge, które przed zmianą należy świadomie sprawdzić.

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. Według Sophos 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. Sophos wymienia ograniczenia dla 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ć.

Obejście i przygotowanie do aktualizacji

Praktycznym sposobem jest utworzenie interfejsów VLAN w Network > Interfaces przy użyciu interfejsu mostu jako interfejsu nadrzędnego.

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. Sophos dopuszcza WebAdmin 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. Utwórz kopię zapasową.
2. Udokumentuj bieżący mostek i konfigurację VLAN.
3. Dodaj nowy interfejs VLAN w obszarze Network > Interfaces.
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ź z klientem testowym.

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.

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.
• Użyj Packet Capture na interfejsie VLAN, gdy nie jest jasne, czy pakiety opuszczają zaporę.

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

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.
• Dostępny jest dostęp do kopii zapasowych i alternatywnego zarządzania.
• 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.
• Wynik zapisany w dzienniku zmian lub w dokumentacji sieci.

Często zadawane pytania