Čo v skutočnosti robí pole Proxy v profile VPN na Apple
Vyplnenie poľa proxy nezmení VPN na HTTP. Zapojené sú dve spojenia a pole sa týka iba jedného z nich.
Vyplnenie poľa Proxy v konfigurácii VPN na Apple vyzerá, akoby malo presmerovať tunel cez webový port. Nerobí to. Pole vyberá sprostredkovateľa na úrovni aplikácie pre prevádzku, ktorú sa kompatibilná aplikácia rozhodne odoslať tam. Samotné spojenie klienta VPN s jeho bránou však riadi protokol, naslúchajúci port a transport, ktoré ste nastavili, a to sú oddelené rozhodnutia.
Dve spojenia, dvaja vlastníci
Každé takéto nastavenie zahŕňa spojenie klienta s bránou a spojenie aplikácie s cieľom. Sekcia Proxy hovorí o druhom, hoci je v tom istom profile ako prvé.
| 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 |
Prehľad nastavení proxy od Apple uvádza HTTP, HTTPS, SOCKS a automatickú konfiguráciu proxy, čo opisuje voľby proxy aplikácií. Žiadny z týchto záznamov nehovorí, ako sa paket IPsec alebo WireGuard dostane k bráne.
Tu je rýchla kontrola, ktorá to vyrieši. Uveďte port a protokol, ktoré klient VPN hlási vo svojom logu. Ak ten riadok stále hovorí UDP 500 alebo UDP 51820, pole proxy na ňom nič nezmenilo.
Kedy je pole správny nástroj
Existuje skutočný prípad, keď proxy stojí pred tunelom, ale je to funkcia klienta, nie pole profilu. Manuál OpenVPN dokumentuje --http-proxy pre TCP spojenia prenášané cez proxy HTTP CONNECT. Použitie vyžaduje príslušnú voľbu klienta, bránu dostupnú týmto spôsobom a proxy, ktorá povoľuje CONNECT na používaný port.
Ak váš klient ponúka túto voľbu a sieť povoľuje CONNECT na port, môže to fungovať. Ak ju klient neponúka, vyplnenie systémovej proxy nemá na tunel vôbec žiadny vplyv.
Kedy nič nemení
Profil IKEv2 alebo IPsec sa nestane tunelom HTTP preto, že je pole proxy vyplnené. Ani WireGuard, ktorého formát konfigurácie pojem proxy nepozná. Zmena portu brány tiež nemení jej protokol. A koncový bod, ktorý odpovedá na bežné HTTPS, nie je automaticky naslúchajúcim VPN.
Rovnaká pasca chytá ľudí, ktorí kopírujú profily z éry PPTP zo starých návodov pre iPad. Voľby v rozhraní stále existujú; služba za nimi už týmto protokolom nehovorí.
Rozhodnúť, ktorú vrstvu opraviť
Skôr než niečo zmeníte, spýtajte sa, ktorá vrstva zlyhala. Ak klient nemôže nadviazať reláciu, problém je v transporte a pole proxy je irelevantné. Ak tunel beží, ale jedna aplikácia sa nedostane na svoj server, oplatí sa pozrieť na proxy aplikácie. Ak tunel beží a zlyhávajú všetky aplikácie, podozriví sú smerovanie a DNS vnútri tunela.
V prvom prípade sa opýtajte operátora, ktorý schválený alternatívny transport alebo sieť podporuje. OpenVPN cez TCP 443 existuje preto, lebo niektoré siete povoľujú iba to, a stále vyžaduje, aby na ňom server naslúchal.
Neberte zablokovaný port UDP ako povolenie improvizovať. Zachovajte kontroly certifikátu alebo identity brány, namiesto toho, aby ste ich vypínali, aby sa podanie ruky zmestilo.
Overte obe vrstvy jednu po druhej
Najprv potvrďte tunel: na stavovej stránke klienta skontrolujte nadviazanú reláciu a nenulový počet bajtov. Potom prečítajte nastavenie proxy priamo, s scutil --proxy pre účinnú konfiguráciu alebo networksetup -getwebproxy Wi-Fi pre uloženú hodnotu. Potom otestujte jednu aplikáciu, ktorá rešpektuje systémovú proxy, a jednu, ktorá ju ignoruje, pretože veľa natívnych aplikácií ju ignoruje.
Tri výsledky, tri rôzne opravy.
Ak obe vrstvy hlásia úspech a aplikácia stále zlyháva, pozrite sa na rozdelené tunelovanie, DNS a vlastné sieťové nastavenia aplikácie. To je tretia vrstva a ani tá nie je poľom proxy.