Maaaring may naka-install na VPN tunnel, filter ng content, at iCloud Private Relay nang sabay sa Mac mo, at wala sa mga ito ang nagsasabi kung alin ang humuhubog sa isang partikular na koneksyon. Magkamukha ang mga panel ng settings, magkamukha ang mga icon, at halos lahat ng vendor ay tinatawag na seguridad ng network ang produkto nila. Tatlong katotohanan ang naghihiwalay sa kanila: kung lumalabas ba ang trapiko sa isang malayong endpoint na kayang pangalanan, kung may policy engine bang nagpapasya ng payagan-o-itakwil sa bawat daloy, at kung sa Safari ba natatapos ang proteksyon. Ayusin ang tatlong ito at ang karamihan ng tanong na bukas-ba-ang-VPN-ko ay sasagutin ng sarili nila.

Tatlong kondisyon na kumikilala sa bahagi

Ang unang kondisyon ay ang labasan. Ipinapasa ng provider ng tunnel ang mga packet sa isang malayong gateway, kaya nagbabago ang pampublikong address mo at, kung sinasabi ng profile, nagiging maabot ang mga host sa likod ng gateway na iyon. Kung hindi kailanman nagbabago ang address at walang pribadong subnet na bumubukas, hindi ka tumitingin sa gumaganang tunnel, ano man ang sabihin ng menu bar.

Ang ikalawang kondisyon ay ang desisyon. Sinusuri ng filter ng content ang mga daloy at nagbabalik ng payagan o itakwil. Maaari nitong ipatupad ang pagharang ng kategorya, patakaran kada app, o patakarang ipinadala ng employer, at naitala nito ang hatol. Ang hindi nito kaya nang mag-isa ay bigyan ng lugar na pupuntahan ang trapiko.

Ang ikatlong kondisyon ay ang saklaw. Pinoprotektahan ng Private Relay ang isang takdang bahagi ng pagba-browse at hindi ang buong device, at ang trabaho nito ay paghiwalayin kung sino ka sa kung ano ang binibisita mo, hindi ka ilagay sa ibang network.

Ilagay ang tatlo nang magkatabi at mahirap palampasin ang mga hangganan:

LayerQuestion it answersEvidence to look forWhat it does not do
VPN tunnel providerWhere does my traffic emerge, and which private networks can I reach?Changed public address, a connected service, a default route through a utun interfaceEnforce per-app content policy
Content filterMay this flow proceed, and who decided?A filter extension in Network Extensions, drop verdicts, an MDM profileSupply a different public exit
iCloud Private RelayCan the local network see which sites Safari loads?A relay egress address in Safari only, the relay toggle in iCloud settingsCover other apps or grant access to a private subnet

Ang filter ng content ay policy engine, hindi labasan

Sa macOS dumarating ang filter bilang Network Extension na itinayo sa filter data provider class ng Apple, NEFilterDataProvider. Sa pinamamahalaang deployment, itinutulak ito ng MDM, ini-install bilang system extension, at isang beses na inaprubahan sa System Settings > General > Login Items and Extensions. Mula noon nakikita nito ang mga TCP flow, at sa ilang configuration pati UDP, at nagbabalik ng hatol sa bawat isa.

Ang paraan ng pagpalya ang nakakalito sa mga tao. Ang filter na nagtatakwil ng daloy ay gumagawa ng timeout, natigil na TLS handshake, o reset, na kamukhang-kamukha ng tunnel na umangat pero hindi makapagpadala ng trapiko. Hindi nagbago ang pampublikong address dahil wala talagang labasang nagbago nito.

Madalas pagsamahin ng mga komersyal na kliyente ang dalawang tungkulin. Isang installer lang ang nagdadala ng provider ng tunnel at filter, ang filter ang humaharang at ang tunnel ang nagruruta. Kaya wala kang malalaman sa pangalan ng app tungkol sa kung aling bahagi ang tumanggi sa koneksyon. Tingnan ang listahan ng extension, pagkatapos ang konektadong serbisyo, pagkatapos ang log ng kliyente, sa ganoong pagkakasunod-sunod.

Sinasaklaw ng Private Relay ang Safari, hindi ang buong makina

Ipinapadala ng Private Relay ang pagba-browse na sinasaklaw nito sa dalawang relay na pinapatakbo ng magkahiwalay na partido, kaya walang nag-iisang operator ang may hawak ng pagkakakilanlan at destinasyon mo nang sabay. Disenyo ito ng privacy, hindi tunnel: walang gateway na mapapasok, walang pribadong subnet, at walang paraan para i-pin ang address ng labasan sa bansang pipiliin mo.

Sadyang makitid ang saklaw nito: sinasaklaw ang pagba-browse sa Safari kasama ang mga DNS query at hindi secure na HTTP load na kasama nito. Ang terminal session, mail client, chat app, at game launcher ay nasa labas nito. Kung ang pagsusuri sa Terminal ay nagpapakita pa rin ng address ng access network mo habang ang Safari ay nagpapakita ng relay address, iyon ang inaasahang resulta, hindi sirang install.

May kondisyon ang pagiging available. Kailangan ng iCloud+ plan, hindi ito inaalok sa bawat rehiyon, at maaaring harangin ng pinamamahalaang network ang access sa relay, at sa ganoong kaso babalik ang Safari sa direktang koneksyon. Ang pangkalahatang-tanaw ng Private Relay ng Apple ang sanggunian para sa kasalukuyang saklaw. Kapag konektado ang VPN profile at dinadala ang trapikong iyon, hindi nakapatong ang relay dito; ang profile ang nagpapasya ng landas.

Basahin ang ebidensya sa tamang pagkakasunod-sunod

Simulan sa estado ng serbisyo, dahil iyon ang pinakamurang senyales. Ipiniprint ng scutil --nc list ang mga naka-configure na serbisyo ng VPN at kung konektado ang bawat isa. Maaaring manatili doon ang isang profile nang maraming taon nang hindi kailanman kumokonekta, at kinukuwenta ito ng mga tao bilang tunnel.

Tingnan pagkatapos ang mga interface at ruta. Ipinapakita ng ifconfig ang mga utun interface, pero kakaunti ang pinapatunayan ng pag-iral lang nila, dahil ginagamit ng macOS ang utun para sa iba't ibang layunin bukod sa VPN. Ang mahalaga ay kung ang default route ay papasok sa isa sa kanila, na iniuulat ng route -n get default.

Para sa resolution ng pangalan, inililista ng scutil --dns ang mga resolver na aktuwal na gagamitin ng system, at doon lumilitaw ang provider ng DNS proxy. Ang paghahambing ng dig +short example.com sa dig +short example.com @1.1.1.1 ang naghihiwalay sa resolver na sumasagot mula sa resolver na hinaharang.

Umaabot ang aktibidad ng extension sa pinag-isang log: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Hinahanap mo kung aling extension ang nagsimula at kung may iniulat na hatol ang filter sa daloy na mahalaga sa iyo, hindi isang linyang dapat sauluhin.

Paliitin ang sintomas bago magpatay ng kahit ano

Uriin muna ang pagpalya. Ang pangalang hindi ma-resolve, koneksyong agad tinanggihan, at koneksyong nakabitin hanggang timeout ay tatlong magkaibang obserbasyon na may tatlong magkaibang may-ari. Ang resolution ay tumuturo sa resolver o DNS proxy. Ang agarang pagtanggi ay tumuturo sa panuntunan ng filter. Ang katahimikan ay karaniwang tumuturo sa routing, o sa tunnel na nakataas pero hindi nagpapasa.

Sa pinamamahalaang Mac, ipagpalagay na pag-aari ng organisasyon ang filter. Ang pagpatay nito para subukan ang VPN ay nagtatanggal ng eksaktong bahaging gusto mong obserbahan, at madalas itong ibalik ng MDM sa susunod na pagsusuri. Tanungin ang administrator sa pangalan ng patakaran bago magbago ng kahit ano, at subukan gamit ang partikular na app na pumalya kaysa sa buong system.

Isa pang patibong: ang pagpatay ng Private Relay para subukan ang VPN ay walang sinasabi tungkol sa dayuhang trapiko, dahil hindi kailanman sinaklaw ng relay ang trapikong iyon. Bawat layer ay dapat subukan sa app na aktuwal na pinamumunuan nito.

Daanan ang listahang ito at huminto sa unang item na pumapalya:

  • Ipinapakita ba ng scutil --nc list ang serbisyong inaasahan mo bilang konektado?
  • Naiiba ba ang pampublikong address na nakikita mula sa Terminal sa address na ibinigay ng access network mo?
  • May naka-install bang extension ng filter, at nagtala ba ito ng hatol para sa daloy na pumapalya?
  • Sa Safari lang ba ang pagpalya? Kung oo, tingnan ang saklaw ng relay bago sisihin ang tunnel.

Kung pumasa ang apat at pumapalya pa rin ang app, nasa itaas ng network layer ang problema: mga setting ng proxy, tiwala sa certificate, o listahan ng pinapayagan sa antas ng app.

Kaugnay na mga artikulo