AirDrop mankas kun ŝaltita VPN? Kontrolu la lokan enkursigadon

AirDrop funkcias, poste la VPN konektiĝas, kaj la alia Mac aŭ iPhone malaperas el la dividfenestro. Nenio en la VPN-protokolo mencias malkovron, ĉar la fiasko kutime temas pri loka atingeblo kaj ne pri kriptografio. La subtena paĝo de Apple agnoskas, ke VPN-agordo, kiu limigas la lokan reton, povas ĝeni Continuity kaj AirDrop; tio estas utila signo, ne diagnozo. Komencu per la malmultekostaj kontroloj, poste legu la enkursigan tabelon, kaj traktu la ŝaltilon de loka aliro kiel decidon pri via privateco anstataŭ kiel agordon por simple renversi.

Kio rompiĝas antaŭ ol la tunelo eĉ partoprenas

Ambaŭ aparatoj bezonas ŝaltitajn Wi-Fi aŭ Bluetooth, AirDrop devas ricevi de kontaktoj aŭ de ĉiuj ene de sia ricevfenestro, kaj la du kontoj devas esti malkovreblaj unu al la alia. Meti la ricevanton al ĉiuj dum dek minutoj estas legitima eksperimento: se la alia aparato aperas tie, la agordoj estis la problemo kaj la tunelo estas senkulpa. Testu per konata ricevanto anstataŭ juĝi laŭ tio, kion la dividfenestro proponas.

Retumilo, kiu ŝargas paĝojn, pruvas ke la interreta vojo funkcias, ne ke la loka malkovro funkcias. Konservu ambaŭ aparatojn kaj la lokon, kie vi staras, senŝanĝaj, poste ŝaltu kaj malŝaltu la VPN kaj notu, ĉu la alia aparato malaperas nur dum la tunelo estas supre. Se la malkovro mortas kun la tunelo kaj revenas sen ĝi, la tunelo estas la variablo kaj la resto de ĉi tiu listo validas. Se ĝi fiaskas en ambaŭ statoj, la antaŭkondiĉoj bezonas pluan trairon antaŭ ol ŝanĝi ajnan retan politikon.

La dividfenestro malpleniĝas, kiam la implicita vojo moviĝas

Kliento de plena tunelo kutime instalas implicitan vojon tra la tunelo plus du duonvojojn, kiuj kaptas la plej multajn cellokojn. Loka subreto postvivas tiun aranĝon nur se ĝi havas pli specifan vojon; alie ĝi malaperas en la tunelon. AirDrop mem iras super la samtavola interfaco AWDL, do kliento, kiu filtradas aŭ agreseme enkursigas lokajn interfacojn, povas ĝeni dum la interreta vojo restas perfekta. Kvar komandoj kovras la interfacon, la vojojn, la aktivan konekton kaj la pakaĵan filtron.

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

Legu unue la implicitan linion: se ĝi montras al interfaco utun kaj neniu pli specifa vojo kovras vian subreton, loka trafiko eniras la tunelon kaj la konscio malaperas kun ĝi. La paro 0/1 kaj 128.0/1 estas ofta formo de plena tunelo, ĉar tiuj vojoj venkas la veran impliciton sen anstataŭigi ĝin. Linio awdl0 kun aktiva stato kaj adreso ekskludas, ke la samtavola interfaco estas malsupre. Kiam ĉiuj tri aspektas normalaj, la limigo venas de klienta politiko aŭ de filtrilo sur la gastiganto, ne de la enkursiga tabelo.

Unu formo indas mencion, ĉar ĝi kaptas homojn en gastaj retoj, kaj ĝi ne estas la duonvojoj. DHCP instalas la ĝus ricevitan adreson kiel vojon sur la ligilo, kaj tiu rikordo estas pli specifa ol ĉiu el ambaŭ duonoj, do gasta subreto postvivas la tunelon same kiel hejma. Kio forigas ĝin estas politiko, ne enkursigado: prefero, kiu blokas la lokan reton kaj instalas malakceptan regulon, filtrilo sur la gastiganto, kiu forĵetas la subreton, aŭ la permeso de macOS por loka reto por la kliento. Do tabelo aspektanta normala kun mortinta dividfenestro estas la signo de la sekva sekcio, ne de la voja formo.

Administrata Mac eble ne proponas la ŝaltilon de loka aliro

Multaj klientoj montras preferon permesi lokan retan aliron dum la tunelo estas supre, sed tiun preferon plenumas la kliento kaj la administra profilo, do sur administrata Mac ĝi povas esti ŝlosita, kaŝita aŭ superregita. Regulo de gastiganta filtrilo aŭ sekureca agento povas bloki la samtavolan trafikon sendepende de tio, kion la VPN-kliento proponas. Serĉu la ŝaltilon antaŭ ol konkludi, ke ĝi faras nenion. Tiu ŝaltilo loĝas en la propraj preferoj de la kliento, ne en la retaj agordoj de macOS, kaj tial kliento, kies panelo ne montras ĝin, kutime estas regata de administra profilo.

Forigi la administradon aŭ malŝalti ĉiun filtrilon, por ke unu ricevanto aperu, interŝanĝas kontrolatan agordon kontraŭ nekonatan. Ŝaltu la opcion de loka aliro nur kiam ĝi kongruas kun la politiko, sub kiu vi laboras, kaj lasu ĝin malŝalta en gasta reto, kie loka malkovro neniam estis dezirata.

Pruvu per dosiero, ne per ikono

Post ŝanĝo de enkursigado aŭ politiko, sendu realan dosieron al la celita ricevanto kaj konfirmu, ke la transigo finiĝas. Nomo aperanta en la fenestro estas malkovro, kaj la reveno de malkovro ne samas kiel finita transigo.

Se la aparato ankoraŭ ne aperas, komparu duan paron da aparatoj en la sama reto por apartigi gastigantan problemon de retskala problemo. Tiu komparo estas pli rapida ol ŝalti VPN-opciojn unu post unu, kaj ĝi donas fakton por la bileto. Notu la implicitan interfacon, la vojan formon kaj la staton de la ŝaltilo de loka aliro dum la fiasko estas ripetebla. Alie la sekva persono ripetos ĉiujn kvar kontrolojn de la komenco.