Beïnvloed ’n VPN Wi-Fi Calling op die iPhone? Kyk na die netwerk se kant

Sluit by ’n hotelnetwerk aan, maak een oproep uit die Phone-program en maak dan ’n blaaier oop en kyk hoe dit die VPN se uitgangsadres rapporteer eerder as die hotel s’n: drie waarnemings wat teenstrydig lyk en gewoonlik nie is nie. Wi-Fi Calling via die netwerk word op jou lyn deur jou selfoonoperateur voorsien, terwyl ’n VPN net ’n roeteringslaag is vir die data wat jou toestel stuur. Om ’n publieke-IP-blad as bewys oor ’n telefoonoproep te lees, is die vinnigste manier om ’n middag aan die verkeerde instelling te spandeer. Nie een van die twee dienste kan uit die ander se simptoom beoordeel word nie, en die volgorde waarin jy hulle nagaan, verander die antwoord.

Die mite dat een tonnel elke oproep dra

Sodra die VPN konekteer, is die intuisie dat alles wat die selfoon stuur nou deur die verskaffer se bediener verlaat, stem ingesluit. Data volg wel die roetes wat die tonnel installeer, maar ’n netwerk-stemdiens is nie by verstek een van daardie roetes nie: die operateur se kernnetwerk lewer dit, en die tonnel vervang nooit daardie kern nie. Die Phone-program se Wi-Fi Calling-modus is ’n aanbod wat aan jou intekenaarlyn gekoppel is. ’n Verbruiker-VPN-profiel kan dit nie voorsien nie, en dit kan dit ook nie herroep nie.

Oproepe wat binne ’n boodskap- of besigheidsprogram gemaak word, is ’n ander produk. So ’n program dra sy eie rekening, sy eie bedieners en sy eie mediapad, so daardie oproepe reis gewoonlik binne die tonnel en kan breek wanneer die tonnel breek. Om ’n mislukte oproep as lynvlakdiens of appvlakrekening te sorteer voordat jy enige instelling aanraak, verwyder die meeste van die raaiwerk.

Is Wi-Fi Calling werklik op hierdie lyn voorsien?

Voordat enige VPN-vraag ter sprake kom, bevestig dat jou netwerk en toestel die funksie ondersteun en dat dit aangeskakel is vir die spesifieke lyn wat jy toets. Apple se gids vir die opstel van Wi-Fi Calling verduidelik die netwerkspesifieke aktiveringspad en die status wat die selfoon wys sodra die lyn aktief is. Wanneer daardie status afwesig is, of jou netwerk nooit in die lys verskyn nie, is die VPN nie die ding om te ondersoek nie.

Volg dit met een gewone oproep na ’n nommer wat jy beheer, en let op die statusaanwyser terwyl die oproep konekteer. ’n Selfoon wat wys Wi-Fi is gekoppel, het net bewys dat die dataskakel op is; dit het nie bewys watter netwerk die klank gedra het nie. Moet nooit ’n noodoproep maak as ’n manier om te sien hoe die klank gerouteer word nie, en moet nooit ’n stemoproep binne ’n boodskapprogram as bewyse oor die netwerkfunksie beskou nie. Dit is afsonderlike dienste met afsonderlike foutmodusse, en die een sê niks oor die ander nie.

As die simptoom net verskyn terwyl die VPN geaktiveer is, hou die lyn, die Wi-Fi-netwerk en die oproepteken konstant en verander een enkele veranderlike per lopie. Op ’n bestuurde selfoon is ’n vergelykende lopie met die profiel verwyder net regmatig wanneer die administrateur vooraf daartoe ingestem het.

Waar IncludeAllNetworks en ExcludeCellularServices inpas

Die IKEv2-lading binne ’n toestelbestuursprofiel dra twee sleutels wat hierdie verdeling bepaal. IncludeAllNetworks is die skakelaar wat alle toestelverkeer in die tonnel instoot eerder as net wat die VPN-program toevallig vang. Sodra dit gestel is, ExcludeCellularServices kan internet-routeerbare diensverkeer weer uit die tonnel sny, en Wi-Fi Calling is een van die dienste wat daardie uitsondering noem. Verkeer wat ’n netwerk reguit in sy eie kern stuur, nooit oor die publieke internet nie, bly buite die tonnel ongeag wat daardie twee sleutels sê.

Sleutels beskryf wat ’n profiel kan uitdruk, nie wat jou verskaffer werklik verskeep het nie. ’n Profiel wat ExcludeCellularServices weglaat, kan die funksie binne die tonnel hou, en ’n verskaffer wat geen bewerkbare skakelaar blootlê nie, kan jou met geen gebruikersgerigte beheer laat nie. Die artefak wat dit beslis, is die lading wat jy geïnstalleer het, en jou administrateur kan dit woordeliks vir jou teruglees.

Waarom ’n publieke-IP-blad nie ’n oproep kan naspoor nie

’n Blad wat die VPN se uitgangsadres rapporteer, het een HTTP-versoek van een program op een oomblik gemeet. Dit sê niks oor die koppelvlak wat ’n stemoproep gebruik het nie, en ’n oproep wat konekteer sê niks oor of die tonnel gesond is vir ander verkeer nie. Om een as ’n proxy vir die ander te gebruik, lewer gevolgtrekkings wat selfversekerd klink en verkeerd is.

Hou die privaatheidkant ewe konkreet: die operateur hou steeds jou intekenaarrekord en lewer steeds die lyndiens, so ’n ander web-uitgang skei jou nie van daardie rekening nie. ’n VPN herskryf paaie vir verkeer wat dit vang; dit skuif nie ’n selfoonlyn na ’n ander netwerk nie.

’n Diagnosevolgorde wat jou beleid ongeskonde hou

Begin by die lyn: funksie geaktiveer, netwerk gelys, aanwyser teenwoordig, een gewone oproep gemaak. Kyk dan na die profiel en vra of IncludeAllNetworks aan is en waarop ExcludeCellularServices gestel is. Eers wanneer albei skoon terugkom, verdien die tonnel self jou aandag.

Skryf die resultaat neer wat jy eintlik wou hê: ’n toegelate selfoonfunksie wat werk, met ’n bekende omvang vir die tonnel. Daardie antwoord oorleef ’n netwerkopdatering, ’n nuwe netwerk of ’n hersiene profiel, terwyl ’n raaiskoot oor pakkette niks oorleef nie. As jy die profiel administreer, lees die stemdiens-uitsonderings langs die verkeersblokkeringsreëls in dieselfde lading, want die twee werk op mekaar in. As jy die gebruiker is, is die netwerk se ondersteuningskanaal en jou VPN-verskaffer se gedokumenteerde gedrag die twee bronne wat die moeite werd is om in ’n kaartjie aan te haal.