Handoff ĉesas funkcii kiam la VPN konektiĝas: kion kontroli

Malfermu paĝon sur la iPhone, iru al la Mac, kaj la Dock-piktogramo ne aperas. Malŝaltu la VPN kaj ĝi funkcias. Tiu sinsekvo aspektas kiel VPN-problemo, kaj ofte ĝi estas, sed ne pro la kaŭzo kiun homoj supozas: Handoff estas loka funkcio inter aparatoj, kaj la tunelo ĝenas la lokan parton, ne la interretan parton.

Riparu unu taskon kaj unu paron da aparatoj

Elektu unu solan Handoff-kapablan taskon, kiel retpaĝon en Safari aŭ malneton en Notes, kaj unu solan paron da aparatoj. Tenu la aplikaĵon, la kontojn kaj la fizikajn poziciojn samaj dum vi ŝanĝas unu variablon samtempe. Testo kiu movas tri aferojn samtempe produktas observon kiun vi ne povas uzi.

Handoff estas daŭrigo de tasko, ne spegulado de ekrano aŭ dosiera kunhavigo. Se la postulo estas speguli ekranon aŭ munti kunhavigon, vi sencimigas alian funkcion kun aliaj antaŭkondiĉoj.

Skribu la precizan taskon, ĉar la kontrolilo de iu ajn ripariĝo estas ke tiu sama tasko funkcias.

La antaŭkondiĉoj estas lokaj, ne malproksimaj

La postuloj de Apple por Handoff estas proksimaj kongruaj aparatoj, ŝaltitaj Wi-Fi kaj Bluetooth sur ambaŭ, la sama Apple Account ensalutinta, kaj Handoff ŝaltita. Kontrolu la konton uzatan por Continuity, ne la konton kiu aĉetis aplikaĵon, ĉar tiuj povas malsami sur komuna Mac. Poste konfirmu ke la aplikaĵo kaj la tasko efektive subtenas Handoff, ĉar arbitra aplikaĵo restanta malferma pruvas nenion. Tiuj kontroloj estas malmultekostaj, kaj ili estas la unuaj aferoj forigendaj.

Ĉio tio okazas per lokaj radioj. Bluetooth anoncas la agadon kaj Wi-Fi portas la utilan ŝarĝon, tial la aparatoj devas esti proksimaj unu al la alia eĉ kiam ambaŭ havas interretan aliron.

Nenio el tio dependas de la publika adreso kiun uzas iu ajn aparato.

Kion la VPN-kliento faras al loka trafiko

Kliento de plena tunelo povas kapti la lokan subreton kune kun ĉio alia, kaj iuj klientoj faras ĝuste tion se vi ne permesas lokan retaliron. Apple avertas ke VPN-agordoj kiuj malhelpas lokan retadon povas ĝeni funkciojn de Continuity. Tio estas aserto pri la politiko de la kliento, ne pri unu specifa blokita pordo.

Multaj klientoj proponas lokan alir-escepton; legu kion ĝi permesas antaŭ ol ŝalti ĝin, kaj preferu la subtenatan opcion de la vendisto anstataŭ permane redakti fajroŝirmilajn regulojn.

Se la kliento ne havas tian opcion, la dezajna decido apartenas al tiu kiu posedas la deplojon.

Kion komuna eliro ne donas al vi

Du aparatoj uzantaj la saman VPN-servilon kunhavas eliran adreson, kaj tio estas ĉio kion ili kunhavas. Ĝi ne kreas la Bluetooth-anoncon, ĝi ne metas ilin sur la saman lokan ligon, kaj ĝi ne riparas malkongruan Apple Account. Trakti komunan publikan adreson kiel antaŭkondiĉon estas kategoria eraro kiu kondukas al senutilaj klientaj ŝanĝoj.

Abonanta izolado en la VPN-servo ankaŭ estas alia demando ol du proksimaj aparatoj daŭrigantaj taskon, do malfermi plusendadon inter abonantoj ne estas Handoff-paŝo.

Router-bazita VPN ŝanĝas kiun politikon aplikas al la aparatoj, kaj ĝi ankoraŭ ne provizas mankantan radion aŭ konton.

Decidu kun la posedanto de la politiko, poste kontrolu ambaŭ rezultojn

Tri kondiĉoj decidas la riparon. Ĉu la antaŭkondiĉa ĉeno tenas kun la VPN malŝaltita? Ĉu la kliento havas subtenatan lokan alir-opcion, kaj ĉu la politiko permesas ĝin? Kaj ĉu vi povas kontroli la ŝanĝon sen malfortigi la protekton por kiu la tunelo ekzistas? Se la tria respondo estas ne, la ŝanĝo bezonas la administranton anstataŭ provizoran solvon.

Post aprobita ŝanĝo, konfirmu ambaŭ rezultojn: la tasko daŭras sur la proksima aparato, kaj la aplikaĵoj kiuj bezonas la tunelon konservas sian celitan aliron kaj blokan konduton.

Registru la escepton apud la agordo de tiu konekto, alie la sekva profila ĝisdatigo silente forigos ĝin.