Browser cabang ke proxy: dua koneksi, dua rute

Browser cabang di belakang proxy eksplisit membuka dua koneksi, dan keduanya gagal karena alasan berbeda. Yang pertama adalah browser ke listener proxy, dibawa melalui VPN cabang. Yang kedua adalah proxy ke situs web, memakai resolver, rute, dan kebijakan keluar milik proxy sendiri. Tiket dukungan yang memperlakukan keduanya sebagai satu alur mengirim orang ke perangkat yang salah selama berjam-jam. Siapkan masing-masing dengan sengaja dan uji keduanya dalam urutan itu.

Langkah 1: tuliskan kedua alur

Tujuan langsung browser adalah listener proxy, bukan setiap situs yang akhirnya dikunjungi pengguna. Satu kalimat itu menyelesaikan sebagian besar kebingungan dalam desain ini.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Sumber berbeda, rute berbeda, izin berbeda. Simpan sketsa di catatan perubahan, karena setiap pemeriksaan berikutnya merujuk ke salah satu dari dua bagiannya.

Langkah 2: beri browser jalur ke listener

Catat nama host proxy, port listener, persyaratan autentikasi, dan sumber cabang yang diizinkan. Daftar itu adalah kriteria penerimaan untuk alur pertama, dan harus mencakup resolusi nama privat serta rute terowongan.

Terapkan aturan jaringan yang sempit untuk layanan yang dimaksud alih-alih menerbitkan proxy tanpa batas ke internet. Proxy dapat tetap berada di jaringan internal ketika klien yang dimaksud memiliki jalur yang didukung ke sana.

Langkah 3: konfigurasikan browser, bukan hanya tabel rute

Gunakan pengaturan proxy browser, berkas PAC, atau mekanisme penemuan terkelola organisasi. Mengirim paket situs web biasa ke alamat proxy dengan rute tidak membuat browser berbicara protokol proxy; itu intersepsi transparan dan termasuk desain gateway yang lain.

Tuliskan aplikasi mana yang mematuhi pengaturan itu. Klien email, pembaru, dan gim sering tidak mematuhinya, dan mereka akan terus memakai jalur biasa.

Langkah 4: buktikan koneksi keluar proxy

Proxy memerlukan resolver sendiri dan rute yang diizinkan ke situs web, ditambah kebijakan firewall atau terjemahan yang dibutuhkan batas internetnya. Browser yang mencapai listener tidak membuktikan satu pun dari itu. Uji alur kedua dari proxy itu sendiri, dengan tujuan dan port yang sama seperti yang dilaporkan pengguna.

Untuk HTTPS, CONNECT membuka terowongan ke tujuan yang diminta. Penerusan biasa tidak menyerahkan halaman yang didekripsi ke proxy, dan menonaktifkan validasi sertifikat untuk mengimprovisasi inspeksi bukanlah solusi.

Langkah 5: bedakan empat kegagalan

Tantangan autentikasi proxy adalah 407 dari listener. CONNECT yang ditolak adalah keputusan kebijakan di proxy, biasanya dengan status dan baris log sendiri. Koneksi keluar yang gagal tampak seperti waktu tunggu habis atau reset yang dicatat proxy terhadap tujuan. Respons situs web berarti kedua koneksi berhasil dan masalahnya ada di asal.

Laporkan batas yang Anda amati, bukan ringkasan bahwa VPN gagal.

Langkah 6: tentukan cakupan dan rencanakan cadangan

Putuskan apa yang terjadi ketika proxy atau terowongan tidak tersedia, dan nyatakan dengan jelas lalu lintas mana yang dicakup desain ini. Ini membawa akses web dari klien yang mematuhi pengaturan proxy; ini tidak membawa email, protokol perangkat sembarang, atau perangkat lunak yang mengabaikan konfigurasi.

Validasi operasi browser yang diperlukan dan satu penolakan yang diperlukan di bawah rencana yang disetujui sebelum memperluas desain ke lebih banyak klien.