Mac-delning dyker upp över VPN: stoppa eller dölja?

Bläddringslistor byggs av tillkännagivanden, och ett tillkännagivande är inte ett beviljande av åtkomst. Någon ser namnet på din bärbara dator i en fjärrlista eftersom en multicast-fråga korsade en gräns som vanligtvis stoppar den i routern. Den korsningen förklarar både varför posten visas och varför det inte är samma sak att ta bort posten som att stänga tjänsten. Bestäm vilket av de två du egentligen invänder mot innan du ändrar något.

Vad posten i bläddringslistan egentligen är

En mDNS-svarare på Macen svarar på frågor om de tjänstetyper den är värd för, och svaret bär ett namn, en port och några textposter. Klienten som frågade visar sedan namnet i en lista. Inget i utbytet bevisar att en anslutning skulle lyckas, och inget i det ger tillstånd: listan är ett påstående om ett namn, inte om åtkomst. Den skillnaden avgör om du bör stänga av något eller sluta publicera det.

Olika tjänster registrerar sig separat, så att en post försvinner betyder inte att alla tillkännagivanden har upphört. Fildelning registrerar en typ, skärmdelning en annan, och skrivare, mediebibliotek och utvecklarverktyg registrerar var sin. Innan du behandlar en enda strömbrytare som huvudkontrollen, lista vad som är registrerat och vilken process som äger det:

dns-sd -B _smb._tcp
lsof -nP -iUDP:5353

Multicast stannar lokalt om inget brygger bro över det

Multicast DNS skickar till en länklokal grupp på UDP 5353, och routrar vidarebefordrar inte den gruppen som standard. En tunnel som routar unicast-trafik lämnar därför upptäckten efter sig, och därför är en Mac på ett routat VPN vanligtvis osynlig för den fjärran platsen. En bryggad tunnel, eller ett relä som satts upp med avsikt, ändrar detta genom att placera båda ändarna i en enda broadcast-domän. Vilken konstruktion du har är en egenskap hos tunneln, inte hos protokollnamnet som tryckts på den.

Granska serverkonfigurationen för att se om den bryggar ett gränssnitt eller routar ett subnät, eftersom de två beter sig olika för varje broadcastberoende protokoll. Om tunneln är bryggad, räkna med att mer än en sorts tillkännagivande läcker ut, inklusive saker som ingen tänkt publicera. Om den är routad har en post i en fjärrlista förmodligen kommit via ett relä eller via unicast-DNS-baserad upptäckt, inte via multicast-gruppen. Dessa vägar har olika åtgärder, och att blockera multicast-porten stänger bara en av dem.

Att stoppa tjänsten är den renaste gränsen

Om Macen inte har något med filservering att göra, stäng av delning via den stödda kontrollen i stället för att försöka dölja dess tillkännagivande. En stoppad tjänst kan man inte ansluta till, gissa sig till eller nås av en gammal klient som kom ihåg namnet. Den egenskapen gör den till den starkare kontrollen, och den behöver inget samarbete från nätverket alls.

Apples guide för fildelning beskriver behörighetsmodellen för delade mappar, tillåtna användare och gäståtkomst, och delningspanelen visar det aktuella läget. Gå igenom dessa tre när tjänsten verkligen behövs, eftersom en delning som måste finnas är en delning som måste avgränsas. Gäståtkomst förtjänar en egen blick, eftersom den kan tillåta en anslutning helt utan inloggningsuppgifter. Bekräfta sedan vilka gränssnitt tjänsten lyssnar på, eftersom en delning som erbjuds på alla gränssnitt också erbjuds på tunneln.

När du behöver tjänsten men inte publiken

Ibland är delningen legitim och publiken inte. Att begränsa tjänsten till godkända källor, med upptäckten kvar som en separat och mindre kontroll, är den ärliga ordningen. Brandväggsregler, behörigheter per användare och att lyssna på rätt gränssnitt snävar in åtkomsten på sätt som ett dolt tillkännagivande inte kan.

Att undertrycka upptäckten är kosmetiskt i strikt mening: tjänsten svarar fortfarande alla som känner till namnet. Om själva publiceringen är problemet, begränsa den i det lager som bär den. På ett nätverk du administrerar innebär det att bestämma vilka tjänstetyper som ska korsa gränsen och konfigurera bryggan, reläet eller filtret därefter. Att kopiera ett bryggfilterkommando från ett forum fungerar bara om din server kör exakt den stacken och det tunneläget, och på ett nätverk du inte administrerar är det ärliga svaret att du inte kan styra vad en fjärrklient minns.

Se det från fjärrsidan

Testa från fjärrsidan i stället för från Macens eget nätverk, och testa en färsk bläddring i stället för en cachad lista. Försök sedan med en direkt anslutning till tjänsten efter namn och efter adress, eftersom de två resultaten svarar på olika frågor. En saknad post med lyckad anslutning betyder att du dolde en etikett, medan en misslyckad anslutning betyder att du stängde en tjänst. Cachen får båda testerna att ljuga om du hoppar över uppdateringen, så starta klienten på nytt.

Skriv ner vad du ändrade och vilken av de tre kontrollerna det hör till: tjänst stoppad, åtkomst begränsad eller upptäckt begränsad. När någon rapporterar att Macen fortfarande syns, berättar den anteckningen om rapporten är inaktuell eller om en annan tjänst tillkännager sig. De flesta överraskningarna här är en andra registrering som ingen kom ihåg att slå på, inte en trasig kontroll.

Kontrollera de återstående registreringarna igen innan du drar slutsatsen att ändringen misslyckades. En kort inventarielista slår ännu en runda gissningar.