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

Nettleserlistene bygges av annonseringer, og en annonsering er ikke en tilgangstillatelse. Noen ser navnet på laptopen din i en ekstern liste fordi en multicast-forespørsel krysset en grense som vanligvis stopper den i ruteren. Den kryssingen forklarer både hvorfor oppføringen vises og hvorfor det ikke er det samme å fjerne oppføringen som å lukke tjenesten. Avgjør hvilken av de to du egentlig protesterer mot før du endrer noe.

Hva oppføringen i nettleserlisten egentlig er

En mDNS-responder på Macen svarer på forespørsler om tjenestetypene den er vert for, og svaret bærer et navn, en port og noen få tekstoppføringer. Klienten som spurte viser deretter navnet i en liste. Ingenting i utvekslingen beviser at en tilkobling ville lykkes, og ingenting i den gir tillatelse: listen er en påstand om et navn, ikke om tilgang. Den forskjellen avgjør om du bør slå noe av eller slutte å publisere det.

Ulike tjenester registrerer seg hver for seg, så én oppføring som forsvinner betyr ikke at alle annonseringer har stoppet. Fildeling registrerer én type, skjermdeling en annen, og skrivere, mediebiblioteker og utviklerverktøy registrerer hver sin. Før du behandler én bryter som hovedkontrollen, list opp hva som er registrert og hvilken prosess som eier det:

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

Multicast blir lokalt med mindre noe bygger bro over det

Multicast DNS sender til en linklokal gruppe på UDP 5353, og rutere videresender ikke den gruppen som standard. En tunnel som ruter unicast-trafikk, lar derfor oppdagelsen bli igjen, og derfor er en Mac på en rutet VPN vanligvis usynlig for det eksterne stedet. En tunnel med bro, eller en relé som er satt opp med vilje, endrer dette ved å plassere begge ender i ett kringkastingsdomene. Hvilket design du har, er en egenskap ved tunnelen, ikke ved protokollnavnet som er trykt på den.

Undersøk serverkonfigurasjonen for å se om den bygger bro over et grensesnitt eller ruter et subnett, fordi de to oppfører seg ulikt for hver kringkastingsavhengig protokoll. Er tunnelen med bro, forvent at mer enn én type annonsering lekker ut, inkludert ting ingen hadde til hensikt å publisere. Er den rutet, er en oppføring i en ekstern liste sannsynligvis kommet gjennom en relé eller gjennom unicast-DNS-basert oppdagelse i stedet for gjennom multicast-gruppen. Disse veiene har ulike rettelser, og å blokkere multicast-porten stenger bare én av dem.

Å stoppe tjenesten er den reneste grensen

Hvis Macen ikke har noe med filservering å gjøre, slå av deling via den støttede kontrollen i stedet for å prøve å skjule annonseringen. En stoppet tjeneste kan man ikke koble til, gjette seg til eller nås av en gammel klient som husket navnet. Den egenskapen gjør den til den sterkere kontrollen, og den trenger ingen samarbeid fra nettverket i det hele tatt.

Apples veiledning for fildeling beskriver tillatelsesmodellen for delte mapper, tillatte brukere og gjestetilgang, og delingspanelet viser gjeldende tilstand. Gå gjennom disse tre når tjenesten virkelig trengs, fordi en deling som må finnes, er en deling som må avgrenses. Gjestetilgang fortjener et eget blikk, siden den kan tillate en tilkobling helt uten påloggingsinformasjon. Bekreft deretter hvilke grensesnitt tjenesten lytter på, fordi en deling som tilbys på alle grensesnitt, også tilbys på tunnelen.

Når du trenger tjenesten, men ikke publikumet

Noen ganger er delingen legitim og publikumet ikke. Å begrense tjenesten til godkjente kilder, med oppdagelse som en separat og mindre kontroll, er den ærlige ordningen. Brannmurregler, tillatelser per bruker og lytting på riktig grensesnitt snevrer inn tilgangen på måter en skjult annonsering ikke kan.

Å undertrykke oppdagelse er kosmetisk i streng forstand: tjenesten svarer fortsatt alle som kjenner navnet. Hvis selve publiseringen er problemet, begrens den i laget som bærer den. På et nettverk du administrerer, betyr det å bestemme hvilke tjenestetyper som skal krysse grensen, og konfigurere broen, reléet eller filteret deretter. Å kopiere en bro-filterkommando fra et forum virker bare hvis serveren din kjører nøyaktig den stakken og den tunnelmodusen, og på et nettverk du ikke administrerer, er det ærlige svaret at du ikke kan kontrollere hva en ekstern klient husker.

Se det fra den eksterne siden

Test fra den eksterne siden i stedet for fra Macens eget nettverk, og test en fersk gjennomgang i stedet for en bufret liste. Prøv deretter en direkte tilkobling til tjenesten ved navn og ved adresse, fordi de to resultatene svarer på forskjellige spørsmål. En manglende oppføring med vellykket tilkobling betyr at du skjulte en etikett, mens en mislykket tilkobling betyr at du lukket en tjeneste. Bufring får begge testene til å lyve hvis du hopper over oppdateringen, så start klienten på nytt.

Skriv ned hva du endret og hvilken av de tre kontrollene det hører til: tjeneste stoppet, tilgang begrenset eller oppdagelse begrenset. Når noen rapporterer at Macen fortsatt vises, forteller notatet deg om rapporten er utdatert eller om en annen tjeneste annonserer seg. De fleste overraskelsene her er en annen registrering som ingen husket å slå på, ikke en ødelagt kontroll.

Sjekk de gjenværende registreringene på nytt før du konkluderer med at endringen mislyktes. En kort oversikt slår enda en runde med gjetting.