Co pole Proxy v profilu VPN na Apple skutečně dělá
Vyplnění pole proxy nepromění VPN v HTTP. Jsou zapojena dvě spojení a pole se týká jen jednoho z nich.
Vyplnění pole Proxy v konfiguraci VPN na Apple vypadá, jako by mělo přesměrovat tunel přes webový port. Nedělá to. Pole vybírá prostředníka na úrovni aplikace pro provoz, který se kompatibilní aplikace rozhodne tam poslat. Vlastní spojení klienta VPN s bránou řídí protokol, naslouchající port a transport, které jste nastavili, a to jsou oddělená rozhodnutí.
Dvě spojení, dva vlastníci
Každé takové nastavení zahrnuje spojení klienta s bránou a spojení aplikace s cílem. Sekce Proxy mluví o druhém, i když sedí ve stejném profilu jako první.
| 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 |
Přehled nastavení proxy od Apple uvádí HTTP, HTTPS, SOCKS a automatickou konfiguraci proxy, což popisuje volby proxy pro aplikace. Žádná z těchto položek neříká, jak paket IPsec nebo WireGuard dorazí k bráně.
Tady je rychlá kontrola, která to vyřeší. Uveďte port a protokol, které klient VPN hlásí ve svém logu. Pokud ten řádek stále říká UDP 500 nebo UDP 51820, pole proxy na něm nic nezměnilo.
Kdy je pole správný nástroj
Existuje skutečný případ, kdy proxy stojí před tunelem, ale je to funkce klienta, ne pole profilu. Manuál OpenVPN dokumentuje --http-proxy pro TCP spojení přenášená přes proxy HTTP CONNECT. Použití vyžaduje odpovídající volbu klienta, bránu dostupnou touto cestou a proxy, která povoluje CONNECT na používaný port.
Pokud váš klient tuto volbu nabízí a síť povoluje CONNECT na port, může to fungovat. Pokud ji klient nenabízí, vyplnění systémové proxy nemá na tunel vůbec žádný vliv.
Kdy nic nemění
Profil IKEv2 nebo IPsec se nestane HTTP tunelem jen proto, že je pole proxy vyplněné. Ani WireGuard, jehož formát konfigurace pojem proxy nezná. Změna portu brány také nemění její protokol. A koncový bod, který odpovídá na běžné HTTPS, není automaticky naslouchající VPN.
Stejná past chytá lidi, kteří kopírují profily z éry PPTP ze starých návodů pro iPad. Volby v rozhraní stále existují; služba za nimi už tímto protokolem nemluví.
Rozhodnutí, kterou vrstvu opravit
Než něco změníte, zeptejte se, která vrstva selhala. Pokud klient nemůže navázat relaci, problém je v transportu a pole proxy je irelevantní. Pokud tunel běží, ale jedna aplikace se nedostane na svůj server, stojí za to prohlédnout proxy aplikace. Pokud tunel běží a selhávají všechny aplikace, podezřelí jsou směrování a DNS uvnitř tunelu.
V prvním případě se provozovatele zeptejte, který schválený alternativní transport nebo síť podporuje. OpenVPN přes TCP 443 existuje proto, že některé sítě povolují jen to, a stále vyžaduje, aby na něm server naslouchal.
Neberte zablokovaný port UDP jako povolení k improvizaci. Zachovejte kontroly certifikátu nebo identity brány, místo abyste je vypínali, aby se handshake vešel.
Ověřte obě vrstvy jednu po druhé
Nejprve potvrďte tunel: na stavové stránce klienta zkontrolujte navázanou relaci a nenulový počet bajtů. Potom přečtěte nastavení proxy přímo, s scutil --proxy pro účinnou konfiguraci nebo networksetup -getwebproxy Wi-Fi pro uloženou hodnotu. Potom otestujte jednu aplikaci, která systémovou proxy respektuje, a jednu, která ji ignoruje, protože mnoho nativních aplikací ji ignoruje.
Tři výsledky, tři různá řešení.
Pokud obě vrstvy hlásí úspěch a aplikace stále selhává, podívejte se na rozdělené tunelování, DNS a vlastní síťové nastavení aplikace. To je třetí vrstva a také to není pole proxy.