Apple VPN профайл дахь Proxy талбар үнэндээ юу хийдэг
Прокси талбарыг бөглөх нь VPN-ийг HTTP болгодоггүй. Хоёр холболт оролцож, талбар нь зөвхөн нэг рүү нь хүрдэг.
Apple VPN тохиргооны Proxy талбарыг бөглөх нь туннелийг веб портоор дамжуулна гэж бодогдоно. Гэхдээ тийм биш. Талбар нь нийцтэй апп тэнд илгээхээр шийдсэн траффикийн хувьд аппын түвшний зуучлагчийг сонгодог. Харин VPN клиентийн өөрийнх нь гарц руу хийх холболтыг таны тохируулсан протокол, сонсогч, тээвэр тодорхойлдог бөгөөд эдгээр нь тусдаа шийдвэр юм.
Хоёр холболт, хоёр эзэн
Ийм тохиргоо бүр клиентээс гарц руу болон аппаас очих газар руу холболтыг агуулдаг. Proxy хэсэг нь хоёр дахь тухай ярьдаг боловч эхнийхтэй нэг профайлд байдаг.
| 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-ын прокси тохиргооны лавлагаа нь HTTP, HTTPS, SOCKS болон автомат прокси тохиргоог жагсаасан бөгөөд энэ нь аппуудын прокси сонголтын тайлбар юм. Эдгээр бичлэгийн аль нь ч IPsec эсвэл WireGuard пакет гарц руу хэрхэн хүрдэг тухай хэлээгүй.
Асуудлыг шийдэх хурдан шалгалт энд байна. VPN клиент өөрийн логт мэдээлдэг порт болон протоколыг нэрлэнэ үү. Хэрэв тэр мөр одоо ч UDP 500 эсвэл UDP 51820 гэж хэлж байвал прокси талбар түүнд юу ч өөрчлөөгүй.
Талбар хэзээ зөв хэрэгсэл вэ
Прокси туннелийн өмнө зогсох бодит тохиолдол байдаг ч энэ нь профайлын талбар биш, клиентийн боломж. OpenVPN-ийн гарын авлага HTTP CONNECT проксигоор дамжуулдаг TCP холболтын хувьд --http-proxy-г баримтжуулсан. Үүнийг ашиглахад тохирох клиентийн сонголт, тэр замаар хүрч болох гарц, ашиглаж буй порт руу CONNECT зөвшөөрдөг прокси шаардлагатай.
Хэрэв клиент чинь тэр сонголтыг санал болгож, сүлжээ порт руу CONNECT зөвшөөрвөл ажиллаж болно. Клиент санал болгохгүй бол системийн прокси бөглөх нь туннелд огт нөлөөлөхгүй.
Хэзээ юу ч өөрчлөхгүй
Прокси талбар бөглөгдсөнөөс IKEv2 эсвэл IPsec профайл HTTP туннель болохгүй. WireGuard ч мөн биш, түүний тохиргооны формат прокси гэсэн ойлголтгүй. Гарцын портыг солих нь түүний протоколыг ч өөрчлөхгүй. Энгийн HTTPS-д хариулдаг төгсгөлийн цэг автоматаар VPN сонсогч болохгүй.
Мөн адил урхи хуучин iPad гарын авлагаас PPTP үеийн профайлыг хуулдаг хүмүүсийг барьдаг. Сонголтууд интерфейсд одоо ч байна; тэдний ард байгаа үйлчилгээ энэ протоколоор ярихаа больсон.
Аль давхаргыг засахыг шийдэх
Ямар нэг юмыг өөрчлөхөөс өмнө аль давхарга бүтэлгүйтсэнийг асуугаарай. Клиент сесс тогтоож чадахгүй бол асуудал тээвэрт байгаа бөгөөд прокси талбар хамаагүй. Туннель ажиллаж байгаа ч нэг апп өөрийн серверт хүрч чадахгүй бол аппын проксийг шалгах нь зүйтэй. Туннель ажиллаж, бүх апп бүтэлгүйтвэл сэжигтэн нь туннелийн доторх маршрутлал болон DNS.
Эхний тохиолдолд оператороос аль зөвшөөрөгдсөн өөр тээвэр эсвэл сүлжээг дэмждэг талаар асуугаарай. TCP 443 дээрх OpenVPN нь зарим сүлжээ зөвхөн үүнийг зөвшөөрдөг тул байдаг бөгөөд сервер үүнийг сонсож байх шаардлага хэвээр.
Хаагдсан UDP портыг бие даасан шийдлийн зөвшөөрөл гэж бүү үз. Handshake-ийг тааруулахын тулд гарцын сертификат эсвэл хэн болохыг шалгах шалгалтыг унтраахын оронд хэвээр нь хадгал.
Хоёр давхаргыг нэг нэгээр нь баталгаажуул
Эхлээд туннелийг баталгаажуул: клиентийн төлөв хуудаснаас тогтоосон сесс болон тэгээс ялгаатай байтын тоог шалга. Дараа нь прокси тохиргоог шууд унш, үр дүнтэй тохиргоонд scutil --proxy, хадгалсан утганд networksetup -getwebproxy Wi-Fi ашигла. Дараа нь системийн проксийг хүндэтгэдэг нэг апп, түүнийг үл тоомсорлодог нэг аппыг туршиж үз, учир нь олон төрөлх апп үүнийг үл тоомсорлодог.
Гурван үр дүн, гурван өөр засвар.
Хоёр давхарга хоёулаа амжилт мэдээлсэн ч апп бүтэлгүйтсээр байвал хуваасан туннель, DNS болон аппын өөрийнх нь сүлжээний тохиргоог хар. Энэ нь гурав дахь давхарга бөгөөд тэр ч бас прокси талбар биш.