Om die Proxy-veld van 'n Apple VPN-konfigurasie in te vul, voel asof dit die tonnel deur 'n webpoort moet herlei. Dit doen nie. Die veld kies 'n tussenlaag op toepassingsvlak vir verkeer wat 'n versoenbare program verkies om daarheen te stuur. Die VPN-kliënt se eie verbinding na sy gateway word deur die protokol, die luisteraar en die vervoer wat jy opgestel het bepaal, en dit is afsonderlike besluite.

Twee verbindings, twee eienaars

Enige opstelling soos hierdie behels 'n kliënt-tot-gateway-verbinding en 'n toepassing-tot-bestemming-verbinding. Die Proxy-afdeling praat met die tweede een, al sit dit in dieselfde profiel as die eerste.

ConnectionWhat decides its behaviour
VPN client to VPN gatewayThe supported protocol, the listening port, the transport and the network policy in between
Application to a selected proxyThe application's own proxy support, the configured proxy policy, and the route to that next hop

Apple se proxy-instellingsverwysing lys HTTP, HTTPS, SOCKS en outomatiese proxy-konfigurasie, wat 'n beskrywing van toepassing-proxykeuses is. Nie een van daardie inskrywings sê iets oor hoe 'n IPsec- of WireGuard-pakkie 'n gateway bereik nie.

Hier is 'n vinnige toets wat dit beslis. Noem die poort en protokol wat die VPN-kliënt in sy log aanmeld. As daardie reël steeds UDP 500 of UDP 51820 sê, het die proxyveld niks daaraan verander nie.

Wanneer die veld die regte hulpmiddel is

Daar is 'n werklike geval waar 'n proxy voor die tonnel sit, maar dit is 'n kliëntfunksie eerder as 'n profielveld. OpenVPN se handleiding dokumenteer --http-proxy vir TCP-verbindings wat deur 'n HTTP CONNECT-proxy gedra word. Om dit te gebruik, het jy die ooreenstemmende kliëntopsie nodig, 'n gateway wat so bereikbaar is, en 'n proxy wat CONNECT na die poort in gebruik toelaat.

As jou kliënt daardie opsie blootstel en die netwerk CONNECT na die poort toelaat, kan dit werk. As jou kliënt dit nie blootstel nie, het die invul van 'n stelselproxy glad geen effek op die tonnel nie.

Wanneer dit niks verander nie

'n IKEv2- of IPsec-profiel word nie 'n HTTP-tonnel omdat die proxyveld ingevul is nie. WireGuard ook nie, want sy konfigurasieformaat het geen proxy-konsep nie. Om die gatewaypoort te verander verander nie sy protokol nie. En 'n eindpunt wat gewone HTTPS beantwoord, is nie outomaties 'n VPN-luisteraar nie.

Dieselfde lokval vang mense wat PPTP-era-profiele uit ou iPad-gidse kopieer. Die opsies bestaan steeds in die koppelvlak; die diens agter hulle praat nie meer daardie protokol nie.

Besluit watter laag om reg te maak

Vra watter laag gefaal het voordat jy enigiets verander. As die kliënt nie 'n sessie kan vestig nie, is die vervoer die probleem en is die proxyveld irrelevant. As die tonnel op is maar een program kan nie sy bediener bereik nie, is dit die moeite werd om die toepassing-proxy na te gaan. As die tonnel op is en elke program faal, is roetebepaling en DNS binne die tonnel die verdagtes.

Vir die eerste geval, vra die operateur watter goedgekeurde alternatiewe vervoer of netwerk hulle ondersteun. OpenVPN oor TCP 443 bestaan omdat sommige netwerke net dit toelaat, en dit vereis steeds dat die bediener daarvoor luister.

Moenie 'n geblokkeerde UDP-poort as toestemming beskou om te improviseer nie. Hou gateway-sertifikaat- of identiteitskontroles onveranderd eerder as om hulle af te skakel om 'n handshake te laat pas.

Bevestig die twee lae een vir een

Bevestig eers die tonnel: kyk op die kliënt se statusbladsy vir 'n gevestigde sessie en 'n byte-telling wat nie nul is nie. Lees dan die proxy-instelling direk, met scutil --proxy vir die effektiewe konfigurasie of networksetup -getwebproxy Wi-Fi vir die gestoorde waarde. Toets dan een program wat die stelselproxy respekteer en een wat dit ignoreer, want baie inheemse programme ignoreer dit.

Drie resultate, drie verskillende regstellings.

As beide lae sukses rapporteer en die program steeds faal, kyk na verdeelde tonneling, DNS en die program se eie netwerkinstellings. Dit is 'n derde laag, en dit is ook nie die proxyveld nie.

Verwante artikels