Wat doen IncludeAllNetworks in 'n IKEv2-profiel op 'n Mac?

In 'n inheemse IKEv2-profiel is die interessante sleutel nie 'n merkblokkie nie, dit is IncludeAllNetworks, en wat dit verander is die omvang van wat die stelsel buite die tonnel mag stuur. Stel dit op 1 en macOS behandel die tonnel as die pad vir in wese alle IP-verkeer, minus 'n stel uitsonderings wat dit definieer en jy mag uitbrei. Omdat dit in 'n profielwoordeboek woon eerder as in 'n kieslys, beteken dit ook nie wat die meeste mense aanneem wanneer hulle die frase stuur alle verkeer lees nie.

Wat die sleutel binne die netwerkstapel verander

Sonder dit gedra die tonnel hom soos 'n netwerkkoppelvlak met roetes wat aangeheg is. 'n Verstekroete deur daardie koppelvlak vang die meeste verkeer, en enige meer spesifieke roete op 'n ander koppelvlak wen steeds vir sy eie voorvoegsel. Dit is normale roetering, en dit is hoekom gesplete tonneling amper per ongeluk gebeur.

Met die sleutel geaktiveer, hou die omvang op om 'n roeteringsvoorkeur te wees en word dit 'n beleid oor watter verkeer toegelaat word om deur enigiets anders as die tonnel te vertrek. Die stelsel moet steeds die netwerk bereik om die verbinding aan die lewe te hou, so die beleid kom saam met uitsonderings eerder as om voor te gee dat hulle nie bestaan nie. Om dit te aktiveer laat nooit die masjien sonder enige werkende pad nie. Wat jy kry is 'n korter lys paaie as wat jy aangeneem het, en daardie lys is gedokumenteer.

Die praktiese gevolg is dat die byvoeging van 'n roete nie meer die uitkoms verduidelik nie. As 'n bestemming steeds direk bereik word, is die vraag om te vra nie watter roete gewen het nie, maar of 'n uitsondering dit dek.

Die uitsonderings is deel van die instelling

Apple dokumenteer verskeie uitsluitings langs die hoofsleutel, wat plaaslike netwerke, Apple Push Notification-verkeer, sellulêre dienste en toestelkommunikasie dek. Elkeen het sy eie platform- en weergawetoestande, so dieselfde profiel kan oor macOS-weergawes anders gedra.

Sommige van daardie uitsluitings is intrinsiek. Verkeer wat nodig is om netwerktoegang te vestig en te onderhou, insluitend hantering van captive portals, moet toegelaat word, anders kan die masjien aan niks gekoppel eindig en dit nie kan regstel nie.

Dan kom die doelbewuste keuses. Om 'n tuisdrukker toe te laat is nie dieselfde besluit as om 'n werkbron-voorvoegsel toe te laat nie, en beide verskil van om APNs bereikbaar te laat sodat kennisgewings bly aankom. Teken aan watter jy geaktiveer het, in die profiel self, eerder as om dit later uit 'n foutverslag te ontdek.

Waarom dit nie dieselfde as 'n verstekroete is nie

'n Verstekroete is 'n roetertabel-inskrywing, en roetertabelle verloor. 'n Meer spesifieke voorvoegsel klop dit, 'n toepassing-omvang verbinding kan dit omseil, en 'n tweede koppelvlak met 'n beter maatstaf kan oorneem sonder dat iemand aan die VPN-konfigurasie raak.

Apple se roeteringsriglyne maak die onderskeid eksplisiet: gewone verstekke kan deur meer spesifieke roetes oorheers word, terwyl die breër omvang-instelling definieer watter verkeer die tonnel moet dra en wat daaruit uitgekap word. Een is 'n voorkeur, die ander is nader aan 'n reël.

Daardie verskil verander ook hoe jy 'n lek diagnoseer. Met 'n verstekroete ondersoek jy roetes en maatstawwe. Met die omvang-sleutel ondersoek jy die profielweergawe, die geïnstalleerde uitsonderings en die weergawe-spesifieke gedrag, want die roetertabel is stroomaf van 'n besluit wat vroeër geneem is.

EnforceRoutes is 'n ander knop

EnforceRoutes klink soos die streng weergawe van dieselfde idee, en mense stapel die twee in die oortuiging dat meer sleutels meer dekking beteken. Apple dokumenteer dat dit geïgnoreer word wanneer IncludeAllNetworks geaktiveer is, so die tweede sleutel koop niks in daardie kombinasie nie.

Behandel dit as 'n alternatief vir konfigurasies wat nie die breër omvang gebruik nie, nie as versterking nie. As jy nie kan verduidelik wat elke sleutel op sy eie doen nie, maak die byvoeging van beide net die profiel moeiliker om na te gaan.

Waaroor die gateway en die profieleienaar moet saamstem

'n Kliëntinstelling kan nie 'n bediener verkeer laat deurstuur wat dit nooit gekonfigureer is om deur te stuur nie. Die gateway moet die sessie aanvaar, adresse uitdeel, 'n terugpad verskaf vir die voorvoegsels wat jy wil bereik, en DNS lewer in watter reëling jy ook al gekies het. As dit net een voorvoegsel routeer, produseer die breë kliëntomvang verkeer wat aankom en sterf. Een versoek na 'n bestemming buite die gateway se roetes bewys dit binne 'n minuut.

'n Toepassing-besitte tonnel is weer 'n aparte geval. Die verskaffer moet die ondersteunde gedrag implementeer of blootstel; die installering van 'n tweede inheemse IKEv2-profiel verander nie 'n tonnel wat 'n ander toepassing reeds bestuur nie, en 'n IKEv2-sleutel is nie 'n OpenVPN-richtlijn wat een of ander ander kliënt sal lees nie.

Vir die huidige sleutellys en weergawetoestande, lees Apple se IKEv2-nutsaamheidsverwysing eerder as 'n profiel wat iemand jare gelede gekopieer het.

Aanvaar 'n profielweergawe as 'n geheel

Voordat jy 'n afstand-beheerde Mac verander, skryf die teiken-macOS-weergawes neer, die beoogde internet-uitgang, die privaat voorvoegsels wat bereikbaar moet bly, en elke uitsluiting wat jy aktiveer. Bewaar dan 'n herstelpad wat nie afhanklik is van die tonnel wat jy op die punt is om te verander nie.

Toets nuwe openbare versoeke, privaat versoeke, beide adresfamilies en naamresolusie, en kontroleer die geïnstalleerde weergawe eerder as die ontwerpdocument. As iets steeds direk gaan, besluit of dit 'n gedokumenteerde uitsondering, 'n ander verbindingkonteks of 'n werklike konfigurasiefout is, en verander een van daardie drie eerder as om onverwante sleutels te verbreed.