Pelayar cawangan ke proksi: dua sambungan, dua laluan
Pelayar bercakap dengan pendengar proksi, dan proksi bercakap dengan tapak. Konfigurasikan kedua-dua sambungan dan uji sebagai dua kegagalan berasingan.
Pelayar cawangan di belakang proksi eksplisit membuka dua sambungan, dan kedua-duanya gagal atas sebab berbeza. Yang pertama ialah pelayar ke pendengar proksi, dibawa melalui VPN cawangan. Yang kedua ialah proksi ke laman web, menggunakan penyelesai, laluan dan dasar keluar proksi itu sendiri. Tiket sokongan yang menganggapnya sebagai satu aliran menghantar orang ke peranti yang salah selama berjam-jam. Sediakan setiap satu secara sengaja dan uji mengikut urutan itu.
Langkah 1: tuliskan kedua-dua aliran
Destinasi segera pelayar ialah pendengar proksi, bukan setiap tapak yang akhirnya dilawati pengguna. Satu ayat itu menyelesaikan sebahagian besar kekeliruan dalam reka bentuk ini.
branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> websiteSumber berbeza, laluan berbeza, kebenaran berbeza. Simpan lakaran dalam rekod perubahan, kerana setiap semakan kemudian merujuk kepada salah satu daripada dua bahagiannya.
Langkah 2: beri pelayar laluan ke pendengar
Catat nama hos proksi, port pendengar, keperluan pengesahan dan sumber cawangan yang dibenarkan. Senarai itu ialah kriteria penerimaan untuk aliran pertama, dan ia harus merangkumi penyelesaian nama peribadi serta laluan terowong.
Gunakan peraturan rangkaian yang sempit untuk perkhidmatan yang dimaksudkan daripada menerbitkan proksi tanpa had ke internet. Proksi boleh kekal pada rangkaian dalaman apabila klien yang dimaksudkan mempunyai laluan yang disokong kepadanya.
Langkah 3: konfigurasikan pelayar, bukan hanya jadual laluan
Gunakan tetapan proksi pelayar, fail PAC atau mekanisme penemuan terurus organisasi. Menghantar paket laman web biasa ke alamat proksi dengan laluan tidak membuat pelayar bercakap protokol proksi; itu pemintasan telus dan tergolong dalam reka bentuk get laluan yang lain.
Catat aplikasi mana yang mematuhi tetapan itu. Klien mel, pengemas kini dan permainan selalunya tidak mematuhinya, dan mereka akan terus menggunakan laluan biasa.
Langkah 4: buktikan sambungan keluar proksi
Proksi memerlukan penyelesai sendiri dan laluan yang dibenarkan ke laman web, serta dasar tembok api atau terjemahan yang diperlukan sempadan internetnya. Pelayar yang sampai ke pendengar tidak membuktikan apa-apa daripada itu. Uji aliran kedua dari proksi itu sendiri, dengan destinasi dan port yang sama seperti yang dilaporkan pengguna.
Untuk HTTPS, CONNECT membuka terowong ke destinasi yang diminta. Pemajuan biasa tidak menyerahkan halaman yang dinyahsulit kepada proksi, dan melumpuhkan pengesahan sijil untuk mengimprovisasi pemeriksaan bukan penyelesaian.
Langkah 5: bezakan empat kegagalan
Cabaran pengesahan proksi ialah 407 daripada pendengar. CONNECT yang ditolak ialah keputusan dasar pada proksi, biasanya dengan status dan baris log sendiri. Sambungan keluar yang gagal kelihatan seperti tamat masa atau set semula yang direkodkan proksi terhadap destinasi. Respons laman web bermakna kedua-dua sambungan berfungsi dan masalahnya di asal.
Laporkan sempadan yang anda perhatikan, bukan ringkasan bahawa VPN gagal.
Langkah 6: tentukan skop dan rancang sandaran
Tentukan apa yang berlaku apabila proksi atau terowong tidak tersedia, dan nyatakan dengan jelas trafik mana yang diliputi reka bentuk ini. Ia membawa akses web daripada klien yang mematuhi tetapan proksi; ia tidak membawa mel, protokol peranti sewenang-wenangnya atau perisian yang mengabaikan konfigurasi.
Sahkan operasi pelayar yang diperlukan dan satu penolakan yang diperlukan di bawah pelan yang diluluskan sebelum melanjutkan reka bentuk kepada lebih banyak klien.