Ko patiesībā dara Proxy lauks Apple VPN profilā
Proksija lauka aizpildīšana nepārvērš VPN par HTTP. Šeit ir iesaistīti divi savienojumi, un lauks sasniedz tikai vienu no tiem.
Proxy lauka aizpildīšana Apple VPN konfigurācijā liek domāt, ka tam vajadzētu pārvirzīt tuneli caur tīmekļa portu. Tas tā nedara. Lauks izvēlas starpnieku lietotnes līmenī saturam, ko saderīga lietotne izlemj sūtīt uz turieni. Savukārt VPN klienta paša savienojumu ar tā vārteju nosaka protokols, klausītājs un transports, ko esat konfigurējis, un tie ir atsevišķi lēmumi.
Divi savienojumi, divi īpašnieki
Jebkurš šāds iestatījums ietver savienojumu no klienta uz vārteju un savienojumu no lietotnes uz galamērķi. Sadaļa Proxy runā par otro, lai gan tā atrodas tajā pašā profilā kā pirmais.
| 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 |
Apple proksija iestatījumu uzziņa uzskaita HTTP, HTTPS, SOCKS un automātisko proksija konfigurāciju, kas apraksta lietotņu proksija izvēles. Neviens no šiem ierakstiem nepasaka, kā IPsec vai WireGuard pakete nonāk pie vārtejas.
Lūk, ātra pārbaude, kas to atrisina. Nosauciet portu un protokolu, ko VPN klients norāda savā žurnālā. Ja šī rinda joprojām saka UDP 500 vai UDP 51820, proksija lauks tajā neko nav mainījis.
Kad lauks ir pareizais instruments
Ir reāls gadījums, kad proksijs stāv tuneļa priekšā, bet tā ir klienta funkcija, nevis profila lauks. OpenVPN rokasgrāmata dokumentē --http-proxy TCP savienojumiem, kas tiek pārvadāti caur HTTP CONNECT proksiju. Lai to izmantotu, vajadzīga atbilstošā klienta opcija, šādi sasniedzama vārteja un proksijs, kas atļauj CONNECT uz izmantoto portu.
Ja jūsu klients piedāvā šo opciju un tīkls atļauj CONNECT uz portu, tas var darboties. Ja klients to nepiedāvā, sistēmas proksija aizpildīšana tuneļa ietekmē neko nemaina.
Kad tas neko nemaina
IKEv2 vai IPsec profils nekļūst par HTTP tuneli tāpēc, ka proksija lauks ir aizpildīts. Arī WireGuard ne, kura konfigurācijas formātā nav proksija jēdziena. Arī vārtejas porta maiņa nemaina tās protokolu. Un galapunkts, kas atbild uz parastu HTTPS, nav automātiski VPN klausītājs.
Tie paši slazdi noķer tos, kas kopē PPTP laikmeta profilus no vecām iPad rokasgrāmatām. Opcijas saskarnē joprojām ir; pakalpojums aiz tām vairs nerunā šajā protokolā.
Izlemt, kuru slāni labot
Pirms kaut ko mainīt, pajautājiet, kurš slānis neizdevās. Ja klients nevar izveidot sesiju, problēma ir transportā un proksija lauks nav svarīgs. Ja tunelis darbojas, bet viena lietotne nevar sasniegt savu serveri, ir vērts pārbaudīt lietotnes proksiju. Ja tunelis darbojas un visas lietotnes neizdodas, aizdomās turamie ir maršrutēšana un DNS tuneļa iekšienē.
Pirmajā gadījumā pajautājiet operatoram, kuru apstiprināto alternatīvo transportu vai tīklu tas atbalsta. OpenVPN caur TCP 443 pastāv tāpēc, ka daži tīkli atļauj tikai to, un tam joprojām ir vajadzīgs, lai serveris to klausās.
Neuzskatiet bloķētu UDP portu par atļauju improvizēt. Saglabājiet vārtejas sertifikāta vai identitātes pārbaudes neskartas, nevis izslēdziet tās, lai rokasspiediens derētu.
Apstipriniet abus slāņus pa vienam
Vispirms apstipriniet tuneli: klienta statusa lapā pārbaudiet izveidotu sesiju un baitu skaitu, kas nav nulle. Pēc tam nolasiet proksija iestatījumu tieši, ar scutil --proxy faktiskajai konfigurācijai vai networksetup -getwebproxy Wi-Fi saglabātajai vērtībai. Pēc tam pārbaudiet vienu lietotni, kas respektē sistēmas proksiju, un vienu, kas to ignorē, jo daudzas vietējās lietotnes to ignorē.
Trīs rezultāti, trīs dažādi labojumi.
Ja abi slāņi ziņo par panākumiem un lietotne joprojām neizdodas, apskatiet sadalīto tuneļošanu, DNS un pašas lietotnes tīkla iestatījumus. Tas ir trešais slānis, un arī tas nav proksija lauks.