Sophos Firewall: mDNS-reflektor för enhetssökning mellan VLAN

mDNS-reflektorn i SFOS 23 möjliggör enhetssökning mellan utvalda interna nätverk och VLAN. På så sätt kan exempelvis en klient hitta en AirPlay-mottagare i ett annat VLAN. Reflektorn överför sökförfrågningar och tjänsteannonseringar, men inte automatiskt den efterföljande applikationstrafiken. Tillåtelse för streaming, utskrift eller fjärråtkomst planeras och kontrolleras separat.

Den korta proceduren: Aktivera mDNS reflector under Network > mDNS, välj IP version, Allowed interfaces och Services med tydlig avgränsning och spara med Apply. Testa därefter Discovery, faktisk användning och de nätverksgränser som fortfarande ska vara spärrade var för sig.

Den här guiden beskriver gränssnittet i SFOS 23. En befintlig SFOS 22-guide för statisk multicast-routning beskriver en annan procedur; den ersätter inte en reflektor. Att dokumentation finns tillgänglig är i sig inget bevis för en viss firmwarebuilds releasestatus eller lämplighet.

Skilj mellan Discovery och användning

mDNS, det vill säga Multicast DNS, används tillsammans med DNS-SD för lokal tjänstesökning. Bonjour är Apples benämning på motsvarande Zero Configuration-tjänster. I separata subnät stannar denna sökning normalt inom respektive segment. Reflektorn kopplar samman Discovery-nivån för de interfaces som uttryckligen har valts, utan att göra nätverken till ett gemensamt VLAN.

Det får två olika konsekvenser:

En enhet kan bli synlig även om anslutningen till dess tjänst fortfarande är blockerad. Synlighet bevisar varken att en lämplig brandväggsregel finns eller att streaming fungerar.
De valda nätverken får ytterligare information om erbjudna tjänster. Även när applikationstrafiken är blockerad kan denna synlighet vara oönskad, exempelvis mellan ett gästnätverk och ett administrationsnätverk.

Allowed interfaces är därför en säkerhetsgräns, inte bara ett tekniskt val. Dialogen definierar deltagande interfaces, inte ett riktat par av källa och destination. Man ska inte förutsätta att detta enbart gör att klienter i det ena VLAN:et ser enheter i det andra. Services begränsar de tjänstekategorier som reflekteras; en kategori är dock inte en tillåtelse för varje host eller varje port i en applikation.

WAN- och VPN-interfaces stöds inte. En fjärransluten VPN-klient blir inte automatiskt en del av lokal Discovery genom denna inställning. Ett annat sökprotokoll stöds inte heller enbart för att en applikation dessutom använder mDNS.

Förutsättningar och ett begränsat exempel

Före ändringen behövs:

En SFOS 23-build med Network > mDNS, åtkomst till WebAdmin och en oberoende managementåtkomst.
Redan konfigurerade interna interfaces med korrekt tilldelade VLAN och nätverk. Zoner och interfaces måste stämma överens med den faktiska topologin.
En klient och en känd tjänstelevererande enhet vars mDNS-sökning redan fungerar inom samma segment.
Ett beslut om vilka tjänstekategorier som får vara synliga över segmentgränserna, samt de applikationsportar som krävs enligt den applikation och enhetsversion som används.
En konfigurationsbackup samt en anteckning om reflektorns tidigare tillstånd, IP-versionen, interfaces, kategorier och befintliga applikationsregler.

För ett begränsat AirPlay-test används exempelvis:

Klient 10.20.20.50 i medarbetar-VLAN 10.20.20.0/24, brandväggsinterface Port2.20, zon LAN.
Mottagare 10.30.30.20 i media-VLAN 10.30.30.0/24, brandväggsinterface Port2.30, egen zon MEDIA.
IP version: IPv4, eftersom testet enbart använder IPv4.
Allowed interfaces: endast Port2.20 och Port2.30.
Services: endast AirPlay.

Adresser, VLAN-ID:n, interfacenamn och exempelzonen MEDIA ersätts med värden från den egna konfigurationen. Reflektorn väljer interfaces, inte dessa två enskilda hosts: Även andra enheter på de berörda interfacen kan delta i Discovery inom de valda kategorierna. En mer finfördelad tillitsgräns kräver en lämplig segmenteringsdesign, inte bara snävare applikationsregler.

Gäst-, management- och andra ovidkommande interfaces lämnas utanför i detta exempel. Ett inledande lyckat test med två interfaces ger mer användbar information än en bred tillåtelse där orsak och verkan knappt längre kan kopplas samman.

Konfigurera mDNS-reflektorn

Spara det tidigare tillståndet och välj IP-version

Öppna Network > mDNS i WebAdmin och dokumentera de befintliga inställningarna. En avstängd reflektor kan behålla en äldre konfiguration; kontrollera därför även det sparade urvalet innan den aktiveras.
Aktivera mDNS reflector. Det dokumenterade standardtillståndet är Off.
Välj den variant som faktiskt behövs under IP version: IPv4 reflekterar endast IPv4-mDNS, IPv6 endast IPv6-mDNS och Dual båda versionerna.

I exemplet används fortsatt IPv4. Dual är inte en allmän lösning på problem: Det utökar Discovery till båda IP-versionerna. Om IPv6-tjänster används senare måste även nåbarhet och applikationsregler för IPv6 planeras medvetet och kontrolleras separat.

Begränsa interfaces och tjänstekategorier

Välj Port2.20 och Port2.30 under Allowed interfaces. Endast de valda interfacen deltar i reflekterade sökförfrågningar och annonseringar; högst 16 interfaces stöds.
Välj AirPlay under Services.
Kontrollera före sparandet att inget gäst-, WAN-, VPN- eller managementinterface av misstag ingår i det planerade urvalet.
Klicka på Apply. Brandväggen reflekterar den Discovery-trafik som stöds omedelbart mellan de valda interfacen.

Utöver AirPlay kan AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos och Spotify Connect väljas. Urvalet anpassas efter det faktiska behovet. En tjänstekategori ersätter inte kontrollen av om den konkreta applikationen har ytterligare förutsättningar utöver Discovery.

⚠️ Any hanterar alla mDNS-tjänstekategorier, även sådana som inte listas separat. Det kan skapa ytterligare nätverkstrafik och påverka systemets prestanda. Det utökar dessutom vilka tjänster som är synliga. Byt inte till Any bara för att en enskild enhet saknas; kontrollera först dess Discovery och den lämpliga kategorin.

Tillåt applikationstrafik separat

För den efterföljande användningen skapas en riktad brandväggsregel, eller så kontrolleras en befintlig regel som redan passar. I testet är regelnamnet exempelvis AirPlay-Test-Client-zu-Media, källan är hosten 10.20.20.50 i LAN och destinationen är hosten 10.30.30.20 i MEDIA. Tjänsterna motsvarar de TCP-/UDP-portar som har bekräftats för denna enhet och applikation; loggning aktiveras för acceptanstestet.

Här finns avsiktligt ingen universell AirPlay-portlista att kopiera. Enhetsfunktioner och nödvändiga anslutningsriktningar måste vara fastställda innan trafiken tillåts. Saknade uppgifter från tillverkaren ersätts inte med Any. Om applikationen dessutom behöver en anslutning som initieras av den tjänstelevererande enheten motiveras detta separat och tillåts med snäv avgränsning. Ett normalt svar på en befintlig anslutning är inte automatiskt ett skäl för en bred regel i motsatt riktning.

Det är inte heller meningsfullt att på måfå skapa en generell UDP-tillåtelse som ersättning för reflektorkonfigurationen. Discovery-urvalet och applikationsregeln löser olika uppgifter. Ändringarna begränsas till det dokumenterade testet; andra regler, NAT och Multicast-routes ändras inte i förbifarten.

Verifiera resultatet med tre separata kontroller

1. Discovery på de valda interfacen

Kontrollera den sparade IP-versionen, interfaceurvalet och kategorierna igen efter Apply. Starta därefter om applikationens enhetssökning på testklienten. Den kända mottagaren från media-VLAN:et ska hittas, inte bara en post från en tidigare sökning.

Om resultatet är oklart startas en kort, tidsbegränsad inspelning under Diagnostics > Packet capture. Följande BPF-filter lämpar sig för mDNS:

udp port 5353

Filtret är endast ett observationshjälpmedel och ändrar inga tillåtelser. För IPv4-testet förväntas mDNS-trafik med den lokala Multicast-adressen 224.0.0.251. Jämför interface och tidsstämplar: Uppstår sökningen i klientnätverket, och syns motsvarande Discovery-trafik även på det valda media-interfacet? Paketinnehåll och en inspelning på klienten hjälper till att kontrollera om den förväntade tjänsten faktiskt annonseras. Ett enskilt paket eller en viss paketstatus bevisar inte i sig att sökningen lyckas. Proceduren förklaras i Packet Capture på Sophos Firewall.

2. Använd den faktiska tjänsten

Välj den upptäckta mottagaren och starta ett kort AirPlay-test. Ett lyckat resultat innebär att den önskade funktionen fungerar på mottagaren, inte bara att dess namn visas. Kontrollera destinationsadress, portar, anslutningsriktning och matchande regel i regelloggen eller i en separat inspelning av hostparet 10.20.20.50 och 10.30.30.20.

Om Discovery fungerar men användningen inte gör det lämnas reflektorurvalet till en början oförändrat. Kontrollera nu applikationsregler, faktiska portar, routing, lokala brandväggar på enheterna och själva applikationen. En bredare reflektor löser inte en blockerad applikationstjänst.

3. Kontrollera de gränser som inte har öppnats

Kontrollera med en ny sökning i ett uteslutet testsegment att tjänsten inte blir synlig genom denna reflektor. Testa dessutom att anslutningar som inte har tillåtits fortfarande blockeras. Befintliga cacheposter och andra Discovery-gateways kan ge missvisande resultat; en visning utan motsvarande ny nätverkstrafik är inte tillräckligt bevis för oönskad reflektion.

I HA synkroniseras reflektorinställningarna mellan enheterna. Funktionen i SFOS 23 stöder Discovery även vid failover. Det är ingen utfästelse om avbrottsfria applikationssessioner. Använd ett redan planerat HA-test för att kontrollera Discovery och användning igen efter rollbytet; utlös inte en failover i produktion enbart för denna guide.

Avgränsa fel systematiskt

Network > mDNS saknas eller ett interface saknas

Kontrollera den installerade SFOS-versionen och den faktiska interfacekonfigurationen. Den här guiden förutsätter gränssnittet i SFOS 23. WAN- och VPN-interfaces är uteslutna. Dokumentera ett saknat internt interface eller ett urval som inte kan sparas tillsammans med build, interfacetyp och det exakta meddelandet; gränsen på 16 interfaces får inte överskridas. Försök inte kringgå detta med en statisk Multicast-route eller en odokumenterad shelländring.

Tjänsten hittas inte

Kontrollera först i den tjänstelevererande enhetens lokala segment att dess Discovery fungerar. Om den redan saknas där är nästa möjliga felkällor enheten, applikationen, WLAN-klientisolering eller lokala nätverksfilter, inte reflektorn. Om den fungerar lokalt kontrolleras IP-versionen, båda valda interfacen, tjänstekategorin och det resultat som faktiskt sparades efter Apply.

Jämför därefter den korta mDNS-inspelningen på båda sidor. Om sökförfrågan redan saknas på klientinterfacet kontrolleras klienten och nätverksvägen. Om förfrågan finns men ingen motsvarande tjänsteannonsering syns undersöks den tjänstelevererande enheten. Om en passande annonsering finns men Discovery inte fungerar på klienten kontrolleras nätverksvägen tillbaka till klienten. Gör ändringar en i taget och upprepa sedan samma test.

Tjänsten är synlig men fungerar inte

Spela in applikationstrafiken separat och undersök en paketblockering utifrån värdar, portar och regelkontext. Komplettera tillåtelsen endast med värden som bevisligen behövs; öppna inte alla tjänster mellan de båda VLAN:en. Även en annonserad adress som klienten inte kan nå kan förhindra användningen; kontrollera den faktiska destinationsadressen och dess routingväg.

För många tjänster eller ytterligare belastning uppstår

Kontrollera om Services är inställt på Any, om oönskade kategorier har valts och om Allowed interfaces omfattar ytterligare segment. Återställ en oavsiktlig utökning till det noterade tidigare tillståndet. Om störningen började omedelbart efter aktiveringen stängs reflektorn av kontrollerat och samma begränsade test upprepas. Inför inte tjänsteomstarter eller ytterligare reflektorer på måfå.

Om problemet kvarstår sparas build, IP-version, berörda interfaces, kategorier, anonymiserade hostadresser, tidsstämplar och korta inspelningar från båda sidor inför eskalering. Kunddata och onödiga paketpayloads hör inte hemma i ett offentligt supportexempel.

Återställ säkert

Avsluta testet och dokumentera resultatet samt de senast sparade inställningarna.
Om reflektorn tidigare var avstängd stängs den av igen under Network > mDNS och ändringen sparas med Apply. Om den redan var aktiv återställs i stället den tidigare noterade IP-versionen samt urvalet av interfaces och kategorier, och ändringarna sparas; stäng inte generellt av andra beroende tjänster.
Avaktivera endast den applikationsregel som lades till för detta test, eller återställ den dokumenterade ändringen i en befintlig regel.
Öppna inställningarna igen och kontrollera Discovery, tidigare tjänster och fortsatt blockerade anslutningar med en ny sökning.

När reflektorn stängs av behålls dess konfiguration; när den aktiveras igen används det tidigare urvalet på nytt. Avstängning innebär därför inte att de sparade tillitsgränserna raderas. Kontrollera interfaces och kategorier igen före varje senare återaktivering. Befintliga Discovery-poster på klienten kan fortfarande visas efter återställningen, och en applikation som redan körs är inget bevis för att ny Discovery fortfarande reflekteras.