Handoff slutter å virke når VPN kobler til: hva du bør sjekke

Åpne en side på iPhone, gå bort til Macen, og Dock-ikonet vises ikke. Slå av VPN, og det virker. Den sekvensen ser ut som et VPN-problem, og det er det ofte, men ikke av grunnen folk antar: Handoff er en lokal funksjon mellom enheter, og tunnelen forstyrrer den lokale delen, ikke internettdelen.

Fiks én oppgave og ett par enheter

Velg én enkelt Handoff-kompatibel oppgave, som en nettside i Safari eller et utkast i Notes, og ett enkelt par enheter. Hold appen, kontoene og de fysiske posisjonene like mens du endrer én variabel om gangen. En test som flytter tre ting samtidig gir en observasjon du ikke kan bruke.

Handoff er oppgavefortsettelse, ikke skjermspeiling eller fildeling. Hvis kravet er å speile en skjerm eller montere en deling, feilsøker du en annen funksjon med andre forutsetninger.

Skriv ned den nøyaktige oppgaven, fordi verifiseringen av enhver retting er at samme oppgave virker.

Forutsetningene er lokale, ikke eksterne

Apples krav til Handoff er kompatible enheter i nærheten, Wi-Fi og Bluetooth slått på på begge, samme Apple Account logget inn og Handoff slått på. Sjekk kontoen som brukes til Continuity, ikke kontoen som kjøpte en app, fordi de kan være forskjellige på en delt Mac. Bekreft deretter at appen og oppgaven faktisk støtter Handoff, siden en vilkårlig app som står åpen ikke beviser noe. Disse sjekkene er billige, og de er det første som må utelukkes.

Alt dette skjer over lokale radioer. Bluetooth annonserer aktiviteten og Wi-Fi bærer nyttelasten, derfor må enhetene være nær hverandre selv når begge har internettilgang.

Ingenting av dette avhenger av den offentlige adressen en av enhetene bruker.

Hva VPN-klienten gjør med lokal trafikk

En fulltunnelklient kan fange det lokale subnettet sammen med alt annet, og noen klienter gjør nettopp det med mindre du tillater lokal nettverkstilgang. Apple advarer om at VPN-konfigurasjoner som hindrer lokalt nettverk kan forstyrre Continuity-funksjoner. Det er en uttalelse om klientens policy, ikke om én bestemt blokkert port.

Mange klienter har et unntak for lokal tilgang; les hva det tillater før du aktiverer det, og foretrekk leverandørens støttede alternativ fremfor å redigere brannmurregler manuelt.

Hvis klienten ikke har et slikt alternativ, tilhører designbeslutningen den som eier utrullingen.

Hva en delt utgang ikke gir deg

To enheter som bruker samme VPN-server deler en utgangsadresse, og det er alt de deler. Det lager ikke Bluetooth-annonsen, det setter dem ikke på samme lokale lenke, og det retter ikke en Apple Account som ikke stemmer. Å behandle en felles offentlig adresse som forutsetning er en kategorifeil som fører til unødvendige klientendringer.

Abonnentisolering på VPN-tjenesten er også et annet spørsmål enn to nærliggende enheter som fortsetter en oppgave, så å åpne videresending mellom abonnenter er ikke et Handoff-trinn.

En ruterbasert VPN endrer hvilken policy som gjelder for enhetene, og den leverer fortsatt ikke en manglende radio eller konto.

Bestem sammen med policyeieren, og verifiser deretter begge resultatene

Tre betingelser avgjør rettingen. Holder forutsetningskjeden med VPN slått av? Har klienten et støttet alternativ for lokal tilgang, og tillater policyen det? Og kan du verifisere endringen uten å svekke beskyttelsen tunnelen finnes for? Hvis det tredje svaret er nei, trenger endringen administratoren fremfor en omvei.

Etter en godkjent endring, bekreft begge resultatene: oppgaven fortsetter på den nærliggende enheten, og applikasjonene som trenger tunnelen beholder sin tiltenkte tilgang og blokkering.

Registrer unntaket ved siden av konfigurasjonen for den tilkoblingen, ellers fjerner den neste profiloppdateringen det lydløst.