Sophos Firewall: reflektor mDNS do wykrywania urządzeń między sieciami VLAN

Reflektor mDNS w SFOS 23 umożliwia wykrywanie urządzeń między wybranymi sieciami wewnętrznymi i sieciami VLAN. Dzięki temu klient może na przykład znaleźć odbiornik AirPlay w innej sieci VLAN. Reflektor przekazuje zapytania wyszukiwania i ogłoszenia usług, ale nie zezwala automatycznie na późniejszy ruch aplikacji. Zezwolenia na przesyłanie strumieniowe, drukowanie lub dostęp zdalny planuje się i sprawdza osobno.

Skrócona procedura: w sekcji Network > mDNS włączyć mDNS reflector, precyzyjnie wybrać IP version, Allowed interfaces oraz Services i zatwierdzić przyciskiem Apply. Następnie oddzielnie przetestować wykrywanie, rzeczywiste korzystanie z usługi oraz granice sieci, które nadal mają pozostać zablokowane.

Ta instrukcja opisuje interfejs SFOS 23. Istniejąca instrukcja dla SFOS 22 dotycząca statycznego routingu Multicast opisuje inną procedurę; nie zastępuje ona reflektora. Sama dostępność dokumentacji nie jest potwierdzeniem statusu wydania ani przydatności konkretnego buildu firmware.

Rozróżnienie wykrywania i korzystania z usługi

mDNS, czyli Multicast DNS, służy wraz z DNS-SD do lokalnego wykrywania usług. Bonjour to nazwa stosowana przez Apple dla odpowiednich usług Zero-Configuration. W oddzielnych podsieciach takie wyszukiwanie zwykle pozostaje w obrębie danego segmentu. Reflektor łączy warstwę wykrywania na jawnie wybranych interfejsach, nie przekształcając tych sieci w jedną wspólną sieć VLAN.

Ma to dwa różne skutki:

Urządzenie może stać się widoczne, mimo że połączenie z jego usługą nadal jest zablokowane. Widoczność nie potwierdza ani istnienia odpowiedniej reguły firewalla, ani działania przesyłania strumieniowego.
Wybrane sieci otrzymują dodatkowe informacje o oferowanych usługach. Nawet przy zablokowanym ruchu aplikacji taka widoczność może być niepożądana, na przykład między siecią gościnną a siecią administracyjną.

Dlatego Allowed interfaces stanowi granicę bezpieczeństwa, a nie tylko wybór techniczny. Okno konfiguracji określa uczestniczące interfejsy, a nie kierunkową parę źródło–cel. Nie należy zakładać, że dzięki temu tylko klienci z jednej sieci VLAN będą widzieć urządzenia w drugiej. Services ogranicza kategorie usług przekazywane przez reflektor; kategoria nie oznacza jednak zezwolenia dla każdego hosta lub każdego portu aplikacji.

Interfejsy WAN i VPN nie są obsługiwane. To ustawienie nie włącza automatycznie zdalnego klienta VPN do lokalnego mechanizmu wykrywania. Również inny protokół wyszukiwania nie staje się obsługiwany tylko dlatego, że aplikacja dodatkowo korzysta z mDNS.

Wymagania wstępne i ograniczony przykład

Przed zmianą potrzebne są:

Build SFOS 23 z sekcją Network > mDNS, dostęp do WebAdmin i niezależny dostęp administracyjny.
Już skonfigurowane interfejsy wewnętrzne z prawidłowo przypisanymi sieciami VLAN i sieciami. Strefy i interfejsy muszą odpowiadać rzeczywistej topologii.
Klient i znany dostawca usługi, dla których wyszukiwanie mDNS już działa w tym samym segmencie.
Decyzja, które kategorie usług mogą być widoczne między segmentami, oraz wymagane porty aplikacji zgodne z używaną aplikacją i wersją urządzenia.
Kopia zapasowa konfiguracji oraz zapis dotychczasowego stanu reflektora, wersji IP, interfejsów, kategorii i istniejących reguł aplikacji.

Do ograniczonego testu AirPlay można użyć na przykład:

Klienta 10.20.20.50 w pracowniczej sieci VLAN 10.20.20.0/24, interfejsu firewalla Port2.20, strefy LAN.
Odbiornika 10.30.30.20 w multimedialnej sieci VLAN 10.30.30.0/24, interfejsu firewalla Port2.30, osobnej strefy MEDIA.
IP version: IPv4, ponieważ ten test korzysta wyłącznie z IPv4.
Allowed interfaces: tylko Port2.20 i Port2.30.
Services: tylko AirPlay.

Adresy, identyfikatory VLAN, nazwy interfejsów i przykładową strefę MEDIA należy zastąpić wartościami z własnej konfiguracji. Reflektor wybiera interfejsy, a nie te dwa pojedyncze hosty: również inne urządzenia na uczestniczących interfejsach mogą brać udział w wykrywaniu w ramach wybranych kategorii. Dokładniejsza granica zaufania wymaga odpowiedniego projektu segmentacji, a nie jedynie bardziej restrykcyjnych reguł aplikacji.

Interfejsy gościnne, administracyjne i inne niezwiązane z testem pozostają w tym przykładzie wykluczone. Udany początkowy test z dwoma interfejsami daje bardziej miarodajne wyniki niż szerokie zezwolenie, przy którym trudno już powiązać przyczynę ze skutkiem.

Konfiguracja reflektora mDNS

Zapisanie stanu początkowego i wybór wersji IP

W WebAdmin otworzyć Network > mDNS i zapisać dotychczasowe ustawienia. Wyłączony reflektor może zachować starszą konfigurację; dlatego przed włączeniem należy sprawdzić również zapisany wybór.
Włączyć mDNS reflector. Udokumentowany stan domyślny to Off.
W IP version wybrać rzeczywiście potrzebny wariant: IPv4 przekazuje przez reflektor tylko mDNS dla IPv4, IPv6 tylko mDNS dla IPv6, a Dual obie wersje.

W przykładzie należy pozostać przy IPv4. Dual nie jest uniwersalnym sposobem naprawy: rozszerza wykrywanie na obie wersje IP. Jeśli później będą używane usługi IPv6, trzeba również świadomie zaplanować osiągalność i reguły aplikacji dla IPv6 oraz sprawdzić je osobno.

Ograniczenie interfejsów i kategorii usług

W Allowed interfaces wybrać Port2.20 i Port2.30. Tylko wybrane interfejsy uczestniczą w zapytaniach wyszukiwania i ogłoszeniach przekazywanych przez reflektor; obsługiwanych jest maksymalnie 16 interfejsów.
W Services wybrać AirPlay.
Przed zatwierdzeniem sprawdzić, czy do planowanego wyboru nie trafił przypadkowo żaden interfejs gościnny, WAN, VPN lub administracyjny.
Kliknąć Apply. Firewall natychmiast zaczyna przekazywać obsługiwany ruch wykrywania między wybranymi interfejsami.

Oprócz AirPlay dostępne są AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos i Spotify Connect. Wybór należy dostosować do rzeczywistych potrzeb. Kategoria usługi nie zastępuje sprawdzenia, czy konkretna aplikacja ma dodatkowe wymagania poza wykrywaniem.

⚠️ Any przetwarza wszystkie kategorie usług mDNS, również te, które nie są wymienione osobno. Może to generować dodatkowy ruch sieciowy i obniżać wydajność systemu. Rozszerza także zakres widocznych usług. Nie należy przełączać na Any tylko dlatego, że brakuje pojedynczego urządzenia; najpierw należy sprawdzić jego wykrywanie i odpowiednią kategorię.

Osobne zezwolenie na ruch aplikacji

Na potrzeby późniejszego korzystania z usługi należy utworzyć precyzyjnie ograniczoną regułę firewalla lub sprawdzić istniejącą, odpowiednią regułę. W teście przykładowa nazwa reguły to AirPlay-Test-Client-zu-Media, źródłem jest host 10.20.20.50 w LAN, a celem host 10.30.30.20 w MEDIA. Usługi odpowiadają portom TCP/UDP potwierdzonym dla tego urządzenia i tej aplikacji; na potrzeby testu odbiorczego należy włączyć rejestrowanie.

Celowo nie podano tutaj uniwersalnej listy portów AirPlay do skopiowania. Funkcje urządzenia i wymagane kierunki połączeń muszą być znane przed udzieleniem zezwolenia. Braku informacji od producenta nie należy kompensować wyborem Any. Jeśli aplikacja dodatkowo wymaga połączenia inicjowanego przez dostawcę usługi, należy je osobno uzasadnić i udzielić ściśle ograniczonego zezwolenia. Zwykła odpowiedź w ramach istniejącego połączenia nie jest automatycznie powodem do utworzenia szerokiej reguły w przeciwnym kierunku.

Równie nieuzasadnione jest tworzenie na podstawie przypuszczeń ogólnego zezwolenia UDP jako zamiennika konfiguracji reflektora. Wybór dotyczący wykrywania i reguła aplikacji realizują różne zadania. Zmiany pozostają ograniczone do udokumentowanego testu; nie należy przy okazji zmieniać innych reguł, NAT ani tras Multicast.

Potwierdzenie działania w trzech oddzielnych testach

1. Wykrywanie na wybranych interfejsach

Po kliknięciu Apply ponownie sprawdzić zapisaną wersję IP, wybór interfejsów i kategorie. Następnie na kliencie testowym ponownie uruchomić wyszukiwanie urządzeń w aplikacji. Oczekiwany jest znany odbiornik z multimedialnej sieci VLAN, a nie tylko wpis z wcześniejszego wyszukiwania.

Jeśli wynik jest niejednoznaczny, w Diagnostics > Packet capture uruchomić krótkie przechwytywanie ograniczone czasowo. Jako filtr BPF dla mDNS nadaje się:

udp port 5353

Filtr jest wyłącznie pomocą w obserwacji i nie zmienia żadnych zezwoleń. W teście IPv4 oczekiwany jest ruch mDNS z lokalnym adresem Multicast 224.0.0.251. Należy porównać interfejs i znaczniki czasu: czy wyszukiwanie powstaje w sieci klienta i czy odpowiadający mu ruch wykrywania jest widoczny także na wybranym interfejsie multimedialnym? Zawartość pakietów i przechwytywanie na kliencie pomagają sprawdzić, czy oczekiwana usługa jest rzeczywiście ogłaszana. Pojedynczy pakiet lub sam określony status pakietu nie potwierdza skutecznego wyszukiwania. Procedurę wyjaśnia artykuł Packet Capture na Sophos Firewall.

2. Rzeczywiste korzystanie z usługi

Wybrać wykryty odbiornik i rozpocząć krótki test AirPlay. Sukces oznacza, że żądana funkcja działa na odbiorniku, a nie tylko że pojawia się jego nazwa. W logu reguły lub w osobnym przechwytywaniu dla pary hostów 10.20.20.50 i 10.30.30.20 należy sprawdzić adres docelowy, porty, kierunek połączenia i pasującą regułę.

Jeśli wykrywanie działa, ale korzystanie z usługi nie, wybór reflektora należy początkowo pozostawić bez zmian. Teraz należy sprawdzić reguły aplikacji, rzeczywiste porty, routing, lokalne firewalle urządzeń i samą aplikację. Rozszerzenie konfiguracji reflektora nie naprawi zablokowanej usługi aplikacji.

3. Kontrola granic, dla których nie udzielono zezwolenia

Za pomocą nowego wyszukiwania w wykluczonym segmencie testowym sprawdzić, czy usługa nie staje się widoczna za pośrednictwem tego reflektora. Dodatkowo przetestować, czy połączenia, na które nie udzielono zezwolenia, nadal są blokowane. Istniejące pamięci podręczne i inne bramy wykrywania mogą zniekształcić wynik; wyświetlenie wpisu bez odpowiadającego mu nowego ruchu sieciowego nie jest wystarczającym dowodem niepożądanego przekazywania przez reflektor.

W HA ustawienia reflektora są synchronizowane między urządzeniami. Funkcja SFOS 23 obsługuje wykrywanie również podczas failover. Nie jest to gwarancja nieprzerwanych sesji aplikacji. Już zaplanowany test HA należy wykorzystać do ponownego sprawdzenia wykrywania i korzystania z usługi po zmianie ról; nie należy wywoływać failover w środowisku produkcyjnym wyłącznie na potrzeby tej instrukcji.

Ukierunkowane diagnozowanie błędów

Brakuje Network > mDNS lub interfejsu

Sprawdzić zainstalowaną wersję SFOS i rzeczywistą konfigurację interfejsów. Ta instrukcja zakłada dostępność interfejsu SFOS 23. Interfejsy WAN i VPN są wykluczone. Brakujący interfejs wewnętrzny lub wybór, którego nie można zapisać, należy udokumentować wraz z buildem, typem interfejsu i dokładnym komunikatem; nie wolno przekraczać limitu 16 interfejsów. Nie należy obchodzić tego ograniczenia za pomocą statycznej trasy Multicast ani nieudokumentowanej zmiany w powłoce.

Usługa nie jest wykrywana

Najpierw w lokalnym segmencie dostawcy usługi sprawdzić, czy jej wykrywanie działa. Jeśli nie działa już tam, kolejnymi elementami do sprawdzenia są urządzenie, aplikacja, izolacja klientów WLAN lub lokalne filtry sieciowe, a nie reflektor. Jeśli wykrywanie działa lokalnie, należy sprawdzić wersję IP, oba wybrane interfejsy, kategorię usługi i rzeczywiście zapisany wynik po kliknięciu Apply.

Następnie porównać krótkie przechwytywanie mDNS po obu stronach. Jeśli już na interfejsie klienta brakuje zapytania wyszukiwania, sprawdzić klienta i ścieżkę sieciową. Jeśli zapytanie jest obecne, ale nie ma odpowiedniego ogłoszenia usługi, zbadać dostawcę usługi. Gdy ogłoszenie jest właściwe, ale klient nie wykrywa usługi, sprawdzić ścieżkę sieciową z powrotem do klienta. Zmiany należy wprowadzać pojedynczo, a następnie powtarzać ten sam test.

Usługa jest widoczna, ale nie działa

Osobno przechwycić ruch aplikacji i zbadać odrzucenie na podstawie hostów, portów i kontekstu reguły. Zezwolenie należy uzupełnić wyłącznie o wartości, których konieczność została potwierdzona, a nie otwierać wszystkich usług między obiema sieciami VLAN. Również ogłaszany adres, który jest nieosiągalny dla klienta, może uniemożliwić korzystanie z usługi; należy sprawdzić rzeczywisty adres docelowy i jego ścieżkę routingu.

Pojawia się zbyt wiele usług lub dodatkowe obciążenie

Sprawdzić, czy Services ustawiono na Any, czy wybrano niepożądane kategorie oraz czy Allowed interfaces obejmuje dodatkowe segmenty. W przypadku niezamierzonego rozszerzenia przywrócić zanotowany stan początkowy. Jeśli zakłócenie zaczęło się bezpośrednio po aktywacji, w kontrolowany sposób wyłączyć reflektor i powtórzyć ten sam ograniczony test. Nie należy na podstawie przypuszczeń restartować usług ani dodawać kolejnych reflektorów.

Jeśli problem nadal występuje, na potrzeby eskalacji zachować build, wersję IP, uczestniczące interfejsy, kategorie, zanonimizowane adresy hostów, znaczniki czasu i krótkie przechwytywania z obu stron. Dane klientów i zbędna zawartość pakietów nie powinny trafiać do publicznego przykładu zgłoszenia do pomocy technicznej.

Bezpieczne wycofanie zmian

Zakończyć test i udokumentować wynik oraz ostatnio zapisane ustawienia.
Jeśli reflektor był wcześniej wyłączony, ponownie wyłączyć go w Network > mDNS i zatwierdzić przyciskiem Apply. Jeśli był już aktywny, zamiast tego przywrócić zanotowaną wcześniej wersję IP, wybór interfejsów i kategorii oraz zatwierdzić; nie należy zbiorczo wyłączać innych zależnych usług.
Wyłączyć tylko regułę aplikacji dodaną na potrzeby tego testu albo wycofać udokumentowaną zmianę w istniejącej regule.
Ponownie otworzyć ustawienia i za pomocą nowego wyszukiwania sprawdzić wykrywanie, dotychczasowe usługi oraz połączenia, które nadal mają być blokowane.

Po wyłączeniu konfiguracja reflektora pozostaje zachowana; przy ponownym włączeniu używany jest poprzedni wybór. Wyłączenie nie oznacza więc usunięcia zapisanych granic zaufania. Przed każdą późniejszą reaktywacją należy ponownie sprawdzić interfejsy i kategorie. Istniejące już wpisy wykrywania na kliencie mogą być nadal wyświetlane po wycofaniu zmian, a działająca już aplikacja nie dowodzi, że nowe wykrywanie nadal jest przekazywane przez reflektor.