Mitä Proxy-kenttä Apple VPN -profiilissa todella tekee
Proxy-kentän täyttäminen ei muuta VPN:ää HTTP:ksi. Mukana on kaksi yhteyttä, ja kenttä ulottuu vain toiseen niistä.
Proxy-kentän täyttäminen Apple VPN -kokoonpanossa tuntuu siltä kuin sen pitäisi ohjata tunneli verkkoportin kautta. Ei tee niin. Kenttä valitsee sovellustason välittäjän liikenteelle, jonka yhteensopiva sovellus päättää lähettää sinne. VPN-asiakkaan oman yhteyden yhdyskäytäväänsä määräävät sen sijaan määrittämäsi protokolla, kuuntelija ja kuljetus, ja ne ovat erillisiä päätöksiä.
Kaksi yhteyttä, kaksi omistajaa
Jokainen tällainen kokoonpano sisältää yhteyden asiakkaasta yhdyskäytävään ja yhteyden sovelluksesta kohteeseen. Proxy-osio puhuu jälkimmäisestä, vaikka se on samassa profiilissa kuin ensimmäinen.
| 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 |
Applen välityspalvelinasetusten viite luettelee HTTP:n, HTTPS:n, SOCKS:n ja automaattisen välityspalvelinmäärityksen, mikä kuvaa sovellusten välityspalvelinvalintoja. Mikään näistä kohdista ei kerro, miten IPsec- tai WireGuard-paketti saavuttaa yhdyskäytävän.
Tässä on nopea tarkistus, joka ratkaisee asian. Nimeä portti ja protokolla, jotka VPN-asiakas ilmoittaa lokissaan. Jos rivi sanoo edelleen UDP 500 tai UDP 51820, Proxy-kenttä ei muuttanut siinä mitään.
Milloin kenttä on oikea työkalu
On todellinen tapaus, jossa välityspalvelin on tunnelin edessä, mutta se on asiakkaan ominaisuus eikä profiilikenttä. OpenVPN:n käsikirja dokumentoi --http-proxy TCP-yhteyksille, joita kuljetetaan HTTP CONNECT -välityspalvelimen kautta. Sen käyttäminen vaatii vastaavan asiakasasetuksen, sitä kautta tavoitettavan yhdyskäytävän ja välityspalvelimen, joka sallii CONNECTin käytettävään porttiin.
Jos asiakkaasi tarjoaa tämän asetuksen ja verkko sallii CONNECTin porttiin, se voi toimia. Jos asiakas ei tarjoa sitä, järjestelmän välityspalvelimen täyttäminen ei vaikuta tunneliin lainkaan.
Milloin se ei muuta mitään
IKEv2- tai IPsec-profiilista ei tule HTTP-tunnelia siksi, että Proxy-kenttä on täytetty. Ei myöskään WireGuardista, jonka kokoonpanomuodossa ei ole välityspalvelimen käsitettä. Yhdyskäytävän portin vaihtaminen ei vaihda sen protokollaa. Eikä tavalliseen HTTPS:ään vastaava päätepiste ole automaattisesti VPN-kuuntelija.
Sama ansa nappaa ne, jotka kopioivat PPTP-aikakauden profiileja vanhoista iPad-oppaista. Asetukset ovat yhä käyttöliittymässä; niiden takana oleva palvelu ei enää puhu tätä protokollaa.
Päätä, mikä kerros korjata
Kysy, mikä kerros epäonnistui, ennen kuin muutat mitään. Jos asiakas ei saa istuntoa muodostettua, ongelma on kuljetuksessa ja Proxy-kenttä on merkityksetön. Jos tunneli on pystyssä mutta yksi sovellus ei tavoita palvelintaan, sovelluksen välityspalvelinta kannattaa tutkia. Jos tunneli on pystyssä ja kaikki sovellukset epäonnistuvat, epäiltyinä ovat tunnelin sisäinen reititys ja DNS.
Ensimmäisessä tapauksessa kysy operaattorilta, mitä hyväksyttyä vaihtoehtoista kuljetusta tai verkkoa se tukee. OpenVPN TCP 443:n yli on olemassa, koska jotkin verkot sallivat vain sen, ja se vaatii silti, että palvelin kuuntelee sitä.
Älä pidä estettyä UDP-porttia lupana improvisoida. Pidä yhdyskäytävän varmenne- tai identiteettitarkistukset ehjinä sen sijaan, että kytkisit ne pois kättelyn sopimiseksi.
Vahvista kaksi kerrosta yksi kerrallaan
Vahvista ensin tunneli: tarkista asiakkaan tilasivulta muodostettu istunto ja nollasta poikkeava tavumäärä. Lue sitten välityspalvelinasetus suoraan, käyttäen scutil --proxy tehokkaaseen kokoonpanoon tai networksetup -getwebproxy Wi-Fi tallennettuun arvoon. Testaa sen jälkeen yhtä sovellusta, joka kunnioittaa järjestelmän välityspalvelinta, ja yhtä, joka jättää sen huomiotta, koska monet natiivit sovellukset jättävät sen huomiotta.
Kolme tulosta, kolme erilaista korjausta.
Jos molemmat kerrokset raportoivat onnistumisesta ja sovellus epäonnistuu edelleen, katso jaettua tunnelointia, DNS:ää ja sovelluksen omia verkkoasetuksia. Se on kolmas kerros, eikä sekään ole Proxy-kenttä.