VPN di Mac dan proxy PAC: dua keputusan, bukan satu pengaturan

Mac Anda mengunduh skrip kebijakan lalu menanyakan skrip itu perantara mana yang harus dipakai sebuah permintaan, sementara terowongan hanya memutuskan bagaimana hop yang dipilih dicapai. Kedua jawaban berakhir di soket yang sama, jadi permintaan yang gagal setelah keduanya berhasil tampak seperti satu kesalahan padahal ada dua. Memisahkan pengunduhan dari pemilihan, dan pemilihan dari rute, adalah sebagian besar pekerjaan dalam tiket ini. Urutan di bawah mengikuti apa yang sebenarnya dilakukan macOS, dengan pemeriksaan yang membuat setiap tahap terlihat.

Di mana alamat PAC dan proxy menyimpang

Alamat seperti https://config.corp.example/proxy.pac menamai dokumen untuk diunduh, dan dokumen itu menamai server untuk mengirim lalu lintas. Menempelkan URL ke kolom host proxy meminta klien membuka koneksi proxy ke server file yang tidak pernah mendengarkan koneksi semacam itu. Di dalam file ada fungsi yang dipanggil klien per permintaan, dan nilai kembaliannya adalah hop berikutnya untuk satu tujuan itu. Perantaraan itu menjelaskan mengapa dua mesin pada layanan jaringan yang sama bisa berperilaku berbeda meski keduanya memegang URL yang benar. Ini juga menjelaskan mengapa perubahan kebijakan berlaku tanpa ada yang menyentuh proxy itu sendiri.

Baca skrip sebelum menafsirkan apa pun di hilir, karena aturan di dalamnya membawa pengecualian organisasi dan urutan penerapannya. Rentang luas yang awal dapat menutupi sufiks internal yang lebih akhir, dan host yang jelas harus melewati proxy tetap memakainya. Ketika seseorang bersikeras kebijakannya salah, skrip adalah satu-satunya tempat klaim itu diselesaikan.

Skrip harus diambil sebelum ia memutuskan apa pun

Mengunduh kebijakan memerlukan nama yang terurai dan rute ke apa pun yang menyajikan file itu, dan terowongan yang tersambung tidak menjamin keduanya. Jika host hanya diurai melalui DNS privat, resolver yang dipakai saat itu menentukan apakah pengunduhan bisa dimulai. Jika host berada di rentang privat, rute harus ada dari mesin ini, bukan dari laptop rekan. Salinan yang di-cache pada sesi sebelumnya menyembunyikan semua ini sampai cache kedaluwarsa atau mesin dimulai ulang.

Jalankan tiga pemeriksaan di bawah secara berurutan dan berhenti pada kegagalan pertama, karena tahap-tahapnya tidak berbagi penyebab. Bersama-sama mereka menunjukkan apakah kebijakan dikonfigurasi, apakah bisa dijangkau, dan apa yang dikembalikannya.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Perintah pertama mencetak kamus proxy untuk layanan aktif, termasuk URL konfigurasi otomatis apa pun yang dipegang sistem. Yang kedua melaporkan URL yang terpasang pada satu layanan bernama, yang penting pada laptop yang berpindah antara Wi-Fi dan Ethernet. Yang ketiga mengambil file tanpa merendernya, sehingga 404, waktu tunggu, dan kegagalan resolver tetap bisa dibedakan. Jika perintah terakhir itu mengembalikan skrip sementara aplikasi masih gagal, masalahnya sudah melewati pengambilan.

Apa yang sebenarnya dilewati jawaban DIRECT

Spesifikasi PAC memberi klien kosakata kecil, dan DIRECT adalah salah satu katanya. Kata itu memberi tahu klien untuk melewati proxy bagi permintaan tersebut dan tidak mengatakan apa pun tentang antarmuka mana yang kemudian dipakai soket. Soket langsung pada terowongan penuh tetap keluar melalui VPN dan tetap menunjukkan alamat keluar terowongan kepada tujuan.

Membaca DIRECT sebagai di luar VPN adalah kesalahan yang mengirim orang ke panel pengaturan yang salah. Bayangan cerminnya sama umumnya, karena proxy privat bisa dijangkau lewat rute terpisah sementara sisa mesin tetap di luar terowongan. Apa yang dilaporkan tujuan saat itu milik keluaran proxy itu sendiri, yang mungkin berada di negara lain. Menuliskan harapan untuk satu host internal dan satu host publik cepat membuka ini, karena skrip sering menjawab keduanya secara berbeda. Setelah Anda tahu hop mana yang menghasilkan alamat itu, laporan berhenti menjadi misterius.

Tiga kegagalan yang muncul sebagai satu halaman kesalahan

Kebijakan mungkin gagal diunduh, proxy yang dipilih mungkin tidak terjangkau, dan permintaan yang tiba di layanan mungkin tetap ditolak di sana. Ketiganya datang sebagai waktu tunggu atau halaman kesalahan umum, dan tidak satu pun menyebut tahap yang rusak. Menangkap keputusan di samping kesalahan adalah yang memisahkan mereka. Dua probe di bawah menguji hop yang dipilih skrip, satu untuk setiap cabang yang bisa dikembalikannya.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Koneksi yang selesai ke proxy memindahkan pertanyaan ke autentikasi atau ke kebijakan proxy itu sendiri, yang punya pemilik berbeda. Koneksi yang selesai ke host internal tanpa proxy di jalurnya menyingkirkan rute dan menunjuk ke kebijakan. Kedua perintah mengabaikan kamus proxy macOS kecuali shell mengekspor variabel proxy, jadi bersihkan dulu. Tidak ada probe yang membuktikan yang lain, dan itulah sebabnya satu halaman kesalahan menyesatkan begitu lama.

Apa yang diserahkan bersama tiket

Kirim layanan jaringan aktif, URL PAC, hasil evaluasi untuk host yang gagal, dan tahap tempat kesalahan muncul. Keempatnya memungkinkan orang berikutnya mereproduksi keputusan alih-alih menebak lapisan mana yang terlibat. Tambahkan status terowongan pada saat pengujian, karena hasil yang diambil sebelum menyambung ulang sudah usang. Simpan juga revisi skrip, karena file kebijakan berubah tanpa pemberitahuan dan jawaban kemarin mungkin tidak lagi berlaku.

Catat bagaimana klien berperilaku ketika skrip tidak dapat diambil, karena implementasinya berbeda dan keputusan proxy bukan tombol mati seluruh perangkat. Sebagian beralih ke koneksi langsung dan sebagian lagi gagal tertutup, dan perbedaan itu mengubah apakah gangguan tampak seperti proxy rusak atau kebijakan yang berfungsi. Konfirmasikan perilakunya untuk klien dan versi yang tepat sebelum mengandalkannya saat insiden.