Šta polje Proxy u Apple VPN profilu zapravo radi
Popunjavanje polja proxy ne pretvara VPN u HTTP. Uključene su dvije veze, a polje doseže samo jednu od njih.
Popunjavanje polja Proxy u Apple VPN konfiguraciji izgleda kao da bi trebalo preusmjeriti tunel kroz web port. Ali ne. Polje bira posrednika na razini aplikacije za promet koji kompatibilna aplikacija odluči poslati tamo. A vlastitu vezu VPN klijenta s pristupnikom određuju protokol, slušalica i transport koje ste konfigurirali, i to su odvojene odluke.
Dvije veze, dva vlasnika
Svaka ovakva postavka uključuje vezu klijenta s pristupnikom i vezu aplikacije s odredištem. Odjeljak Proxy govori o drugoj, iako se nalazi u istom profilu kao i 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 postavki proxyja navodi HTTP, HTTPS, SOCKS i automatsku konfiguraciju proxyja, što opisuje izbore proxyja za aplikacije. Nijedan od tih unosa ne kaže kako IPsec ili WireGuard paket stiže do pristupnika.
Evo brze provjere koja to rješava. Navedite port i protokol koje VPN klijent prijavljuje u svojem dnevniku. Ako taj redak još uvijek kaže UDP 500 ili UDP 51820, polje proxy nije na tome ništa promijenilo.
Kada je polje pravi alat
Postoji stvarni slučaj u kojem proxy stoji ispred tunela, ali to je značajka klijenta, a ne polje profila. OpenVPN priručnik dokumentira --http-proxy za TCP veze koje se prenose kroz HTTP CONNECT proxy. Za to je potrebna odgovarajuća opcija klijenta, pristupnik dostupan tim putem i proxy koji dopušta CONNECT na port koji se koristi.
Ako vaš klijent nudi tu opciju i mreža dopušta CONNECT na port, može raditi. Ako je klijent ne nudi, popunjavanje sistemskog proxyja nema nikakvog učinka na tunel.
Kada ništa ne mijenja
IKEv2 ili IPsec profil ne postaje HTTP tunel zato što je polje proxy popunjeno. Ni WireGuard, čiji format konfiguracije nema pojam proxyja. Promjena porta pristupnika također ne mijenja njegov protokol. A krajnja točka koja odgovara na obični HTTPS nije automatski VPN slušalica.
Ista zamka hvata ljude koji kopiraju profile iz PPTP ere iz starih iPad vodiča. Opcije još postoje u sučelju; usluga iza njih više ne govori taj protokol.
Odlučite koji sloj popraviti
Pitajte koji je sloj zakazao prije nego što išta promijenite. Ako klijent ne može uspostaviti sesiju, problem je u transportu i polje proxy je nevažno. Ako je tunel aktivan, ali jedna aplikacija ne može doći do svojeg poslužitelja, vrijedi pregledati proxy aplikacije. Ako je tunel aktivan i sve aplikacije zakažu, sumnjivci su usmjeravanje i DNS unutar tunela.
Za prvi slučaj pitajte operatera koji odobreni alternativni transport ili mrežu podržava. OpenVPN preko TCP 443 postoji jer neke mreže dopuštaju samo to, a i dalje zahtijeva da poslužitelj to sluša.
Ne shvaćajte blokirani UDP port kao dopuštenje za improvizaciju. Očuvajte provjere certifikata ili identiteta pristupnika umjesto da ih isključite kako bi rukovanje odgovaralo.
Provjerite dva sloja jedan po jedan
Najprije potvrdite tunel: provjerite na statusnoj stranici klijenta postoji li uspostavljena sesija i broj bajtova različit od nule. Zatim pročitajte postavku proxyja izravno, s scutil --proxy za stvarnu konfiguraciju ili networksetup -getwebproxy Wi-Fi za pohranjenu vrijednost. Zatim testirajte jednu aplikaciju koja poštuje sistemski proxy i jednu koja ga ignorira, jer mnoge izvorne aplikacije ga ignoriraju.
Tri rezultata, tri različita popravka.
Ako oba sloja prijave uspjeh, a aplikacija još uvijek ne radi, pogledajte podijeljeno tuneliranje, DNS i vlastite mrežne postavke aplikacije. To je treći sloj i ni on nije polje proxy.