Mac-deling dukkar opp over VPN: stoppe eller skjule?

Nettlesarlistene blir bygde av annonseringar, og ei annonsering er ikkje ei tilgangsløyve. Nokon ser namnet på den berekne datamaskina di i ei ekstern liste fordi ein multicast-førespurnad kryssa ei grense som vanlegvis stoppar han i rutaren. Den kryssinga forklarer både kvifor oppføringa blir vist og kvifor det ikkje er det same å fjerne oppføringa som å lukke tenesta. Avgjer kva av dei to du eigentleg protesterer mot før du endrar noko.

Kva oppføringa i nettlesarlista eigentleg er

Ein mDNS-svarar på Macen svarar på førespurnader om tenestetypane han er vert for, og svaret ber med seg eit namn, ein port og nokre få tekstoppføringar. Klienten som spurde viser deretter namnet i ei liste. Ingenting i utvekslinga provar at ei tilkopling ville lukkast, og ingenting i henne gir løyve: lista er ein påstand om eit namn, ikkje om tilgang. Den skilnaden avgjer om du bør slå noko av eller slutte å publisere det.

Ulike tenester registrerer seg kvar for seg, så éi oppføring som forsvinn tyder ikkje at alle annonseringar har stoppa. Fildeling registrerer éin type, skjermdeling ein annan, og skrivarar, mediebibliotek og utviklarverktøy registrerer kvar sin. Før du handsamar éin brytar som hovudkontrollen, list opp kva som er registrert og kva prosess som eig det:

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

Multicast blir lokalt med mindre noko byggjer bru over det

Multicast DNS sender til ei lenkjelokal gruppe på UDP 5353, og rutarar vidaresender ikkje den gruppa som standard. Ein tunnel som rutar unicast-trafikk lèt derfor oppdaginga bli att, og derfor er ein Mac på ein ruta VPN vanlegvis usynleg for den eksterne staden. Ein tunnel med bru, eller eit relé som er sett opp med vilje, endrar dette ved å plassere begge endar i eitt kringkastingsdomene. Kva design du har, er ein eigenskap ved tunnelen, ikkje ved protokollnamnet som er trykt på han.

Undersøk serverkonfigurasjonen for å sjå om han byggjer bru over eit grensesnitt eller rutar eit subnett, fordi dei to oppfører seg ulikt for kvar kringkastingsavhengig protokoll. Er tunnelen med bru, vent at meir enn éin type annonsering lek ut, inkludert ting ingen hadde til hensikt å publisere. Er han ruta, er ei oppføring i ei ekstern liste truleg komen gjennom eit relé eller gjennom unicast-DNS-basert oppdaging i staden for gjennom multicast-gruppa. Desse vegane har ulike rettingar, og å blokkere multicast-porten stenger berre éin av dei.

Å stoppe tenesta er den reinaste grensa

Viss Macen ikkje har noko med filtening å gjere, slå av deling via den støtta kontrollen i staden for å prøve å skjule annonseringa. Ei stoppa teneste kan ein ikkje kople til, gjete seg til eller nå med ein gammal klient som hugsa namnet. Den eigenskapen gjer henne til den sterkare kontrollen, og ho treng inga samarbeid frå nettet i det heile.

Apples rettleiing for fildeling beskriv løyvemodellen for delte mapper, tillatne brukarar og gjestetilgang, og delingspanelet viser gjeldande tilstand. Gå gjennom desse tre når tenesta verkeleg trengst, fordi ei deling som må finnast, er ei deling som må avgrensast. Gjestetilgang fortener eit eige blikk, sidan han kan tillate ei tilkopling heilt utan påloggingsinformasjon. Stadfest deretter kva grensesnitt tenesta lyttar på, fordi ei deling som blir tilboden på alle grensesnitt, også blir tilboden på tunnelen.

Når du treng tenesta, men ikkje publikumet

Stundom er delinga legitim og publikumet ikkje. Å avgrense tenesta til godkjende kjelder, med oppdaging som ein separat og mindre kontroll, er den ærlege ordninga. Brannmurreglar, løyve per brukar og lytting på rett grensesnitt snevrar inn tilgangen på måtar ei skjult annonsering ikkje kan.

Å undertrykkje oppdaging er kosmetisk i streng forstand: tenesta svarar framleis alle som kjenner namnet. Viss sjølve publiseringa er problemet, avgrens henne i laget som ber henne. På eit nett du administrerer, tyder det å avgjere kva tenestetypar som skal krysse grensa, og setje opp brua, reléet eller filteret deretter. Å kopiere ein bru-filterkommando frå eit forum verkar berre viss serveren din køyrer nøyaktig den stakken og den tunnelmodusen, og på eit nett du ikkje administrerer, er det ærlege svaret at du ikkje kan kontrollere kva ein ekstern klient hugsar.

Sjå det frå den eksterne sida

Test frå den eksterne sida i staden for frå Macen sitt eige nett, og test ein fersk gjennomgang i staden for ei buftra liste. Prøv deretter ei direkte tilkopling til tenesta ved namn og ved adresse, fordi dei to resultata svarar på ulike spørsmål. Ei manglande oppføring med vellukka tilkopling tyder at du skjulte ei etikett, medan ei mislukka tilkopling tyder at du lukka ei teneste. Bufring får begge testane til å lyge viss du hoppar over oppdateringa, så start klienten på nytt.

Skriv ned kva du endra og kva av dei tre kontrollane det høyrer til: teneste stoppa, tilgang avgrensa eller oppdaging avgrensa. Når nokon rapporterer at Macen framleis blir vist, fortel notatet deg om rapporten er utdatert eller om ei anna teneste annonserer seg. Dei fleste overraskingane her er ei anna registrering som ingen hugsa å slå på, ikkje ein øydelagd kontroll.

Sjekk dei attverande registreringane på nytt før du konkluderer med at endringa mislukkast. Ei kort oversikt slår endå ein runde med gjetting.