Mit tesz valójában a Proxy mező egy Apple VPN-profilban

A Proxy mező kitöltése egy Apple VPN-konfigurációban olyan érzést kelt, mintha a bújtatást egy webes porton keresztül kellene átirányítania. Nem teszi. A mező egy alkalmazásszintű közvetítőt választ annak a forgalomnak, amelyet egy kompatibilis alkalmazás oda küldeni dönt. A VPN-kliens saját kapcsolatát az átjárójával viszont az általad beállított protokoll, figyelő és átvitel szabályozza, és ezek külön döntések.

Két kapcsolat, két tulajdonos

Minden ilyen beállítás tartalmaz egy ügyféltől az átjáróig tartó és egy alkalmazástól a célállomásig tartó kapcsolatot. A Proxy szakasz a másodikról szól, bár ugyanabban a profilban van, mint az első.

Az Apple proxybeállítási referenciája felsorolja a HTTP-t, a HTTPS-t, a SOCKS-t és az automatikus proxykonfigurációt, ami az alkalmazások proxyválasztásait írja le. Egyik bejegyzés sem mondja el, hogyan ér el egy IPsec- vagy WireGuard-csomag egy átjárót.

Íme egy gyors ellenőrzés, amely eldönti a kérdést. Nevezd meg a portot és a protokollt, amelyet a VPN-kliens a naplójában jelent. Ha az a sor még mindig UDP 500 vagy UDP 51820, a proxy mező semmit nem változtatott rajta.

Mikor a mező a megfelelő eszköz

Létezik valós eset, amikor egy proxy a bújtatás előtt áll, de ez az ügyfél funkciója, nem profilmező. Az OpenVPN kézikönyve dokumentálja a --http-proxy beállítást a HTTP CONNECT proxyn keresztül továbbított TCP-kapcsolatokhoz. Használatához kell a megfelelő ügyfélopció, az így elérhető átjáró és egy proxy, amely engedélyezi a CONNECT-et a használt portra.

Ha az ügyféled kínálja ezt az opciót, és a hálózat engedélyezi a CONNECT-et a portra, működhet. Ha az ügyfél nem kínálja, a rendszerproxy kitöltése semmilyen hatással nincs a bújtatásra.

Mikor nem változtat semmin

Egy IKEv2- vagy IPsec-profil nem válik HTTP-bújtatássá attól, hogy a proxy mező ki van töltve. A WireGuard sem, amelynek konfigurációs formátuma nem ismeri a proxy fogalmát. Az átjáró portjának módosítása sem változtatja meg a protokollt. És egy közönséges HTTPS-re válaszoló végpont nem lesz automatikusan VPN-figyelő.

Ugyanez a csapda fogja meg azokat, akik PPTP-korszakbeli profilokat másolnak régi iPad-útmutatókból. A lehetőségek még léteznek a felületen; a mögöttük lévő szolgáltatás már nem beszél ezen a protokollon.

Eldönteni, melyik réteget kell javítani

Kérdezd meg, melyik réteg hibázott, mielőtt bármit megváltoztatnál. Ha az ügyfél nem tud munkamenetet létrehozni, az átvitel a probléma, és a proxy mező lényegtelen. Ha a bújtatás él, de egy alkalmazás nem éri el a szerverét, érdemes megvizsgálni az alkalmazás proxyt. Ha a bújtatás él, és minden alkalmazás meghiúsul, a bújtatáson belüli útválasztás és DNS a gyanús.

Az első esetben kérdezd meg az üzemeltetőt, melyik jóváhagyott alternatív átvitelt vagy hálózatot támogatja. Az OpenVPN TCP 443-on azért létezik, mert egyes hálózatok csak azt engedélyezik, és még mindig megköveteli, hogy a szerver figyelje.

Ne tekintsd a blokkolt UDP-portot az improvizáció engedélyének. Tartsd érintetlenül az átjáró tanúsítvány- vagy identitásellenőrzéseit, ahelyett hogy kikapcsolnád őket, hogy a kézfogás illeszkedjen.

Ellenőrizd a két réteget egyenként

Először igazold a bújtatást: nézd meg az ügyfél állapotoldalán a létrejött munkamenetet és a nem nulla bájtszámot. Utána olvasd ki közvetlenül a proxybeállítást, a scutil --proxy használatával a tényleges konfigurációhoz vagy a networksetup -getwebproxy Wi-Fi használatával a tárolt értékhez. Utána tesztelj egy alkalmazást, amely tiszteletben tartja a rendszerproxyt, és egyet, amely figyelmen kívül hagyja, mert sok natív alkalmazás figyelmen kívül hagyja.

Három eredmény, három különböző javítás.

Ha mindkét réteg sikert jelent, és az alkalmazás még mindig meghiúsul, nézd meg az osztott bújtatást, a DNS-t és az alkalmazás saját hálózati beállításait. Az egy harmadik réteg, és az sem a proxy mező.