Handoff holder op med at virke, når VPN'et forbinder: hvad du skal tjekke

Åbn en side på iPhone, gå hen til Mac'en, og Dock-ikonet vises ikke. Slå VPN'et fra, og det virker. Den sekvens ligner et VPN-problem, og det er det ofte, men ikke af den grund folk antager: Handoff er en lokal funktion mellem enheder, og tunnelen forstyrrer den lokale del, ikke internetdelen.

Ret én opgave og ét par enheder

Vælg én enkelt Handoff-kompatibel opgave, som en webside i Safari eller et udkast i Notes, og ét enkelt par enheder. Hold appen, konti og de fysiske placeringer uændrede, mens du ændrer én variabel ad gangen. En test, der flytter tre ting på én gang, giver en observation, du ikke kan bruge.

Handoff er opgavefortsættelse, ikke skærmdeling eller fildeling. Hvis kravet er at spejle en skærm eller montere en delt ressource, fejlfinder du en anden funktion med andre forudsætninger.

Skriv den præcise opgave ned, fordi verifikatoren for enhver rettelse er, at netop den opgave virker.

Forudsætningerne er lokale, ikke eksterne

Apples krav til Handoff er kompatible enheder i nærheden, Wi-Fi og Bluetooth slået til på begge, samme Apple Account logget ind og Handoff slået til. Tjek den konto, der bruges til Continuity, og ikke den konto, der købte en app, fordi de kan være forskellige på en delt Mac. Bekræft derefter, at appen og opgaven faktisk understøtter Handoff, da en vilkårlig app, der står åben, ikke beviser noget. De tjek er billige, og de er de første, der skal udelukkes.

Det hele sker over lokale radioer. Bluetooth annoncerer aktiviteten, og Wi-Fi bærer nyttelasten, og derfor skal enhederne være tæt på hinanden, selv når begge har internetadgang.

Intet af det afhænger af den offentlige adresse, som en af enhederne bruger.

Hvad VPN-klienten gør ved lokal trafik

En fuldtunnel-klient kan fange det lokale subnet sammen med alt andet, og nogle klienter gør præcis det, medmindre du tillader lokal netværksadgang. Apple advarer om, at VPN-konfigurationer, der forhindrer lokalt netværk, kan forstyrre Continuity-funktioner. Det er en udtalelse om klientens politik, ikke om én bestemt blokeret port.

Mange klienter har en undtagelse for lokal adgang; læs, hvad den tillader, før du aktiverer den, og foretræk leverandørens understøttede mulighed frem for at redigere firewallregler manuelt.

Hvis klienten ikke har en sådan mulighed, tilhører designbeslutningen den, der ejer udrulningen.

Hvad en delt udgang ikke giver dig

To enheder, der bruger den samme VPN-server, deler en udgangsadresse, og det er alt, de deler. Det skaber ikke Bluetooth-annoncen, det sætter dem ikke på samme lokale link, og det retter ikke en uoverensstemmende Apple Account. At behandle en fælles offentlig adresse som forudsætning er en kategorifejl, der fører til unødvendige klientændringer.

Abonnentisolering på VPN-tjenesten er også et andet spørgsmål end to nærliggende enheder, der fortsætter en opgave, så at åbne videresendelse mellem abonnenter er ikke et Handoff-trin.

Et routerbaseret VPN ændrer, hvilken politik der gælder for enhederne, og det leverer stadig ikke en manglende radio eller konto.

Beslut sammen med politikejeren, og verificér derefter begge resultater

Tre betingelser afgør rettelsen. Holder forudsætningskæden med VPN'et slået fra? Har klienten en understøttet mulighed for lokal adgang, og tillader politikken den? Og kan du verificere ændringen uden at svække den beskyttelse, som tunnelen findes for? Hvis det tredje svar er nej, kræver ændringen administratoren frem for en omvej.

Efter en godkendt ændring skal du bekræfte begge resultater: opgaven fortsætter på den nærliggende enhed, og de applikationer, der har brug for tunnelen, beholder deres tilsigtede adgang og blokering.

Registrér undtagelsen ved siden af den forbindelses konfiguration, ellers fjerner den næste profilopdatering den lydløst.