Mengapa proxy PAC di VM tamu gagal dengan URL host

«Host memakai file PAC ini, jadi saya menaruh URL yang sama di VM» adalah kalimat yang wajar dan rencana yang tidak lengkap. URL PAC menunjuk ke skrip kebijakan, bukan ke proxy. Sampai tamu dapat mengambil skrip itu, mengevaluasinya dengan alamat tamu sendiri, lalu mencapai proxy apa pun yang disebut skrip, URL hanyalah string di sebuah kolom pengaturan. Sebagian besar kebingungan soal kebijakan proxy di mesin virtual muncul karena satu baris itu dianggap sebagai seluruh konfigurasi.

URL PAC adalah skrip, bukan proxy

File itu berisi fungsi yang menerima URL dan host dan mengembalikan deskripsi proxy atau kata DIRECT. Tidak ada apa pun di URL yang memberi tahu aplikasi ke mana harus mengirim lalu lintas; keputusan itu terjadi saat runtime, di dalam skrip, dengan data yang diminta skrip dari platform. Dialog pengaturan yang menerima URL PAC sebenarnya menerima penunjuk ke prosedur keputusan.

Perbedaan itulah sebabnya menyalin URL bisa tampak berhasil. Kolomnya terisi, pengaturannya tersimpan, dan kegagalan baru muncul kemudian, ketika skrip tidak dapat diambil atau ketika skrip mengembalikan proxy yang tidak dapat dijangkau tamu.

Keempat langkah gagal dengan cara masing-masing

Di dalam tamu, empat hal harus terjadi secara berurutan, dan masing-masing punya tanda kesalahannya sendiri. Tamu mengambil file PAC. Aplikasi mengevaluasi skrip untuk URL yang diminta memakai informasi lokal. Proxy yang dipilih diresolusi dan dicapai. Autentikasi terjadi jika proxy memerlukannya.

Mulailah dengan membuktikan pengambilan, karena tanpa itu semua yang berikutnya tidak bermakna. File PAC di server privat memerlukan jalur yang diizinkan ke server itu sebelum aturan apa pun dapat membantu, dan pilihan proxy di dalam skrip yang tidak terjangkau tidak dapat membuat jalur yang akan mengambilnya:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Jika permintaan itu gagal dari tamu dan berhasil dari host, masalahnya adalah jalur tamu ke server PAC, bukan isi skrip. Jika skrip mengembalikan file JavaScript, lanjutkan ke langkah kedua dan cari tahu apa yang diputuskan skrip untuk konteks tamu.

Skrip yang sama memutuskan berbeda di dalam VM

Fungsi PAC dapat memeriksa host yang diminta dan informasi tentang mesin yang menjalankan evaluasi. Aturan yang dibangun di atas alamat klien sendiri, misalnya yang memeriksa alamat antarmuka atau keanggotaan subnet, akan melihat alamat tamu, bukan alamat host fisik. Di balik NAT sisi host, keduanya alamat yang berbeda, sehingga skrip yang sama dapat memilih proxy lain atau kembali ke DIRECT di dalam VM.

Itu bukan bug di dalam skrip. Skrip melakukan tepat apa yang dimaksudkan saat ditulis, dengan masukan berbeda, dan itu menjelaskan laporan membingungkan ketika host memakai proxy dan tamu terhubung langsung. Reproduksilah keputusannya alih-alih menalar tentangnya: evaluator PAC yang menerima alamat dan URL, jika distribusi Anda menyertakannya, menyelesaikan pertanyaan dengan satu perintah. Jika tidak, ujilah dengan aplikasi yang benar-benar akan dipakai, dan bacalah log proxy-nya alih-alih menebak.

Jangan menyimpulkan bahwa tamu mewarisi pengaturan proxy host karena lalu lintasnya melewati terjemahan sisi host. Terjemahan jaringan meneruskan paket; ia tidak menyalin konfigurasi aplikasi, dan proxy sistem adalah konfigurasi aplikasi.

Alat yang sama sekali tidak membaca PAC

Alat baris perintah adalah batas tersendiri, dan di sinilah banyak waktu terbuang. curl tidak menjalankan file PAC, seperti yang dikatakan oleh dokumentasi proxy dengan jelas. Mengarahkan variabel proxy ke URL unduhan PAC tidak membuat skrip menjadi titik akhir proxy; alat itu akan mencoba berbicara HTTP dengan file JavaScript dan gagal dengan cara yang tampak seperti masalah jaringan.

Hal yang sama berlaku bagi banyak manajer paket, runtime bahasa, dan alat build, yang hanya mematuhi variabel proxy eksplisit atau konfigurasi mereka sendiri. Jika uji yang Anda pedulikan adalah alat CLI, konfigurasikan dengan proxy konkret yang akan dipilih skrip PAC, dan catat bagaimana Anda menurunkan pilihan itu agar orang berikutnya dapat mengulanginya.

Untuk aplikasi desktop di Linux, pengaturan sistem harus diatur ke mode otomatis dan juga diberi URL; URL yang disimpan saat mode masih manual tidak melakukan apa pun. Periksa keduanya, dan periksa di dalam tamu:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT juga sebuah keputusan

Hasil PAC berupa DIRECT berarti aplikasi melewati proxy HTTP, bukan bahwa aplikasi telah lolos dari jaringan. Koneksi yang dihasilkan tetap dapat mengikuti rute sistem operasi melalui terowongan, atau gagal karena alasan yang sama sekali tidak berkaitan dengan penggunaan proxy. Sebaliknya, hasil proxy menjelaskan permintaan satu aplikasi, bukan setiap proses di dalam tamu.

Jadi verifikasi ke arah sebagaimana persyaratan itu ditulis. Jika persyaratannya «aplikasi ini mencapai situs internal», buktikan bahwa aplikasi itu mencapai, dan catat proxy atau rute mana yang membawanya. Jika persyaratannya «VM berada di jaringan perusahaan», peramban yang berfungsi melalui proxy terpilih adalah bukti untuk peramban itu dan tidak lebih.

Perbaiki rantainya di dalam tamu alih-alih mematikan terowongan host atau melonggarkan kebijakan penerusan agar sebuah uji lulus. Rantai itu punya empat mata rantai, dan perubahan yang melewati salah satunya akan bertahan sampai skrip diperbarui lagi atau alamat tamu berubah.