curl tidak bisa membaca berkas PAC Anda: teruskan proxy saja
PAC adalah kebijakan JavaScript; curl menginginkan endpoint. Tanyakan proxy mana yang dipilih kebijakan untuk URL Anda, teruskan proxy itu, dan perhatikan NO_PROXY serta TLS.
Alamat berkas PAC dan endpoint proxy tampak bisa saling menggantikan dalam berkas konfigurasi, padahal tidak. Yang satu adalah program kebijakan yang harus dievaluasi untuk setiap URL; yang lain adalah host dan port yang menerima koneksi. curl hanya memahami yang kedua. Meneruskan alamat PAC ke --proxy adalah kesalahan kategori yang gagal dengan cara membingungkan, biasanya setelah timeout CONNECT yang lama ke server web.
Apa sebenarnya masing-masing
| Anda punya | Apa itu | Apa yang curl lakukan dengannya |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript yang mengembalikan proxy atau koneksi langsung untuk URL tertentu | Mengambilnya sebagai berkas dan berhenti di situ |
http://proxy.corp.example:8080 | Listener yang menerima permintaan melalui proxy | Memakainya, termasuk CONNECT untuk tujuan HTTPS |
Hal itu dinyatakan jelas oleh FAQ curl: curl tidak menyediakan interpretasi JavaScript maupun PAC. Pembungkus di sekitar curl yang memahami PAC bisa, tetapi curl sendiri tidak, dan tidak ada flag yang mengubahnya menjadi peramban.
Mengapa peramban berhasil dan curl tidak
Peramban terintegrasi dengan konfigurasi proxy sistem, mengambil berkas PAC, dan menjalankan aturannya terhadap URL yang Anda buka. Evaluasi itulah layanan yang diberikan berkas PAC, dan itu terjadi di dalam peramban, bukan di dalam terminal Anda.
Mengunduh berkas PAC dengan curl hanya mengambil teksnya. Itu tidak membuat curl menjalankan kebijakan, dan membacanya secara manual untuk menemukan proxy adalah versi manual dari evaluasi yang sama, dengan peluang yang sama untuk memilih cabang yang salah. Jika Anda membacanya, bacalah pernyataan return yang cocok dengan host Anda, bukan nama proxy pertama dalam berkas. Sebagian besar berkas PAC berisi beberapa, dan hanya satu cabang yang berlaku bagi Anda.
Untuk proxy HTTP yang disetujui dan layanan HTTPS yang disetujui, permintaan ilustratif adalah:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusAlamat pertama adalah listener proxy, yang kedua adalah layanan yang Anda inginkan. Ini adalah endpoint contoh, bukan pengujian yang dilakukan seseorang, jadi gantilah dengan skema, port, dan alur autentikasi organisasi Anda.
Pilih proxy untuk tujuan ini
Tanyakan kepada administrator proxy mana yang dipilih kebijakan untuk URL yang Anda butuhkan, bukan proxy mana yang dimiliki organisasi. Aturan PAC dapat memberikan hasil berbeda untuk layanan internal, situs publik, dan kondisi failover, dan aturan yang cocok dengan URL Anda hari ini bisa cocok dengan yang lain setelah penyuntingan.
Jika alur kerja membutuhkan lebih dari satu permintaan yang diketahui, gunakan pengaturan statis yang didukung administrator atau integrasi sadar-PAC yang disetujui. Menanamkan satu alamat hasil salinan berfungsi sampai hari kebijakan berubah dan tidak ada yang ingat mengapa alamat itu dipilih.
Lalu lihat apa yang diwarisi curl. Variabel lingkungan proxy dan NO_PROXY dapat menimpa atau mengecualikan proxy yang Anda teruskan, dan pengecualian yang cocok dengan tujuan Anda mengirim permintaan langsung tanpa bicara. Pertahankan kebijakan yang dimaksudkan alih-alih menghapus setiap pengecualian atau memaksa semuanya melalui satu alamat. Jalankan permintaan sekali dengan -v dan periksa alamat mana yang benar-benar dihubunginya.
Pisahkan kedua identitas TLS
Dengan proxy HTTPS, ada dua koneksi TLS yang berperan: koneksi Anda ke proxy dan koneksi proxy ke tujuan. Masing-masing punya identitas sendiri untuk diverifikasi, dan menonaktifkan verifikasi untuk salah satunya bukan perbaikan PAC, melainkan masalah kedua yang ditambahkan ke yang pertama.
Biarkan verifikasi aktif dan bacalah kegagalan yang Anda dapat. Tantangan autentikasi proxy, proxy yang tidak dapat dijangkau, dan penolakan dari situs web adalah tiga hasil berbeda, dan hanya yang pertama soal kredensial. VPN tetap harus menyediakan jalur yang diizinkan ke proxy privat, termasuk resolusi nama untuk host proxy itu sendiri, sebelum semua ini bisa berhasil.
Catat endpoint, skema, port, metode autentikasi, pengecualian, dan jalur VPN ke proxy. Catatan itulah yang membuat permintaan berikutnya dapat direproduksi, dan itulah bedanya antara mengenal proxy Anda dan menduganya.