FaceTime virker, men din Mac kan ikke ringe via din iPhone

Du kan starte et FaceTime-lydopkald fra din Mac uden problemer og derefter ringe til en VVS-mand fra samme Mac, og der sker intet. Den sædvanlige læsning er, at netværket er sundt, og at noget urelateret er gået i stykker. Den læsning er myten, og den overlever mest, fordi FaceTime ser ud som en fair test.

Det er den ikke. FaceTime-lyd og telefonrelay er separate transportveje med separate krav, og den ene overlever en tunnel, som den anden ikke kan krydse.

VPN er heller ikke skyldig på forhånd. Rækkefølgen nedenfor fjerner begge antagelser, før du rører en anden indstilling.

FaceTime, der virker, fortæller dig næsten intet

FaceTime-lyd forhandler en forbindelse til en tilgængelig modpart. Den trafik kan krydse internettet, også gennem en VPN med fuld tunnel, så længe begge ender kan udveksle pakker. Telefonrelay forlader ikke bygningen. Din Mac beder en iPhone i nærheden om at placere opkaldet på sin mobilforbindelse, og den anmodning er lokal.

Så et velfungerende FaceTime-opkald beviser, at Macen har brugbart internet og kan nå Apples tjenester. Det siger intet om, hvorvidt Macen kan se den iPhone, der står ved siden af. To enheder kan dele det samme SSID og stadig være usynlige for hinanden.

Det er hele myten på én linje: intet opkald, der forlader bygningen, tester den lokale forbindelse.

Hvad relay-vejen faktisk kræver

Hvert punkt på Apples liste er obligatorisk, ikke additivt. Begge enheder på samme Wi-Fi-netværk, begge logget ind på samme Apple-konto, begge logget ind på FaceTime med telefonnummeret aktiveret, og Opkald på andre enheder slået til for den Mac, du vil bruge. Apples vejledning til iPhone-opkald er referencen for den nuværende formulering.

På en nyere iPhone sidder kontakten under Indstillinger, Apps, Telefon, Opkald på andre enheder, og din Mac skal optræde på den liste og være aktiveret. Når Macen første gang prøver at bruge forbindelsen, spørger macOS, om der må ringes fra den iPhone. Afviser du den meddelelse én gang, forbliver funktionen stille i stykker, fordi intet spørger igen.

Macsiden afhænger af systemversionen. Nyere macOS-udgivelser leverer en Telefon-app, ældre sender opkald gennem FaceTime. Hvis en vejledning peger på en menu, du ikke kan finde, så tjek versionen, før du beslutter, at en indstilling mangler.

Hvor en VPN virkelig forstyrrer

En VPN-klient kan ødelægge relay på tre forskellige måder, og kun den første er dokumenteret. Det dokumenterede tilfælde er en konfiguration, der forhindrer lokalt netværk: macOS advarer om, at en sådan VPN kan forstyrre Continuity-funktioner, og relay er en Continuity-funktion. Den anden er en fuld tunnel, der opsnapper den trafik, Macen ville bruge til at nå iPhone, så den lokale anmodning forlader mod en gateway, der ikke har brug for den. Den tredje er en klient, der anvender sin egen filtrering eller sit eget kill switch på hver grænseflade i stedet for kun på tunnelen.

En delt tunnel, der kun bærer virksomhedsundernet, lader normalt den lokale vej være. Derfor kan den samme Mac bestå på én VPN-profil og fejle på en anden, og forskellen mellem de to profiler er det nyttige signal.

Vær streng om, hvad sammenligningen beviser. At virke uden VPN og fejle med den er en interaktion, ikke en diagnose. Den navngiver ikke den protokol, port eller grænseflade, der blev blokeret, og at opfinde ruter alene ud fra det gør den næste test værdiløs.

Tre fejl, der får skylden for VPN'en

Wi-Fi-opkald. Det er en operatørfunktion på iPhone, ikke noget Macen arver. Den lader telefonen bruge operatørens tjeneste over Wi-Fi, ikke alle operatører tilbyder den, og den er ubrugelig, når iPhone er slukket, uden for rækkevidde eller på et netværk, der blokerer operatørens endepunkter. Hvis dit egentlige krav er at ringe, mens iPhone bliver hjemme, var relay den forkerte mekanisme at teste fra starten.

Netværksisolering. Gæstenetværk, klientisolering på et accesspunkt og separate VLAN'er giver præcis relay-symptomet: samme SSID og ingen synlighed, uden nogen VPN i billedet. Hvis bygningens Wi-Fi isolerer klienter, ændrer ingen indstilling på din Mac resultatet.

Handoff. Handoff fortsætter en aktivitet mellem enheder. Det giver ikke din Mac en mobilforbindelse, og det er ikke en erstatningstest. At se Handoff-ikonet dukke op fortæller dig faktisk, at de to enheder kan finde hinanden, hvilket er værd at vide, men det stopper langt fra at bevise, at opkaldsrouting virker.

En testrækkefølge, der giver bevis

Start fra en kendt tilstand: iPhone låst op og i nærheden, begge enheder på samme Wi-Fi, VPN afbrudt på Macen. Foretag ét udgående opkald og modtag ét indgående. Begge retninger betyder noget, fordi de fejler af forskellige grunde. Udgående afhænger af, at Macen når forbindelsen, mens indgående afhænger af, at iPhone behandler den Mac som et gyldigt mål.

Tilslut VPN'en igen med den profil, du faktisk arbejder med, og gentag begge opkald uden at ændre noget andet. Hvis begge stadig virker, er VPN'en ikke din variabel, og du bør holde op med at justere den. Hvis begge går i stykker, så noter profilnavnet, klientversionen og om lokal trafik er udelukket, og giv de tre fakta til den, der ejer konfigurationen.

Hvis kun én retning fejler, så se på iPhone'ens opkaldsindstillinger før tunnelen. Asymmetrisk fejl er langt oftere en kontakt pr. enhed end et routingproblem, og den ene observation sparer en eftermiddag.

Hvad du skal bekræfte, før du eskalerer

Gå disse fem punkter igennem i rækkefølge og skriv svaret på hvert: samme Wi-Fi-netværk, samme Apple-konto, telefonnummer aktiveret i FaceTime, denne Mac aktiveret under Opkald på andre enheder, og macOS-tilladelsesmeddelelsen accepteret. Alt, du ikke kan bekræfte, er en gratis mulig årsag.

Beslut derefter, hvad du optimerer for. Hvis opkald kun skal virke ved dit skrivebord, er det som regel nok at udelukke lokal trafik fra VPN-profilen, og det svækker ikke tunnelens formål. Hvis de skal virke, mens iPhone er et andet sted, er relay den forkerte funktion, og operatørspørgsmålet kommer først.