Che cosa fa davvero il campo Proxy in un profilo VPN Apple
Compilare un campo proxy non trasforma una VPN in HTTP. Sono coinvolte due connessioni e il campo ne raggiunge solo una.
Compilare il campo Proxy di una configurazione VPN Apple dà l’impressione che debba reindirizzare il tunnel attraverso una porta web. Non è così. Il campo sceglie un intermediario a livello applicativo per il traffico che un’app compatibile decide di inviare lì. La connessione del client VPN stesso con il suo gateway, invece, dipende dal protocollo, dal listener e dal trasporto che hai configurato, e sono decisioni separate.
Due connessioni, due responsabili
Qualsiasi configurazione di questo tipo comporta una connessione dal client al gateway e una dall’applicazione alla destinazione. La sezione Proxy riguarda la seconda, anche se si trova nello stesso profilo della prima.
| 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 |
La riferimento delle impostazioni proxy di Apple elenca HTTP, HTTPS, SOCKS e la configurazione automatica del proxy, che descrive le scelte proxy delle applicazioni. Nessuna di queste voci dice come un pacchetto IPsec o WireGuard raggiunga un gateway.
Ecco un controllo rapido che risolve la questione. Indica la porta e il protocollo che il client VPN riporta nel suo registro. Se quella riga dice ancora UDP 500 o UDP 51820, il campo proxy non vi ha cambiato nulla.
Quando il campo è lo strumento giusto
Esiste un caso reale in cui un proxy sta davanti al tunnel, ma è una funzione del client e non un campo del profilo. Il manuale di OpenVPN documenta --http-proxy per le connessioni TCP trasportate tramite un proxy HTTP CONNECT. Usarlo richiede l’opzione client corrispondente, un gateway raggiungibile in quel modo e un proxy che consenta CONNECT verso la porta in uso.
Se il tuo client espone quell’opzione e la rete consente CONNECT verso la porta, può funzionare. Se il client non la espone, compilare un proxy di sistema non ha alcun effetto sul tunnel.
Quando non cambia nulla
Un profilo IKEv2 o IPsec non diventa un tunnel HTTP perché il campo proxy è compilato. Nemmeno WireGuard, il cui formato di configurazione non conosce il concetto di proxy. Cambiare la porta del gateway non cambia nemmeno il suo protocollo. E un endpoint che risponde a un normale HTTPS non è automaticamente un listener VPN.
La stessa trappola coglie chi copia profili dell’epoca PPTP da vecchie guide iPad. Le opzioni esistono ancora nell’interfaccia; il servizio dietro non parla più quel protocollo.
Decidere quale livello correggere
Chiedi quale livello ha fallito prima di cambiare qualcosa. Se il client non riesce a stabilire una sessione, il problema è il trasporto e il campo proxy è irrilevante. Se il tunnel è attivo ma un’app non raggiunge il suo server, vale la pena esaminare il proxy dell’applicazione. Se il tunnel è attivo e tutte le app falliscono, i sospetti sono l’instradamento e il DNS dentro il tunnel.
Per il primo caso, chiedi all’operatore quale trasporto o rete alternativa approvata supporta. OpenVPN su TCP 443 esiste perché alcune reti consentono solo quello, e richiede comunque che il server lo ascolti.
Non considerare una porta UDP bloccata un permesso a improvvisare. Mantieni intatti i controlli di certificato o di identità del gateway invece di disattivarli per far quadrare l’handshake.
Conferma i due livelli uno alla volta
Conferma prima il tunnel: controlla nella pagina di stato del client una sessione stabilita e un conteggio di byte diverso da zero. Poi leggi l’impostazione proxy direttamente, con scutil --proxy per la configurazione effettiva o networksetup -getwebproxy Wi-Fi per il valore memorizzato. Poi prova un’app che rispetta il proxy di sistema e una che lo ignora, perché molte app native lo ignorano.
Tre risultati, tre correzioni diverse.
Se entrambi i livelli segnalano successo e l’app continua a fallire, guarda lo split tunneling, il DNS e le impostazioni di rete dell’app stessa. È un terzo livello, e non è nemmeno il campo proxy.