Wat it Proxy-fjild yn in Apple VPN-profyl eins docht
In proxyfjild ynfolje makket fan in VPN gjin HTTP. Der binne twa ferbiningen by belutsen, en it fjild berikt mar ien fan beide.
It Proxy-fjild fan in Apple VPN-konfiguraasje ynfolje fielt as moat it de tunnel fia in webpoarte omliede. Dat docht it net. It fjild kiest in tuskenpersoan op applikaasjenivo foar ferkear dat in kompatibele app dêrhinne stjoere wol. De eigen ferbining fan de VPN-klient nei syn gateway wurdt lykwols bepaald troch it protokol, de listener en it transport dat jo ynsteld hawwe, en dat binne aparte besluten.
Twa ferbiningen, twa eigners
Elke ynstelling fan dit soarte omfettet in ferbining fan klient nei gateway en ien fan applikaasje nei bestimming. De seksje Proxy giet oer de twadde, ek al stiet dy yn itselde profyl as de earste.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
De referinsje foar proxyynstellingen fan Apple neamt HTTP, HTTPS, SOCKS en automatyske proxykonfiguraasje, wat de proxykarren fan applikaasjes beskriuwt. Gjin fan dy items seit eat oer hoe’t in IPsec- of WireGuard-pakket in gateway berikt.
Hjir is in flugge kontrôle dy’t it útmakket. Neam de poarte en it protokol dy’t de VPN-klient yn syn log meldt. As dy rigel noch altyd UDP 500 of UDP 51820 seit, hat it proxyfjild dêroan neat feroare.
Wannear it fjild it juste ark is
Der is in echt gefal wêryn in proxy foar de tunnel stiet, mar dat is in kliïntfunksje en gjin profylfjild. De hânlieding fan OpenVPN dokumintearret --http-proxy foar TCP-ferbiningen dy’t troch in HTTP CONNECT-proxy geane. It brûken freget de byhearrende klientopsje, in gateway dy’t sa berikber is, en in proxy dy’t CONNECT nei de brûkte poarte tastiet.
As jo klient dy opsje biedt en it netwurk CONNECT nei de poarte tastiet, kin it wurkje. As de klient it net biedt, hat it ynfoljen fan in systeemproxy hielendal gjin effekt op de tunnel.
Wannear’t it neat feroaret
In IKEv2- of IPsec-profyl wurdt gjin HTTP-tunnel om’t it proxyfjild ynfold is. WireGuard ek net, waans konfiguraasjeformaat gjin proxybegryp hat. It feroarjen fan de gatewaypoarte feroaret ek syn protokol net. En in einpunt dat gewoane HTTPS beantwurdet is net automatysk in VPN-listener.
Deselde falstrik pakt minsken dy’t profylen út it PPTP-tiidrek út âlde iPad-gidsen kopiearje. De opsjes besteane noch yn de ynterface; de tsjinst derachter sprekt dat protokol net mear.
Beslute hokker laach te reparearjen
Freegje hokker laach mislearre is foardat jo eat feroarje. As de klient gjin sesje meitsje kin, is it transport it probleem en is it proxyfjild net fan belang. As de tunnel oan is mar ien app berikt syn tsjinner net, is it de muoite wurdich de applikaasjeproxy te besjen. As de tunnel oan is en alle apps mislearje, binne routing en DNS binnen de tunnel de fertochten.
Freegje foar it earste gefal de operator hokker goedkarde alternative transport of netwurk hy stipet. OpenVPN oer TCP 443 bestiet om’t guon netwurken allinnich dat tastean, en it freget noch altyd dat de tsjinner dernei harket.
Besjoch in blokkearre UDP-poarte net as tastimming om te ymprovisearjen. Hâld de sertifikaat- as identiteitskontrôles fan de gateway yntakt yn stee fan se út te setten om in handshake passe te meitsjen.
Befêstigje de twa lagen ien foar ien
Befêstigje earst de tunnel: sjoch op de status side fan de klient nei in fêstige sesje en in bytetelling dy’t net nul is. Lês dan de proxyynstelling direkt, mei scutil --proxy foar de effektive konfiguraasje of networksetup -getwebproxy Wi-Fi foar de bewarre wearde. Test dan ien app dy’t de systeemproxy respektearret en ien dy’t it negearret, want in soad native apps negearje it.
Trije resultaten, trije ferskillende reparaasjes.
As beide lagen sukses melde en de app mislearret noch, sjoch dan nei split-tunneling, DNS en de eigen netwurkinstellingen fan de app. Dat is in tredde laach, en dy is ek net it proxyfjild.