Hvað Proxy-reiturinn í Apple VPN-sniði gerir í raun
Að fylla út proxy-reit breytir ekki VPN í HTTP. Tvær tengingar koma við sögu og reiturinn nær aðeins í aðra þeirra.
Að fylla út Proxy-reitinn í Apple VPN-stillingu virðist eiga að beina göngunni í gegnum vefport. Það gerir það ekki. Reiturinn velur millilið á forritslagsstigi fyrir umferð sem samhæft forrit ákveður að senda þangað. En tenging VPN-biðlarans sjálfs við gáttina sína ræðst af samskiptareglunni, hlustandanum og flutningnum sem þú stilltir, og það eru aðskildar ákvarðanir.
Tvær tengingar, tveir eigendur
Hver slík uppsetning felur í sér tengingu biðlarans við gáttina og tengingu forritsins við áfangastaðinn. Proxy-hlutinn fjallar um þá seinni, þótt hann sé í sama sniði og sú fyrri.
| 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 |
Tilvísun Apple að proxy-stillingum telur upp HTTP, HTTPS, SOCKS og sjálfvirka proxy-stillingu, sem lýsir proxy-valkostum forrita. Engin þessara færslna segir neitt um hvernig IPsec- eða WireGuard-pakki kemst að gátt.
Hér er fljótleg prófun sem útkljar málið. Nefndu portið og samskiptaregluna sem VPN-biðlarinn tilkynnir í annál sínum. Ef sú lína segir enn UDP 500 eða UDP 51820 breytti proxy-reiturinn engu um hana.
Hvenær reiturinn er rétta verkfærið
Það er raunverulegt tilvik þar sem proxy stendur fyrir framan gönguna, en það er eiginleiki biðlarans en ekki sniðsreitur. Handbók OpenVPN skjalfestir --http-proxy fyrir TCP-tengingar sem bornar eru í gegnum HTTP CONNECT-proxy. Notkun krefst samsvarandi valkosts í biðlaranum, gáttar sem næst á þann hátt og proxy sem leyfir CONNECT á portið sem er í notkun.
Ef biðlarinn þinn býður upp á þann valkost og netið leyfir CONNECT á portið getur það virkað. Ef biðlarinn gerir það ekki hefur það engin áhrif á gönguna að fylla út kerfisproxy.
Hvenær það breytir engu
IKEv2- eða IPsec-snið verður ekki HTTP-göng vegna þess að proxy-reiturinn er útfylltur. WireGuard heldur ekki, en snið þess þekkir ekki hugtakið proxy. Að breyta porti gáttarinnar breytir heldur ekki samskiptareglunni. Og endapunktur sem svarar venjulegu HTTPS er ekki sjálfkrafa VPN-hlustandi.
Sama gildran grípur þá sem afrita snið frá PPTP-tímanum úr gömlum iPad-leiðbeiningum. Valkostirnir eru enn í viðmótinu; þjónustan bak við þá talar ekki lengur þessa samskiptareglu.
Ákveða hvaða lag á að laga
Spyrðu hvaða lag brást áður en þú breytir einhverju. Ef biðlarinn getur ekki stofnað setu er vandamálið í flutningnum og proxy-reiturinn óviðkomandi. Ef gangan er uppi en eitt forrit nær ekki þjóninum sínum er vert að skoða proxy forritsins. Ef gangan er uppi og öll forrit mistakast eru grunsemdirnar leiðsögn og DNS inni í göngunni.
Fyrir fyrra tilvikið skaltu spyrja rekstraraðilann hvaða samþykktu varaleið eða net hann styður. OpenVPN yfir TCP 443 er til vegna þess að sum net leyfa aðeins það, og það krefst þess enn að þjónninn hlusti á það.
Líttu ekki á lokað UDP-port sem leyfi til að grípa til tiltektar. Haltu vottorðs- eða auðkennisskoðunum gáttarinnar óskertum í stað þess að slökkva á þeim svo handabandið passi.
Staðfestu lögin tvö hvert í einu
Staðfestu gönguna fyrst: athugaðu stöðusíðu biðlarans fyrir stofnaðri setu og bytatölu sem er ekki núll. Lestu síðan proxy-stillinguna beint, með scutil --proxy fyrir virku stillinguna eða networksetup -getwebproxy Wi-Fi fyrir geymda gildið. Prófaðu svo eitt forrit sem virðir kerfisproxy og eitt sem hunsar það, því mörg innbyggð forrit hunsa það.
Þrjár niðurstöður, þrjár mismunandi lagfæringar.
Ef bæði lögin tilkynna árangur og forritið mistekst enn skaltu skoða skipta göngun, DNS og eigin netstillingar forritsins. Það er þriðja lagið, og það er heldur ekki proxy-reiturinn.