Kion la kampo Proxy en Apple-VPN-profilo efektive faras
Plenigi proksean kampon ne igas VPN-on HTTP. Du konektoj estas implikitaj, kaj la kampo atingas nur unu el ili.
Plenigi la kampon Proxy en Apple-VPN-agordo sentiĝas kvazaŭ ĝi devus alidirekti la tunelon tra reta pordo. Ĝi ne faras tion. La kampo elektas peranton je aplikaĵ-nivelo por trafiko, kiun kongrua aplikaĵo decidas sendi tien. La propran konekton de la VPN-kliento al sia enirejo regas la protokolo, la aŭskultanto kaj la transporto, kiujn vi agordis, kaj tiuj estas apartaj decidoj.
Du konektoj, du posedantoj
Ĉiu tia agordo implikas konekton de kliento al enirejo kaj konekton de aplikaĵo al celo. La sekcio Proxy parolas pri la dua, kvankam ĝi staras en la sama profilo kiel la unua.
| 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 |
La referenco pri proksaj agordoj de Apple listigas HTTP, HTTPS, SOCKS kaj aŭtomatan proksan agordon, kio priskribas la elektojn de aplikaĵa prokso. Neniu el tiuj eroj diras ion pri tio, kiel IPsec aŭ WireGuard-paketo atingas enirejon.
Jen rapida kontrolo, kiu solvas la aferon. Nomu la pordon kaj protokolon, kiujn la VPN-kliento raportas en sia protokolo. Se tiu linio ankoraŭ diras UDP 500 aŭ UDP 51820, la proksa kampo ŝanĝis nenion en ĝi.
Kiam la kampo estas la ĝusta ilo
Ekzistas vera kazo, en kiu prokso staras antaŭ la tunelo, sed ĝi estas klienta trajto, ne profila kampo. La manlibro de OpenVPN dokumentas --http-proxy por TCP-konektoj transportataj tra HTTP CONNECT-prokso. Uzi ĝin postulas la respondan klientan opcion, enirejon atingeblan tiel, kaj prokson, kiu permesas CONNECT al la uzata pordo.
Se via kliento montras tiun opcion kaj la reto permesas CONNECT al la pordo, ĝi povas funkcii. Se via kliento ne montras ĝin, plenigi sisteman prokson havas neniun efikon al la tunelo.
Kiam ĝi ŝanĝas nenion
IKEv2 aŭ IPsec-profilo ne fariĝas HTTP-tunelo pro tio, ke la proksa kampo estas plenigita. Nek WireGuard, kies agorda formato havas neniun proksan koncepton. Ŝanĝi la enirejan pordon ankaŭ ne ŝanĝas ĝian protokolon. Kaj finpunkto, kiu respondas al ordinara HTTPS, ne estas aŭtomate VPN-aŭskultanto.
La sama kaptilo kaptas homojn, kiuj kopias profilojn el la PPTP-epoko el malnovaj iPad-gvidiloj. La opcioj ankoraŭ ekzistas en la fasado; la servo malantaŭ ili ne plu parolas tiun protokolon.
Decidi, kiun tavolon ripari
Demandu, kiu tavolo malsukcesis, antaŭ ol ion ŝanĝi. Se la kliento ne povas starigi seancon, la problemo estas la transporto kaj la proksa kampo estas nerelevanta. Se la tunelo funkcias sed unu aplikaĵo ne atingas sian servilon, indas ekzameni la aplikaĵan prokson. Se la tunelo funkcias kaj ĉiuj aplikaĵoj malsukcesas, suspektindas la enkursigado kaj DNS ene de la tunelo.
Por la unua kazo, demandu la operatoron, kiun aprobitan alternativan transporton aŭ reton ĝi subtenas. OpenVPN super TCP 443 ekzistas ĉar iuj retoj permesas nur tion, kaj ĝi ankoraŭ postulas, ke la servilo aŭskultu ĝin.
Ne traktu blokitan UDP-pordon kiel permeson improvizi. Konservu la atestilon aŭ identecajn kontrolojn de la enirejo sendifekte anstataŭ malŝalti ilin por ke la manpremo taŭgu.
Konfirmu la du tavolojn unu post la alia
Unue konfirmu la tunelon: kontrolu en la statpaĝo de la kliento establigitan seancon kaj nombron da bajtoj ne nula. Poste legu la proksan agordon rekte, per scutil --proxy por la efektiva agordo aŭ networksetup -getwebproxy Wi-Fi por la konservita valoro. Poste testu unu aplikaĵon, kiu respektas la sisteman prokson, kaj unu, kiu ignoras ĝin, ĉar multaj denaskaj aplikaĵoj ignoras ĝin.
Tri rezultoj, tri malsamaj korektoj.
Se ambaŭ tavoloj raportas sukceson kaj la aplikaĵo ankoraŭ malsukcesas, rigardu disigitan tuneladon, DNS kaj la proprajn retajn agordojn de la aplikaĵo. Tio estas tria tavolo, kaj ĝi ankaŭ ne estas la proksa kampo.