Mida Proxy-väli Apple’i VPN-profiilis tegelikult teeb
Proksivälja täitmine ei muuda VPN-i HTTP-ks. Kaasatud on kaks ühendust ja väli jõuab neist ainult üheni.
Proxy-välja täitmine Apple’i VPN-konfiguratsioonis tundub, nagu peaks see tunnelit veebipordi kaudu ümber suunama. Ei tee. Väli valib rakenduse tasemel vahendaja liiklusele, mille ühilduv rakendus otsustab sinna saata. VPN-kliendi enda ühendust lüüsiga juhivad aga protokoll, kuulaja ja transport, mille olete seadistanud, ning need on eraldi otsused.
Kaks ühendust, kaks omanikku
Iga selline seadistus hõlmab ühendust kliendist lüüsini ja ühendust rakendusest sihtkohta. Jaotis Proxy räägib teisest, kuigi see asub samas profiilis kui esimene.
| 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’i proksiseadete viide loetleb HTTP, HTTPS, SOCKS-i ja automaatse proksikonfiguratsiooni, mis kirjeldab rakenduste proksivalikuid. Ükski neist kirjetest ei ütle, kuidas IPsec- või WireGuard-pakett lüüsini jõuab.
Siin on kiire kontroll, mis selle ära lahendab. Nimetage port ja protokoll, mille VPN-klient oma logis teatab. Kui see rida ütleb endiselt UDP 500 või UDP 51820, ei muutnud proksiväli selles midagi.
Millal on väli õige tööriist
On tõeline juhtum, kus proksi seisab tunneli ees, kuid see on kliendi funktsioon, mitte profiili väli. OpenVPN-i käsiraamat dokumenteerib --http-proxy TCP-ühenduste jaoks, mida kantakse läbi HTTP CONNECT proksi. Selle kasutamiseks on vaja sobivat kliendi valikut, sellel teel kättesaadavat lüüsi ja proksit, mis lubab CONNECT-i kasutatavale pordile.
Kui teie klient pakub seda valikut ja võrk lubab CONNECT-i pordile, võib see töötada. Kui klient seda ei paku, ei mõjuta süsteemse proksi täitmine tunnelit üldse.
Millal see ei muuda midagi
IKEv2 või IPsec profiil ei muutu HTTP tunneliks sellepärast, et proksiväli on täidetud. Ei muutu ka WireGuard, mille konfiguratsioonivormingul puudub proksi mõiste. Lüüsi pordi muutmine ei muuda ka selle protokolli. Ja lõpp-punkt, mis vastab tavalisele HTTPS-ile, ei ole automaatselt VPN-i kuulaja.
Sama lõks püüab inimesi, kes kopeerivad PPTP-ajastu profiile vanadest iPad-i juhenditest. Valikud on liideses endiselt olemas; nende taga olev teenus ei räägi enam seda protokolli.
Otsustamine, millist kihti parandada
Küsige, milline kiht ebaõnnestus, enne kui midagi muudate. Kui klient ei saa sessiooni luua, on probleem transpordis ja proksiväli on ebaoluline. Kui tunnel töötab, aga üks rakendus ei jõua oma serverini, tasub uurida rakenduse proksit. Kui tunnel töötab ja kõik rakendused ebaõnnestuvad, on kahtlusalused marsruutimine ja DNS tunneli sees.
Esimesel juhul küsige operaatorilt, millist kinnitatud alternatiivset transporti või võrku ta toetab. OpenVPN üle TCP 443 on olemas, sest mõned võrgud lubavad ainult seda, ja see nõuab endiselt, et server seda kuulaks.
Ärge käsitlege blokeeritud UDP-porti loana improviseerida. Hoidke lüüsi sertifikaadi või identiteedi kontrollid terveina, selle asemel et need välja lülitada, et käepigistus sobiks.
Kinnitage mõlemad kihid ükshaaval
Kinnitage esmalt tunnel: kontrollige kliendi olekulehelt loodud sessiooni ja nullist erinevat baitide arvu. Seejärel lugege proksiseadet otse, kasutades scutil --proxy tegeliku konfiguratsiooni jaoks või networksetup -getwebproxy Wi-Fi salvestatud väärtuse jaoks. Seejärel testige ühte rakendust, mis austab süsteemset proksit, ja ühte, mis seda eirab, sest paljud natiivsed rakendused eiravad seda.
Kolm tulemust, kolm erinevat parandust.
Kui mõlemad kihid teatavad edust ja rakendus ikka ebaõnnestub, vaadake jagatud tunnelit, DNS-i ja rakenduse enda võrguseadeid. See on kolmas kiht ja ka see ei ole proksiväli.