Mac VPN, tartalomszűrő vagy Private Relay: melyik aktív
A Mac három hálózati rétege egyformán néz ki a Beállításokban. Különböztesse meg a VPN-t, a tartalomszűrőt és a Private Relayt a kilépési útvonal, a folyamatirány-elv és a böngészési hatókör alapján.
A Macén egyszerre lehet telepítve VPN-alagút, tartalomszűrő és iCloud Private Relay, és egyik sem jelzi, melyik alakítja az adott kapcsolatot. A beállítási panelek hasonlóak, az ikonok hasonlóak, és szinte minden gyártó hálózati biztonságnak nevezi a termékét. Három tény választja el őket: hogy a forgalom egy megnevezhető távoli végponton át lép-e ki, hogy egy házirend-motor engedélyez-vagy-elvet döntéseket hoz-e az egyes folyamokon, és hogy a védelem megáll-e a Safarinál. Ha ezt a hármat tisztázza, a legtöbb bekapcsolt-a-VPN-em kérdés magától megválaszolódik.
Három feltétel, amely azonosítja az összetevőt
Az első feltétel a kilépés. Az alagút-szolgáltató a csomagokat egy távoli átjárónak adja át, így a nyilvános címe megváltozik, és ha a profil így rendelkezik, az átjáró mögötti gazdagépek elérhetővé válnak. Ha a cím soha nem változik, és nem nyílik meg semmilyen privát alhálózat, nem működő alagutat lát, bármit is állít a menüsor.
A második feltétel a döntés. A tartalomszűrő kiértékeli a folyamokat, és engedélyez vagy elvet eredményt ad. Kényszeríthet kategóriablokkolást, alkalmazásonkénti szabályt vagy a munkáltató által küldött házirendet, és naplózhatja a döntést. Amit önmagában nem tud, az az, hogy helyet adjon a forgalomnak, ahová menjen.
A harmadik feltétel a hatókör. A Private Relay a böngészés meghatározott szeletét védi, nem az egész eszközt, és a feladata az, hogy elválassza, ki Ön attól, amit meglátogat, nem az, hogy más hálózatra helyezze.
Tegye őket egymás mellé, és a határok alig téveszthetők össze:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
A tartalomszűrő házirend-motor, nem kilépés
macOS-en a szűrő Network Extensionként érkezik, amely az Apple szűrőadat-szolgáltató osztályára, a NEFilterDataProviderre épül. Felügyelt telepítésben az MDM tolja ki, rendszerbővítményként települ, és egyszer jóváhagyják a System Settings > General > Login Items and Extensions alatt. Onnantól TCP-folyamokat lát, bizonyos konfigurációkban UDP-t is, és mindegyikre döntést ad vissza.
A hiba módja az, ami összezavarja az embereket. A folyamot elvető szűrő időtúllépést, elakadt TLS-kézfogást vagy visszaállítást okoz, ami pontosan úgy néz ki, mint egy felállt, de forgalmat átengedni nem tudó alagút. A nyilvános cím soha nem változott meg, mert soha nem volt kilépés, amely megváltoztatta volna.
A kereskedelmi kliensek gyakran mindkét szerepet egybeépítik. Egy telepítő hozza az alagút-szolgáltatót és a szűrőt, a szűrő blokkol, az alagút pedig irányít. Az alkalmazás neve tehát semmit nem mond arról, melyik összetevő utasította el a kapcsolatot. Ellenőrizze a bővítménylistát, majd a csatlakoztatott szolgáltatást, majd a kliensnaplót, ebben a sorrendben.
A Private Relay a Safarit fedi le, nem a gépet
A Private Relay a lefedett böngészést két, külön felek által üzemeltetett relayen keresztül küldi, így egyetlen üzemeltető sem birtokolja egyszerre az Ön személyazonosságát és úti céljait. Ez adatvédelmi tervezés, nem alagút: nincs átjáró, amelybe beléphetne, nincs privát alhálózat, és nincs mód arra, hogy egy általa választott országban kilépési címet rögzítsen.
Hatóköre szándékosan szűk: a Safari böngészését fedi le a hozzá tartozó DNS-lekérdezésekkel és nem biztonságos HTTP-betöltésekkel együtt. A terminál-munkamenet, a levelezőprogram, a csevegőalkalmazás és a játékindító kívül esik rajta. Ha a terminálban végzett ellenőrzés még a hozzáférési hálózatának címét mutatja, miközben a Safari relay-címet mutat, az a várt eredmény, nem hibás telepítés.
Az elérhetőség feltételes. iCloud+ csomag kell hozzá, nem minden régióban kínálják, és egy felügyelt hálózat blokkolhatja a relay-hozzáférést, amely esetben a Safari visszatér a közvetlen kapcsolatra. Az Apple Private Relay áttekintése a jelenlegi hatókör referenciája. Ha egy VPN-profil csatlakozva van és ezt a forgalmat viszi, a relay nem rakódik rá; az útvonalat a profil dönti el.
Olvassa a bizonyítékokat a megfelelő sorrendben
Kezdje a szolgáltatás állapotával, mert ez a legolcsóbb jel. A scutil --nc list kiírja a beállított VPN-szolgáltatásokat és azt, hogy melyik csatlakozik. Egy profil évekig ott ülhet anélkül, hogy valaha csatlakozna, és az emberek rutinszerűen alagútnak számítják.
Azután nézze meg az interfészeket és az útvonalakat. Az ifconfig utun-interfészeket mutat, de pusztán a jelenlétük keveset bizonyít, mert a macOS az utunt több célra használja a VPN-en kívül is. Az számít, hogy az alapértelmezett útvonal valamelyikükbe mutat-e, amit a route -n get default jelent.
Névfeloldáshoz a scutil --dns felsorolja azokat a feloldókat, amelyeket a rendszer valóban használni fog, és ott megjelenik egy DNS-proxy szolgáltató. A dig +short example.com összevetése a dig +short example.com @1.1.1.1 paranccsal elválasztja a válaszoló feloldót az elfogott feloldótól.
A bővítmények tevékenysége eljut az egyesített naplóba: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Azt keresi, melyik bővítmény indult el, és jelentett-e a szűrő döntést az Önt érdeklő folyamról, nem egy megjegyzendő sort.
Szűkítse a tünetet, mielőtt bármit kikapcsolna
Először osztályozza a hibát. A fel nem oldódó név, az azonnal elutasított kapcsolat és az időtúllépésig lógó kapcsolat három különböző megfigyelés, három különböző felelőssel. A feloldás feloldóra vagy DNS-proxyra mutat. Az azonnali elutasítás szűrőszabályra mutat. A csend általában irányításra utal, vagy olyan alagútra, amely felállt, de nem továbbít.
Felügyelt Macen tételezze fel, hogy a szűrő a szervezeté. Kikapcsolása a VPN teszteléséhez eltávolítja azt az összetevőt, amelyet meg akart figyelni, és az MDM gyakran visszaállítja a következő ellenőrzéskor. Kérdezze meg a rendszergazdától a házirend nevét, mielőtt bármit módosít, és azzal az alkalmazással teszteljen, amelyik elbukott, ne az egész rendszerrel.
Még egy csapda: a Private Relay kikapcsolása VPN-teszteléshez semmit nem mond a külföldi forgalomról, mert a relay soha nem fedte le azt a forgalmat. Minden réteget abban az alkalmazásban kell tesztelni, amelyet valóban irányít.
Járja végig ezt a listát, és álljon meg az első pontnál, amelyik elbukik:
- A
scutil --nc lista várt szolgáltatást csatlakozottként mutatja? - A terminálból látható nyilvános cím eltér-e a hozzáférési hálózata által kiosztott címtől?
- Telepítve van-e szűrőbővítmény, és naplózott-e döntést a hibás folyamról?
- Csak a Safariban hibás? Ha igen, ellenőrizze a relay hatókörét, mielőtt az alagutat hibáztatja.
Ha mind a négy átmegy, és az alkalmazás mégis elbukik, a probléma a hálózati réteg fölött van: proxybeállítások, tanúsítvány-megbízhatóság vagy alkalmazásszintű engedélyezési lista.