Beïnvloedt een VPN Wi-Fi-bellen op de iPhone? Controleer de kant van de provider

Maak verbinding met een hotelnetwerk, voer één gesprek uit de Phone-app en open dan een browser en zie dat die het exitadres van de VPN meldt in plaats van dat van het hotel: drie waarnemingen die tegenstrijdig lijken en dat meestal niet zijn. Wi-Fi-bellen van de provider wordt door je mobiele aanbieder op je lijn ingericht, terwijl een VPN alleen een routeringslaag is voor de gegevens die je apparaat verstuurt. Een openbare IP-pagina lezen als bewijs over een telefoongesprek is de snelste manier om een middag aan de verkeerde instelling te besteden. Geen van beide diensten kan worden beoordeeld op het symptoom van de andere, en de volgorde waarin je ze controleert verandert het antwoord.

De mythe dat één tunnel elk gesprek draagt

Zodra de VPN verbindt, zegt de intuïtie dat alles wat de telefoon verstuurt nu via de server van de aanbieder naar buiten gaat, stem inbegrepen. Data volgt inderdaad de routes die de tunnel installeert, maar een spraakdienst van de provider is standaard niet een van die routes: het corenetwerk van de provider levert die, en de tunnel vervangt dat corenetwerk nooit. De Wi-Fi-belmodus van de Phone-app is een aanbod dat aan je abonneelijn hangt. Een consumenten-VPN-profiel kan die niet inrichten en kan die ook niet intrekken.

Gesprekken binnen een berichten- of zakelijke app zijn een ander product. Zo'n app heeft een eigen account, eigen servers en een eigen mediapad, dus die gesprekken reizen meestal binnen de tunnel en kunnen breken wanneer de tunnel breekt. Een mislukt gesprek indelen als dienst op lijnniveau of account op appniveau voordat je een instelling aanraakt, haalt het meeste giswerk weg.

Is Wi-Fi-bellen eigenlijk wel ingericht op deze lijn?

Controleer vóór elke VPN-vraag of je provider en toestel de functie ondersteunen en of die aanstaat voor de specifieke lijn die je test. Apples handleiding voor het instellen van Wi-Fi-bellen loopt de providerspecifieke activeerweg door en de status die de telefoon toont zodra de lijn actief is. Ontbreekt die status, of verschijnt je provider nooit in de lijst, dan is de VPN niet het ding om te onderzoeken.

Doe daarna één gewoon gesprek naar een nummer dat je beheert, en let op de statusindicator terwijl het gesprek verbindt. Een telefoon die Wi-Fi als verbonden toont, heeft alleen bewezen dat de datalink actief is; niet welk netwerk de audio droeg. Voer nooit een noodoproep uit om te zien hoe audio wordt gerouteerd, en beschouw een spraakgesprek in een berichtenapp nooit als bewijs over de providerfunctie. Dat zijn aparte diensten met aparte faalwijzen, en de ene zegt niets over de andere.

Als het symptoom alleen optreedt terwijl de VPN aanstaat, houd dan de lijn, het Wi-Fi-netwerk en het gespreksdoel constant en wijzig één variabele per run. Op een beheerde telefoon is een vergelijkingsrun zonder het profiel alleen legitiem wanneer de beheerder daar vooraf mee heeft ingestemd.

Waar IncludeAllNetworks en ExcludeCellularServices passen

De IKEv2-payload in een apparaatbeheerprofiel draagt twee sleutels die deze splitsing bepalen. IncludeAllNetworks is de schakelaar die al het verkeer van het apparaat de tunnel in duwt in plaats van alleen wat de VPN-app toevallig opvangt. Zodra die is ingesteld, ExcludeCellularServices kan internet-routeerbaar dienstverkeer weer uit de tunnel snijden, en Wi-Fi-bellen is een van de diensten die die uitzondering noemt. Verkeer dat een provider rechtstreeks zijn eigen core in routeert en nooit over het openbare internet gaat, blijft buiten de tunnel wat die twee sleutels ook zeggen.

Sleutels beschrijven wat een profiel kan uitdrukken, niet wat je aanbieder daadwerkelijk heeft geleverd. Een profiel dat ExcludeCellularServices weglaat, kan de functie binnen de tunnel houden, en een aanbieder die geen bewerkbare schakelaar toont, kan je helemaal zonder voor de gebruiker zichtbare controle achterlaten. Het document dat het beslist, is de payload die je hebt geïnstalleerd, en je beheerder kan die woord voor woord aan je voorlezen.

Waarom een openbare IP-pagina geen gesprek kan traceren

Een pagina die het exitadres van de VPN meldt, heeft één HTTP-verzoek van één app op één moment gemeten. Die zegt niets over de interface die een spraakgesprek gebruikte, en een gesprek dat verbindt zegt niets over of de tunnel gezond is voor ander verkeer. Het ene als vervanging voor het andere gebruiken levert conclusies op die zelfverzekerd klinken en onjuist zijn.

Houd de privacykant net zo concreet: de provider heeft nog steeds je abonneegegevens en levert nog steeds de lijndienst, dus een andere webuitgang ontkoppelt je niet van dat account. Een VPN herschrijft routes voor verkeer dat hij opvangt; hij verplaatst geen mobiele lijn naar een andere provider.

Een diagnosevolgorde die je beleid intact houdt

Begin bij de lijn: functie aan, provider in de lijst, indicator aanwezig, één gewoon gesprek gevoerd. Bekijk daarna het profiel en vraag of IncludeAllNetworks aanstaat en waarop ExcludeCellularServices is ingesteld. Pas wanneer beide schoon terugkomen, verdient de tunnel zelf je aandacht.

Schrijf het resultaat op dat je echt wilde: een toegestane telefoonfunctie die werkt, met een bekend bereik voor de tunnel. Dat antwoord overleeft een providerupdate, een nieuw netwerk of een herzien profiel, terwijl een gok over pakketten niets overleeft. Als je het profiel beheert, lees dan de uitzonderingen voor spraakdiensten naast de regels voor verkeersblokkering in dezelfde payload, omdat die twee elkaar beïnvloeden. Ben je de gebruiker, dan zijn het supportkanaal van de provider en het gedocumenteerde gedrag van je VPN-aanbieder de twee bronnen die het waard zijn om in een ticket te citeren.