Ką iš tikrųjų daro Proxy laukas Apple VPN profilyje
Proksio lauko užpildymas nepaverčia VPN į HTTP. Čia dalyvauja dvi jungtys, o laukas pasiekia tik vieną jų.
Užpildyti Proxy lauką Apple VPN konfigūracijoje atrodo taip, tarsi tai turėtų peradresuoti tunelį per žiniatinklio prievadą. Taip nėra. Laukas parenka programos lygmens tarpininką srautui, kurį suderinama programa nusprendžia ten siųsti. O paties VPN kliento ryšį su jo tinklų sietuva nustato protokolas, klausytojas ir transportas, kuriuos sukonfigūravote, ir tai yra atskiri sprendimai.
Dvi jungtys, du šeimininkai
Bet kokia tokia sąranga apima jungtį nuo kliento iki tinklų sietuvos ir jungtį nuo programos iki paskirties. Skyrius Proxy kalba apie antrąją, nors ji yra tame pačiame profilyje kaip pirmoji.
| 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 proksio nustatymų žinynas išvardija HTTP, HTTPS, SOCKS ir automatinę proksio konfigūraciją, o tai apibūdina programų proksio pasirinkimus. Nė vienas iš šių įrašų nepasako, kaip IPsec arba WireGuard paketas pasiekia tinklų sietuvą.
Štai greita patikra, kuri tai išsprendžia. Įvardykite prievadą ir protokolą, kuriuos VPN klientas nurodo savo žurnale. Jei ta eilutė vis dar sako UDP 500 arba UDP 51820, proksio laukas joje nieko nepakeitė.
Kada laukas yra tinkama priemonė
Yra realus atvejis, kai proksis stovi prieš tunelį, bet tai kliento funkcija, o ne profilio laukas. OpenVPN vadove dokumentuojama --http-proxy TCP jungtims, perduodamoms per HTTP CONNECT proksį. Norint juo naudotis, reikia atitinkamos kliento parinkties, taip pasiekiamos tinklų sietuvos ir proksio, kuris leidžia CONNECT į naudojamą prievadą.
Jei jūsų klientas siūlo šią parinktį ir tinklas leidžia CONNECT į prievadą, tai gali veikti. Jei klientas jos nesiūlo, sisteminio proksio užpildymas tuneliui visiškai neturi įtakos.
Kada tai nieko nekeičia
IKEv2 arba IPsec profilis netampa HTTP tuneliu todėl, kad užpildytas proksio laukas. WireGuard taip pat ne, nes jo konfigūracijos formate nėra proksio sąvokos. Pakeitus tinklų sietuvos prievadą, jos protokolas taip pat nesikeičia. O galutinis taškas, atsakantis į įprastą HTTPS, nėra automatiškai VPN klausytojas.
Ta pati spąsta sugauna tuos, kurie kopijuoja PPTP eros profilius iš senų iPad vadovų. Parinktys sąsajoje dar yra; paslauga už jų nebebendrauja šiuo protokolu.
Nuspręsti, kurį sluoksnį taisyti
Prieš ką nors keisdami, paklauskite, kuris sluoksnis sugedo. Jei klientas negali užmegzti sesijos, problema yra transporte, o proksio laukas neturi reikšmės. Jei tunelis veikia, bet viena programa negali pasiekti savo serverio, verta patikrinti programos proksį. Jei tunelis veikia ir visos programos nepavyksta, įtariamieji yra maršrutizavimas ir DNS tunelio viduje.
Pirmuoju atveju paklauskite operatoriaus, kokį patvirtintą alternatyvų transportą ar tinklą jis palaiko. OpenVPN per TCP 443 egzistuoja todėl, kad kai kurie tinklai leidžia tik jį, ir jam vis dar reikia, kad serveris jo klausytųsi.
Nelaikykite užblokuoto UDP prievado leidimu improvizuoti. Išsaugokite tinklų sietuvos sertifikato ar tapatybės patikras, o ne išjunkite jas, kad rankos paspaudimas tilptų.
Patikrinkite abu sluoksnius po vieną
Pirmiausia patvirtinkite tunelį: kliento būsenos puslapyje patikrinkite užmegztą sesiją ir ne nulinį baitų skaičių. Tada perskaitykite proksio nuostatą tiesiogiai, su scutil --proxy veiksmingai konfigūracijai arba networksetup -getwebproxy Wi-Fi išsaugotai reikšmei. Tada išbandykite vieną programą, kuri gerbia sisteminį proksį, ir vieną, kuri jo nepaiso, nes daugelis vietinių programų jo nepaiso.
Trys rezultatai, trys skirtingi pataisymai.
Jei abu sluoksniai praneša apie sėkmę, o programa vis tiek nepavyksta, pažiūrėkite į padalintą tuneliavimą, DNS ir pačios programos tinklo nustatymus. Tai trečias sluoksnis, ir jis taip pat nėra proksio laukas.