Kaj v resnici počne polje Proxy v profilu VPN Apple
Izpolnjevanje polja proxy ne spremeni VPN v HTTP. Vpleteni sta dve povezavi, polje pa doseže le eno od njiju.
Izpolnjevanje polja Proxy v konfiguraciji VPN Apple daje občutek, da bi moralo preusmeriti tunel skozi spletna vrata. Ne stori tega. Polje izbere posrednika na ravni aplikacije za promet, ki se ga združljiva aplikacija odloči poslati tja. Povezavo samega odjemalca VPN z njegovim prehodom pa določajo protokol, poslušalec in prenos, ki ste jih nastavili, in to so ločene odločitve.
Dve povezavi, dva lastnika
Vsaka taka nastavitev vključuje povezavo od odjemalca do prehoda in povezavo od aplikacije do cilja. Razdelek Proxy govori o drugi, čeprav je v istem profilu kot prva.
| 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 |
Appleov pregled nastavitev proxyja navaja HTTP, HTTPS, SOCKS in samodejno konfiguracijo proxyja, kar opisuje izbire proxyja v aplikacijah. Noben od teh vnosov ne pove, kako paket IPsec ali WireGuard doseže prehod.
Tukaj je hitro preverjanje, ki to razreši. Navedite vrata in protokol, ki jih odjemalec VPN poroča v svojem dnevniku. Če ta vrstica še vedno pravi UDP 500 ali UDP 51820, polje proxy glede tega ni spremenilo ničesar.
Kdaj je polje pravo orodje
Obstaja resničen primer, ko proxy stoji pred tunelom, vendar je to funkcija odjemalca in ne polje profila. Priročnik OpenVPN dokumentira --http-proxy za povezave TCP, ki se prenašajo skozi proxy HTTP CONNECT. Uporaba zahteva ustrezno možnost odjemalca, tako dosegljiv prehod in proxy, ki dovoljuje CONNECT na uporabljena vrata.
Če vaš odjemalec ponuja to možnost in omrežje dovoljuje CONNECT na vrata, lahko deluje. Če odjemalec tega ne ponuja, izpolnjevanje sistemskega proxyja na tunel sploh ne vpliva.
Kdaj ne spremeni ničesar
Profil IKEv2 ali IPsec ne postane tunel HTTP zato, ker je polje proxy izpolnjeno. Niti WireGuard, katerega oblika konfiguracije ne pozna pojma proxyja. Tudi sprememba vrat prehoda ne spremeni njegovega protokola. In končna točka, ki odgovarja na običajen HTTPS, ni samodejno poslušalec VPN.
Ista past ujame ljudi, ki kopirajo profile iz obdobja PPTP iz starih vodnikov za iPad. Možnosti v vmesniku še vedno obstajajo; storitev za njimi ne govori več tega protokola.
Odločitev, kateri sloj popraviti
Preden karkoli spremenite, vprašajte, kateri sloj je odpovedal. Če odjemalec ne more vzpostaviti seje, je težava v prenosu in polje proxy je nepomembno. Če tunel deluje, a ena aplikacija ne doseže svojega strežnika, je vredno pregledati proxy aplikacije. Če tunel deluje in vse aplikacije odpovedo, so sumljivi usmerjanje in DNS znotraj tunela.
Za prvi primer vprašajte operaterja, kateri odobreni nadomestni prenos ali omrežje podpira. OpenVPN prek TCP 443 obstaja, ker nekatera omrežja dovoljujejo samo to, in še vedno zahteva, da strežnik posluša na njem.
Blokiranih vrat UDP ne jemljite kot dovoljenje za improvizacijo. Ohranite preverjanja potrdila ali identitete prehoda nedotaknjena, namesto da jih izklopite, da bi se rokovanje prilegalo.
Preverite oba sloja enega za drugim
Najprej potrdite tunel: na statusni strani odjemalca preverite vzpostavljeno sejo in število bajtov, ki ni nič. Nato preberite nastavitev proxyja neposredno, s scutil --proxy za dejansko konfiguracijo ali networksetup -getwebproxy Wi-Fi za shranjeno vrednost. Nato preizkusite eno aplikacijo, ki spoštuje sistemski proxy, in eno, ki ga ignorira, saj ga veliko izvornih aplikacij ignorira.
Trije rezultati, tri različni popravki.
Če oba sloja poročata o uspehu in aplikacija še vedno odpove, poglejte razdeljeno tuneliranje, DNS in lastne omrežne nastavitve aplikacije. To je tretji sloj in tudi ta ni polje proxy.