Mac-kunhavigo aperas tra la VPN: ĉu haltigi aŭ kaŝi ĝin?

Brosservaj listoj konstruiĝas el anoncoj, kaj anonco ne estas alirkoncedo. Iu vidas la nomon de via tekkomputilo en fora listo ĉar multicast-demando transiris limon, kiu kutime haltigas ĝin ĉe la enkursigilo. Tiu transiro klarigas kaj kial la ero aperas kaj kial forigi la eron ne samas kiel fermi la servon. Decidu, kontraŭ kiu el la du vi efektive protestas, antaŭ ol ŝanĝi ion ajn.

Kio efektive estas la brosservaĵo

mDNS-respondilo en la Mac respondas demandojn pri la servotipoj, kiujn ĝi gastigas, kaj la respondo portas nomon, pordon kaj kelkajn tekstajn rikordojn. La kliento, kiu demandis, poste montras tiun nomon en listo. Nenio en la interŝanĝo pruvas, ke konekto sukcesus, kaj nenio en ĝi donas permeson: la listo estas aserto pri nomo, ne pri aliro. Ĝuste tiu distingo decidas, ĉu vi devas malŝalti ion aŭ ĉesi publikigi ĝin.

Malsamaj servoj registriĝas aparte, do malapero de unu ero ne signifas, ke ĉiuj anoncoj haltis. Dosierkunhavigo registras unu tipon, ekrankunhavigo alian, kaj presiloj, aŭdovidaj bibliotekoj kaj programistaj iloj registras ĉiu sian. Antaŭ ol rigardi unu ŝaltilon kiel la ĉefan regilon, listigu, kio estas registrita kaj kiu procezo posedas ĝin:

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

Multicast restas loka se nenio pontas ĝin

Multicast DNS sendas al ligile-loka grupo sur UDP 5353, kaj enkursigiloj ne plusendas tiun grupon defaŭlte. Tunelo, kiu enkursigas unicast-trafikon, do lasas la trovon malantaŭe, kaj tial Mac en enkursigita VPN kutime estas nevidebla por la fora loko. Pontita tunelo, aŭ intence agordita ripetilo, ŝanĝas tion metante ambaŭ finojn en unu dissendan domajnon. Kian dezajnon vi havas, estas eco de la tunelo, ne de la protokola nomo presita sur ĝi.

Ekzamenu la servilan agordon por vidi, ĉu ĝi pontas interfacon aŭ enkursigas subreton, ĉar la du kondutas malsame por ĉiu dissendodependa protokolo. Se la tunelo estas pontita, atendu likon de pli ol unu speco de anonco, inkluzive de aferoj, kiujn neniu intencis publikigi. Se ĝi estas enkursigita, ero en fora listo probable alvenis per ripetilo aŭ per trovo bazita sur unicast DNS, ne per la multicast-grupo. Tiuj vojoj havas malsamajn riparojn, kaj blokado de la multicast-pordo fermas nur unu el ili.

Haltigi la servon estas la plej pura limo

Se la Mac havas nenion por fari kun dosieroj, malŝaltu kunhavigon per ĝia subtenata regilo anstataŭ provi kaŝi ĝian anoncon. Haltitan servon oni ne povas konekti, diveni aŭ atingi per malnova kliento, kiu memoris la nomon. Tiu eco faras ĝin la pli forta regilo, kaj ĝi tute ne bezonas kunlaboron de la reto.

La gvidilo pri dosierkunhavigo de Apple priskribas la permesan modelon por kunhavigitaj dosierujoj, permesitaj uzantoj kaj gastaliro, kaj la kunhaviga panelo montras la nunan staton. Revizu tiujn tri, kiam la servo vere necesas, ĉar kunhavigo, kiu devas ekzisti, estas kunhavigo, kiu devas esti limigita. Gastaliro meritas propran rigardon, ĉar ĝi povas permesi konekton tute sen legitimiloj. Poste konfirmu, sur kiuj interfacoj la servo aŭskultas, ĉar kunhavigo ofertita sur ĉiu interfaco estas ofertita ankaŭ sur la tunelo.

Kiam vi bezonas la servon sed ne la publikon

Foje la kunhavigo estas legitima kaj la publiko ne. Limigi la servon al aprobitaj fontoj, kun trovo kiel aparta kaj malpli grava regilo, estas la honesta aranĝo. Fajroŝirmilaj reguloj, permesoj por uzanto kaj aŭskultado sur la ĝusta interfaco mallarĝigas aliron tiel, kiel kaŝita anonco ne povas.

Subpremi trovon estas kosmetika laŭ la strikta senco: la servo ankoraŭ respondas al ĉiu, kiu scias la nomon. Se la publikigo mem estas la problemo, limigu ĝin en la tavolo, kiu portas ĝin. En reto, kiun vi administras, tio signifas decidi, kiuj servotipoj transiru la limon, kaj agordi la ponton, ripetilon aŭ filtron konforme. Kopii pontfiltrilan komandon el forumo funkcias nur se via servilo rulas ĝuste tiun stakon kaj tiun tunelan reĝimon, kaj en reto, kiun vi ne administras, la honesta respondo estas, ke vi ne povas regi, kion memoras fora kliento.

Rigardu ĝin de la fora flanko

Testu de la fora flanko anstataŭ de la propra reto de la Mac, kaj testu freŝan brosservadon anstataŭ kaŝmemorigitan liston. Poste provu rektan konekton al la servo laŭ nomo kaj laŭ adreso, ĉar la du rezultoj respondas malsamajn demandojn. Mankanta ero kun sukcesa konekto signifas, ke vi kaŝis etikedon, dum malsukcesa konekto signifas, ke vi fermis servon. Kaŝmemoro igas ambaŭ testojn mensogi, se vi preterlasas la refreŝigon, do startigu la klienton denove.

Notu, kion vi ŝanĝis kaj al kiu el la tri regiloj ĝi apartenas: servo haltigita, aliro limigita, aŭ trovo limigita. Kiam iu raportas, ke la Mac ankoraŭ aperas, tiu noto diras al vi, ĉu la raporto estas kaduka aŭ ĉu alia servo sin anoncas. Plej multaj surprizoj ĉi tie estas dua registriĝo, kiun neniu memoris ŝalti, ne rompita regilo.

Rekontrolu la ceterajn registriĝojn antaŭ ol konkludi, ke la ŝanĝo malsukcesis. Mallonga inventarlisto pli valoras ol plia rondo de divenado.