Mac-deling dukker op over VPN: stop den eller skjul den?

Browse-lister bygges af annonceringer, og en annoncering er ikke en adgangstilladelse. Nogen ser din laptops navn på en fjern liste, fordi en multicast-forespørgsel krydsede en grænse, som normalt stopper den ved routeren. Den krydsning forklarer både, hvorfor posten vises, og hvorfor det ikke er det samme at fjerne posten som at lukke tjenesten. Afgør, hvilken af de to du egentlig indvender imod, før du ændrer noget.

Hvad browse-posten egentlig er

En mDNS-responder på Mac'en besvarer forespørgsler om de tjenestetyper, den hoster, og svaret bærer et navn, en port og nogle få tekstposter. Klienten, der spurgte, viser derefter navnet på en liste. Intet i udvekslingen beviser, at en forbindelse ville lykkes, og intet i den giver tilladelse: listen er en påstand om et navn, ikke om adgang. Den forskel afgør, om du skal slå noget fra eller holde op med at offentliggøre det.

Forskellige tjenester registrerer sig hver for sig, så én post, der forsvinder, betyder ikke, at alle annonceringer er stoppet. Fildeling registrerer én type, skærmdeling en anden, og printere, mediebiblioteker og udviklerværktøjer registrerer hver deres. Før du betragter en enkelt kontakt som hovedkontrollen, så list, hvad der er registreret, og hvilken proces der ejer det:

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

Multicast bliver lokalt, medmindre noget bygger bro over det

Multicast DNS sender til en linklokal gruppe på UDP 5353, og routere videresender ikke den gruppe som standard. En tunnel, der router unicast-trafik, efterlader derfor opdagelsen bagud, og derfor er en Mac på en routet VPN normalt usynlig for det fjerne sted. En tunnel med bro eller et relæ, der er sat op med vilje, ændrer det ved at sætte begge ender i ét broadcast-domæne. Hvilket design du har, er en egenskab ved tunnelen, ikke ved protokolnavnet, der er trykt på den.

Undersøg serverkonfigurationen for at se, om den bygger bro over et interface eller router et subnet, fordi de to opfører sig forskelligt for enhver broadcast-afhængig protokol. Er tunnelen med bro, så forvent, at mere end én slags annoncering lækker, inklusive ting, ingen havde til hensigt at offentliggøre. Er den routet, er en post på en fjern liste sandsynligvis kommet gennem et relæ eller gennem unicast-DNS-baseret opdagelse i stedet for gennem multicast-gruppen. De veje har forskellige rettelser, og blokering af multicast-porten lukker kun én af dem.

At stoppe tjenesten er den reneste grænse

Hvis Mac'en ikke har noget at gøre med at dele filer, så slå deling fra via dens understøttede kontrol i stedet for at prøve at skjule dens annoncering. En stoppet tjeneste kan man ikke forbinde til, gætte sig til eller nås af en gammel klient, der huskede navnet. Den egenskab gør den til den stærkere kontrol, og den kræver slet ingen netværkssamarbejde.

Apples guide til fildeling beskriver tilladelsesmodellen for delte mapper, tilladte brugere og gæsteadgang, og delingspanelet viser den aktuelle tilstand. Gennemgå de tre, når tjenesten virkelig er nødvendig, fordi en deling, der skal findes, er en deling, der skal afgrænses. Gæsteadgang fortjener et særligt blik, da den kan tillade en forbindelse helt uden legitimationsoplysninger. Bekræft derefter, hvilke interface tjenesten lytter på, fordi en deling, der tilbydes på alle interface, også tilbydes på tunnelen.

Når du har brug for tjenesten, men ikke publikum

Nogle gange er delingen legitim, og publikum er det ikke. At begrænse tjenesten til godkendte kilder, med opdagelse som en separat og mindre kontrol, er den ærlige ordning. Firewallregler, tilladelser per bruger og at lytte på det rigtige interface indsnævrer adgangen på måder, en skjult annoncering ikke kan.

At undertrykke opdagelse er kosmetisk i streng forstand: tjenesten svarer stadig enhver, der kender navnet. Hvis selve offentliggørelsen er problemet, så begræns den i det lag, der bærer den. På et netværk, du administrerer, betyder det at beslutte, hvilke tjenestetyper der skal krydse grænsen, og at konfigurere broen, relæet eller filteret derefter. At kopiere en bro-filterkommando fra et forum virker kun, hvis din server kører netop det stack og den tunnel-tilstand, og på et netværk, du ikke administrerer, er det ærlige svar, at du ikke kan styre, hvad en fjern klient husker.

Se det fra den fjerne side

Test fra den fjerne side i stedet for fra Mac'ens eget netværk, og test en frisk browsing i stedet for en cachet liste. Forsøg derefter en direkte forbindelse til tjenesten ved navn og ved adresse, fordi de to resultater besvarer forskellige spørgsmål. En manglende post med en vellykket forbindelse betyder, at du skjulte en etiket, mens en mislykket forbindelse betyder, at du lukkede en tjeneste. Cache får begge tests til at lyve, hvis du springer opdateringen over, så start klienten forfra.

Skriv ned, hvad du ændrede, og hvilken af de tre kontroller det hører til: tjeneste stoppet, adgang begrænset eller opdagelse begrænset. Når nogen rapporterer, at Mac'en stadig vises, fortæller den note dig, om rapporten er forældet, eller om en anden tjeneste annoncerer sig. De fleste overraskelser her er en anden registrering, som ingen huskede at slå til, ikke en ødelagt kontrol.

Tjek de resterende registreringer igen, før du konkluderer, at ændringen mislykkedes. En kort opgørelse slår endnu en runde gætteri.