Handoff slutar fungera när VPN ansluter: vad du bör kontrollera

Öppna en sida på iPhone, gå fram till Macen, och Dock-ikonen visas inte. Stäng av VPN och det fungerar. Den sekvensen ser ut som ett VPN-problem, och det är det ofta, men inte av skälet folk antar: Handoff är en lokal funktion mellan enheter, och tunneln stör den lokala delen, inte internetdelen.

Åtgärda en uppgift och ett par enheter

Välj en enda Handoff-kompatibel uppgift, som en webbsida i Safari eller ett utkast i Notes, och ett enda par enheter. Håll appen, kontona och de fysiska positionerna oförändrade medan du ändrar en variabel i taget. Ett test som flyttar tre saker samtidigt ger en observation du inte kan använda.

Handoff är uppgiftsfortsättning, inte skärmspegling eller fildelning. Om kravet är att spegla en skärm eller montera en delning felsöker du en annan funktion med andra förutsättningar.

Skriv ned den exakta uppgiften, eftersom verifieringen av varje åtgärd är att samma uppgift fungerar.

Förutsättningarna är lokala, inte avlägsna

Apples krav för Handoff är kompatibla enheter i närheten, Wi-Fi och Bluetooth påslaget på båda, samma Apple Account inloggat och Handoff påslaget. Kontrollera kontot som används för Continuity och inte kontot som köpte en app, eftersom de kan skilja sig på en delad Mac. Bekräfta sedan att appen och uppgiften faktiskt stöder Handoff, eftersom en godtycklig app som står öppen inte bevisar något. Dessa kontroller är billiga, och de är det första som ska uteslutas.

Allt detta sker över lokala radio. Bluetooth annonserar aktiviteten och Wi-Fi bär nyttolasten, därför måste enheterna vara nära varandra även när båda har internetåtkomst.

Inget av detta beror på den offentliga adress som någon av enheterna använder.

Vad VPN-klienten gör med lokal trafik

En fulltunnelklient kan fånga det lokala subnätet tillsammans med allt annat, och vissa klienter gör precis det om du inte tillåter lokal nätverksåtkomst. Apple varnar för att VPN-konfigurationer som hindrar lokalt nätverk kan störa Continuity-funktioner. Det är ett uttalande om klientens policy, inte om en specifik blockerad port.

Många klienter erbjuder ett undantag för lokal åtkomst; läs vad det tillåter innan du aktiverar det, och föredra leverantörens stödda alternativ framför att redigera brandväggsregler manuellt.

Om klienten inte har det alternativet tillhör designbeslutet den som äger utrullningen.

Vad en delad utgång inte ger dig

Två enheter som använder samma VPN-server delar en utgångsadress, och det är allt de delar. Det skapar inte Bluetooth-annonsen, det placerar dem inte på samma lokala länk och det åtgärdar inte ett Apple Account som inte stämmer. Att behandla en gemensam offentlig adress som förutsättning är ett kategorifel som leder till onödiga klientändringar.

Abonnentisolering i VPN-tjänsten är också en annan fråga än två närliggande enheter som fortsätter en uppgift, så att öppna vidarebefordran mellan abonnenter är inte ett Handoff-steg.

En routerbaserad VPN ändrar vilken policy som gäller för enheterna, och den levererar fortfarande inte en saknad radio eller ett konto.

Bestäm tillsammans med policyägaren och verifiera sedan båda resultaten

Tre villkor avgör åtgärden. Håller förutsättningskedjan med VPN avstängt? Har klienten ett stött alternativ för lokal åtkomst, och tillåter policyn det? Och kan du verifiera ändringen utan att försvaga det skydd som tunneln finns för? Om det tredje svaret är nej behöver ändringen administratören i stället för en omväg.

Efter en godkänd ändring, bekräfta båda resultaten: uppgiften fortsätter på den närliggande enheten, och applikationerna som behöver tunneln behåller sin avsedda åtkomst och blockering.

Registrera undantaget bredvid konfigurationen för den anslutningen, annars tar nästa profiluppdatering bort det tyst.