Apa yang sebenarnya dilakukan medan Proxy dalam profil VPN Apple
Mengisi medan proksi tidak menjadikan VPN sebagai HTTP. Terdapat dua sambungan terlibat, dan medan itu hanya sampai kepada satu daripadanya.
Mengisi medan Proxy dalam konfigurasi VPN Apple terasa seolah-olah ia akan mengubah hala terowong melalui port web. Ia tidak berbuat demikian. Medan itu memilih perantara pada peringkat aplikasi untuk trafik yang dipilih oleh aplikasi serasi untuk dihantar ke sana. Manakala sambungan klien VPN sendiri ke gateway-nya ditentukan oleh protokol, pendengar dan pengangkutan yang anda konfigurasikan, dan itu adalah keputusan yang berasingan.
Dua sambungan, dua pemilik
Sebarang persediaan seperti ini melibatkan sambungan dari klien ke gateway dan sambungan dari aplikasi ke destinasi. Bahagian Proxy membincangkan yang kedua, walaupun ia berada dalam profil yang sama dengan yang pertama.
| 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 |
Rujukan tetapan proksi Apple menyenaraikan HTTP, HTTPS, SOCKS dan konfigurasi proksi automatik, yang merupakan huraian pilihan proksi aplikasi. Tiada satu pun catatan itu menyatakan bagaimana paket IPsec atau WireGuard sampai ke gateway.
Berikut ialah pemeriksaan pantas yang menyelesaikannya. Namakan port dan protokol yang dilaporkan oleh klien VPN dalam lognya. Jika baris itu masih menyebut UDP 500 atau UDP 51820, medan proksi tidak mengubah apa-apa padanya.
Bila medan itu alat yang betul
Ada kes sebenar di mana proksi berada di hadapan terowong, tetapi itu ciri klien dan bukan medan profil. Manual OpenVPN mendokumenkan --http-proxy untuk sambungan TCP yang dibawa melalui proksi HTTP CONNECT. Untuk menggunakannya perlu pilihan klien yang sepadan, gateway yang boleh dicapai melalui cara itu, dan proksi yang membenarkan CONNECT ke port yang digunakan.
Jika klien anda menawarkan pilihan itu dan rangkaian membenarkan CONNECT ke port tersebut, ia mungkin berfungsi. Jika klien tidak menawarkannya, mengisi proksi sistem tidak memberi sebarang kesan pada terowong.
Bila ia tidak mengubah apa-apa
Profil IKEv2 atau IPsec tidak menjadi terowong HTTP kerana medan proksi diisi. WireGuard juga tidak, yang format konfigurasinya tidak mengenal konsep proksi. Menukar port gateway juga tidak menukar protokolnya. Dan titik akhir yang menjawab HTTPS biasa tidak automatik menjadi pendengar VPN.
Perangkap yang sama menangkap orang yang menyalin profil era PPTP daripada panduan iPad lama. Pilihan itu masih ada dalam antara muka; perkhidmatan di belakangnya tidak lagi bertutur dalam protokol itu.
Memutuskan lapisan mana yang perlu dibaiki
Tanya lapisan mana yang gagal sebelum mengubah apa-apa. Jika klien tidak dapat mewujudkan sesi, masalahnya pada pengangkutan dan medan proksi tidak relevan. Jika terowong aktif tetapi satu aplikasi tidak dapat mencapai pelayannya, proksi aplikasi patut diperiksa. Jika terowong aktif dan semua aplikasi gagal, suspek utama ialah penghalaan dan DNS di dalam terowong.
Untuk kes pertama, tanya pengendali pengangkutan atau rangkaian alternatif yang diluluskan mana yang disokongnya. OpenVPN melalui TCP 443 wujud kerana sesetengah rangkaian hanya membenarkan itu, dan ia masih memerlukan pelayan mendengarnya.
Jangan anggap port UDP yang disekat sebagai kebenaran untuk berimprovisasi. Kekalkan pemeriksaan sijil atau identiti gateway, bukannya mematikannya supaya jabat tangan sepadan.
Sahkan kedua-dua lapisan satu demi satu
Sahkan terowong dahulu: periksa halaman status klien untuk sesi yang terjalin dan kiraan bait yang bukan sifar. Kemudian baca tetapan proksi secara terus, dengan scutil --proxy untuk konfigurasi berkesan atau networksetup -getwebproxy Wi-Fi untuk nilai tersimpan. Kemudian uji satu aplikasi yang menghormati proksi sistem dan satu yang mengabaikannya, kerana banyak aplikasi asli mengabaikannya.
Tiga keputusan, tiga pembetulan berbeza.
Jika kedua-dua lapisan melaporkan kejayaan dan aplikasi masih gagal, lihat terowong berpecah, DNS dan tetapan rangkaian aplikasi itu sendiri. Itu lapisan ketiga, dan itu juga bukan medan proksi.