Handoff sluttar å verke når VPN koplar til: kva du bør sjekke

Opne ei side på iPhone, gå bort til Macen, og Dock-ikonet viser seg ikkje. Slå av VPN, og det verkar. Den sekvensen ser ut som eit VPN-problem, og det er det ofte, men ikkje av grunnen folk reknar med: Handoff er ein lokal funksjon mellom einingar, og tunnelen forstyrrar den lokale delen, ikkje internettdelen.

Fiks éi oppgåve og eitt par einingar

Vel éi einsleg Handoff-kompatibel oppgåve, som ei nettside i Safari eller eit utkast i Notes, og eitt einsleg par einingar. Hald appen, kontoane og dei fysiske posisjonane like medan du endrar éin variabel om gongen. Ein test som flyttar tre ting samstundes gjev ei observasjon du ikkje kan bruke.

Handoff er oppgåvefortsetjing, ikkje skjermspegling eller fildeling. Viss kravet er å spegle ein skjerm eller montere ei deling, feilsøkjer du ein annan funksjon med andre føresetnader.

Skriv ned den nøyaktige oppgåva, fordi verifiseringa av kvar retting er at same oppgåva verkar.

Føresetnadene er lokale, ikkje eksterne

Apple sine krav til Handoff er kompatible einingar i nærleiken, Wi-Fi og Bluetooth slått på på båe, same Apple Account innlogga og Handoff slått på. Sjekk kontoen som vert brukt til Continuity, ikkje kontoen som kjøpte ein app, fordi dei kan vere ulike på ein delt Mac. Stadfest deretter at appen og oppgåva faktisk støttar Handoff, sidan ein vilkårleg app som står open ikkje provar noko. Desse sjekkane er billige, og dei er det fyrste som må utelukkast.

Alt dette skjer over lokale radioar. Bluetooth annonserer aktiviteten og Wi-Fi ber nyttelasta, difor må einingane vere nær kvarandre sjølv når båe har internettilgang.

Ingenting av dette er avhengig av den offentlege adressa som ei av einingane brukar.

Kva VPN-klienten gjer med lokal trafikk

Ein fulltunnelklient kan fange det lokale subnettet saman med alt anna, og nokre klientar gjer nettopp det med mindre du tillèt lokal nettverkstilgang. Apple åtvarar om at VPN-konfigurasjonar som hindrar lokalt nettverk kan forstyrre Continuity-funksjonar. Det er ei utsegn om policyen til klienten, ikkje om éin bestemd blokkert port.

Mange klientar har eit unntak for lokal tilgang; les kva det tillèt før du slår det på, og føretrekk det støtta alternativet frå leverandøren framfor å redigere brannmurreglar manuelt.

Viss klienten ikkje har eit slikt alternativ, høyrer designavgjerda til den som eig utrullinga.

Kva ein delt utgang ikkje gjev deg

To einingar som brukar same VPN-tenar deler ei utgangsadresse, og det er alt dei deler. Det lagar ikkje Bluetooth-annonsen, det set dei ikkje på same lokale lenkje, og det rettar ikkje ein Apple Account som ikkje stemmer. Å handsame ei felles offentleg adresse som føresetnad er ein kategorifeil som fører til unødvendige klientendringar.

Abonnentisolering på VPN-tenesta er òg eit anna spørsmål enn to nærliggande einingar som held fram ei oppgåve, så å opne vidaresending mellom abonnentar er ikkje eit Handoff-steg.

Ein rutarbasert VPN endrar kva policy som gjeld for einingane, og han leverer framleis ikkje ein manglande radio eller konto.

Avgjer saman med policyeigaren, og verifiser deretter båe resultata

Tre vilkår avgjer rettinga. Held føresetnadskjeda stand med VPN slått av? Har klienten eit støtta alternativ for lokal tilgang, og tillèt policyen det? Og kan du verifisere endringa utan å svekke vernet tunnelen finst for? Viss det tredje svaret er nei, treng endringa administratoren framfor ein omveg.

Etter ei godkjend endring, stadfest båe resultata: oppgåva held fram på den nærliggande eininga, og applikasjonane som treng tunnelen held på den tiltenkte tilgangen og blokkeringa.

Registrer unntaket ved sida av konfigurasjonen for den tilkoplinga, elles fjernar den neste profiloppdateringa det lydlaust.