Proksi setiap profil pelayar: DNS, pengesahan dan kegagalan

Panduan ini menggunakan tingkah laku rangkaian Chromium yang didokumenkan sebagai rujukan. Pelayar dan produk lain mungkin membuat pilihan berbeza, dan pengurus pelayar boleh menambah perantara rangkaian setempat di sekeliling Chromium. Sahkan tingkah laku binaan tepat yang anda gunakan.

Mulakan dengan empat soalan berasingan

Rekod proksi biasanya mengandungi skim, titik akhir, port dan kadangkala rujukan pengesahan. Rekod itu masih meninggalkan empat soalan dasar berasingan:

1. Liputan: permintaan dan protokol pelayar mana diarahkan kepada proksi ini?
2. Penyelesaian nama: adakah peranti atau proksi menyelesaikan nama hos destinasi?
3. Pengesahan: skim klien dan proksi mana serasi, dan di mana bukti kelayakan disimpan?
4. Kegagalan: adakah ralat sambungan menghentikan permintaan, mencuba proksi lain atau beralih ke laluan terus?

Menganggap semuanya sebagai satu suis ‘proksi hidup’ menyebabkan banyak kejutan. Chromium mendokumenkan pemilihan proksi sebagai penentuan pada peringkat URL: URL menghasilkan senarai pilihan proksi tersusun sebelum nama destinasi semestinya diselesaikan. Peraturan pengecualian dan laluan gantian sebahagian daripada keputusan itu.

Liputan proksi setiap profil

Dasar ProxySettings Google diterapkan pada peringkat profil Chrome. Ia boleh memilih mod terus, sistem, pengesanan automatik, pelayan tetap atau skrip PAC, dengan medan pengecualian dan kewajipan PAC yang jelas.

Sempadan itu lebih sempit daripada VPN atau ruang nama rangkaian sistem pengendalian. Ia mengawal permintaan yang dikendalikan konteks rangkaian pelayar, tetapi tidak secara automatik mengawal:

• panggilan API pengurus desktop sendiri;
• pengemas kini aplikasi atau pelayar yang berjalan di luar proses itu;
• DNS dan pemeriksaan sambungan sistem pengendalian;
• aplikasi lain yang dilancarkan daripada fail muat turun;
• pembantu natif berasingan milik sambungan;
• perkhidmatan setempat yang dicapai melalui pengecualian gelung balik tersirat; atau
• trafik menggunakan protokol yang tidak dapat dibawa laluan proksi dipilih.

Sesetengah komponen itu mungkin mempunyai sokongan proksi sendiri. Sokongan tersebut mesti dinyatakan dan diuji secara berasingan. Kenyataan produk seperti ‘trafik profil menggunakan proksi ini’ perlu mengenal pasti proses dan protokol yang diliputi, bukannya membayangkan penghalaan seluruh peranti.

Ikuti satu permintaan HTTPS

Bagi navigasi HTTPS biasa, laluan mempunyai beberapa langkah.

1. Pilih laluan

Pelayar menilai peraturan tetap, skrip konfigurasi proksi automatik atau tetapan sistem. Padanan pengecualian boleh memilih sambungan terus. Senarai proksi boleh memilih proksi utama diikuti alternatif, termasuk DIRECT jika laluan terus gantian dibenarkan.

Chromium juga menerapkan pengecualian tersirat bagi localhost dan destinasi pautan setempat. Ini melindungi origin setempat daripada tetapan proksi yang dikawal pihak luar, tetapi bermakna dakwaan luas ‘semua trafik’ perlu diperincikan.

2. Selesaikan nama dan capai proksi

Jika titik akhir proksi ialah nama hos, peranti masih memerlukan cara menyelesaikan nama dan menyambung kepadanya. DNS destinasi di pihak proksi tidak menghapuskan carian permulaan ini. Kegagalan pada tahap ini berbeza daripada keadaan proksi boleh dicapai tetapi tidak dapat menyelesaikan nama destinasi.

3. Sahkan diri kepada proksi

Proksi HTTP yang memerlukan bukti kelayakan biasanya memulangkan 407 Proxy Authentication Required bersama cabaran. RFC 9110 mentakrifkan pertukaran itu serta medan Proxy-Authenticate dan Proxy-Authorization.

Chromium tidak menggunakan nama pengguna dan kata laluan yang dimasukkan dalam tetapan proksi manual. Dokumentasi proksinya menyatakan bahawa pengesahan mengikut aliran bukti kelayakan biasa pelayar. Oleh itu, pengurus profil memerlukan integrasi jelas untuk cabaran yang disokong, bukan janji bahawa semua rentetan user:password@host akan berfungsi.

4. Wujudkan sambungan destinasi

Dengan proksi HTTP, Chromium menyerahkan penyelesaian nama destinasi kepada proksi. Untuk destinasi HTTPS, pelayar meminta proksi mencipta terowong CONNECT, kemudian menjalankan TLS hujung ke hujung dengan destinasi melalui terowong itu.

Proksi masih mengetahui nama hos destinasi dan metadata sambungan. Apabila hubungan klien ke proksi menggunakan HTTP biasa, permintaan CONNECT dan nama hosnya tidak dilindungi pada hubungan itu. Proksi HTTPS menambah TLS antara pelayar dan proksi, melindungi metadata tersebut daripada pemerhati di antaranya. Ia tidak menghalang proksi sendiri daripada melihat destinasi diminta.

Proksi biasanya tidak dapat membaca kandungan halaman HTTPS yang dibawa dalam terowong. Pemintasan TLS ialah model kepercayaan berbeza: klien mempercayai pihak berkuasa sijil yang membolehkan perantara menamatkan dan mewujudkan semula TLS. Ini tidak boleh disamakan secara senyap dengan pemajuan biasa.

Pihak yang menyelesaikan DNS berubah mengikut skim proksi

Tingkah laku Chromium yang didokumenkan berbeza mengikut jenis proksi:

Laluan dipilih	Penyelesaian nama destinasi dalam Chromium	Batas penting
Terus atau pengecualian	Penyelesai peranti atau pelayar	Trafik destinasi keluar tanpa proksi profil
Proksi HTTP	Pihak proksi	Pengangkutan HTTP biasa dari klien ke proksi mendedahkan permintaan HTTP; HTTPS menggunakan CONNECT
Proksi HTTPS	Pihak proksi	Klien mesti mengesahkan sijil TLS proksi
Proksi SOCKS4	Pihak klien	Destinasi IPv4 sahaja; Chromium tidak melaksanakan laluan gantian SOCKS4a
Proksi SOCKS5	Pihak proksi	Chromium menggunakannya untuk permintaan URL TCP dan mendokumenkan tiada sokongan pengesahan SOCKS5

RFC 1928 membenarkan permintaan SOCKS5 membawa nama domain dan mentakrifkan beberapa pengecam kaedah pengesahan. Keupayaan protokol tidak menjamin pelaksanaan klien. Chromium kini menghantar nama destinasi kepada proksi SOCKS5 tetapi menyatakan bahawa klien SOCKS5 terbina dalamnya tidak menyokong kaedah pengesahan proksi. Oleh itu, penyedia akses SOCKS5 bernama pengguna dan kata laluan mungkin memerlukan perantara disokong atau skim proksi lain. Sahkan pelaksanaan pelayar sebelum menerima rekod tersebut.

DNS melalui HTTPS menambah satu lagi lapisan. Dasar DnsOverHttpsMode Chrome membezakan automatic, yang boleh beralih kepada DNS tidak selamat, daripada secure, yang menggagalkan penyelesaian nama apabila DNS selamat gagal. Dasar itu didokumenkan pada peringkat pelayar, sedangkan ProxySettings pada peringkat profil. Perbezaan ini peringatan berguna: perkataan ‘profil’ pada satu tetapan tidak bermaksud semua kawalan DNS mempunyai skop sama.

Produk yang menjalankan setiap profil dalam proses pelayar berasingan boleh mewujudkan sempadan berkesan yang lebih sempit, tetapi itu pilihan pelaksanaan. Ujilah. Bukti perlu membezakan:

• penyelesaian nama titik akhir proksi;
• penyelesaian nama destinasi diminta;
• DNS bagi permintaan terus atau yang dikecualikan;
• permulaan dan laluan gantian DNS selamat; dan
• DNS yang dilakukan komponen di luar konteks rangkaian pelayar profil.

Pengesahan melibatkan keserasian dan pengendalian rahsia

Chromium mendokumenkan Basic, Digest, Negotiate dan NTLM bagi proksi HTTP. Proksi HTTPS menambah saluran terlindung klien ke proksi dan juga boleh menyokong sijil klien. Pengesahan SOCKS4 dan SOCKS5 tidak dilaksanakan oleh klien proksi terbina dalam Chromium, walaupun kaedah pengesahan wujud dalam spesifikasi SOCKS5.

Skim yang serasi juga boleh mendedahkan data jika saluran komunikasi tidak dilindungi dengan sewajarnya. RFC 7617 menerangkan bahawa bukti kelayakan Basic hanya dikodkan Base64 dan memerlukan saluran terlindung seperti TLS. Pengesahan Basic kepada proksi HTTP biasa mendedahkan kata laluan proksi kepada sesiapa yang dapat memerhatikan hubungan itu.

Pengurus profil sepatutnya mengasingkan data berikut:

• metadata titik akhir bukan rahsia, seperti skim, hos, port dan label penyedia;
• rujukan rahsia yang digunakan perkhidmatan kitar hayat atau rangkaian;
• nilai bukti kelayakan dalam storan terlindung;
• keadaan sambungan dengan maklumat sensitif disembunyikan untuk antara muka dan jejak audit; dan
• butiran diagnostik yang tersedia hanya melalui aliran sokongan terkawal.

Paparan biasa, log, API, eksport dan output automasi tidak memerlukan kata laluan proksi. Pengendali biasanya perlu mengetahui bahawa pengesahan gagal, skim yang dicabar, titik akhir terlibat dan sama ada laluan gantian digunakan.

Mod kegagalan dan simptomnya

Kegagalan	Simptom berkemungkinan	Sempadan yang perlu disahkan
Skim proksi salah	Rundingan TLS atau protokol gagal	Adakah titik akhir HTTPS diisytiharkan sebagai HTTP, atau sebaliknya?
Nama hos proksi tidak dapat diselesaikan	Sambungan gagal sebelum proksi dicapai	Penyelesai mana melakukan carian permulaan?
Port proksi tidak dapat dicapai	Masa tamat atau sambungan ditolak	Adakah proksi lain atau DIRECT berada seterusnya dalam senarai?
Cabaran pengesahan tidak disokong	407 atau gesaan log masuk berulang	Adakah pelayar melaksanakan skim yang dicabar?
Bukti kelayakan salah atau luput	407 selepas bukti kelayakan dihantar	Adakah rujukan rahsia berjaya diperoleh dan nilainya disembunyikan daripada output?
Sijil proksi HTTPS gagal	Sambungan selamat kepada proksi ditolak	Adakah pengesahan sijil kekal utuh?
Proksi tidak dapat menyelesaikan nama destinasi	Kegagalan hos atau terowong khusus proksi	Adakah klien mengelakkan cubaan terus ke destinasi?
CONNECT ditolak	Navigasi HTTPS gagal untuk destinasi itu	Adakah penolakan dianggap dasar, bukannya kebenaran untuk memintas?
Fail PAC tidak tersedia	Pemilihan proksi tersekat atau laluan berubah	Adakah PAC wajib, atau bolehkah Chromium menggunakan DIRECT secara senyap?
Corak pengecualian terlalu luas	Laman tertentu menyambung terus	Adakah peraturan hos tepat, subdomain, port dan tersirat difahami?
WebRTC menggunakan antara muka lain	Laluan media berbeza daripada trafik halaman	Adakah UDP tanpa proksi dinyahdayakan bagi profil?
Sambungan sedia ada kekal selepas perubahan	Laluan lama masih aktif sementara	Adakah sambungan dikosongkan atau profil dimulakan semula?
Tangkapan diagnostik terlalu terperinci	URL, nama hos atau rahsia masuk ke fail sokongan	Mod penyembunyian data dan peraturan simpanan mana terpakai?

Laluan gantian Chromium mengekalkan keadaan. Proksi dengan kegagalan sambungan boleh ditandakan bermasalah dan diletakkan selepas entri lain untuk suatu tempoh. Jika DIRECT ada dalam senarai, permintaan kemudian boleh keluar tanpa proksi. Penolakan CONNECT dikendalikan berbeza kerana ia mungkin dasar destinasi yang disengajakan, bukan proksi tidak tersedia.

Kegagalan PAC memerlukan perhatian khusus. Chromium mendokumenkan bahawa fail PAC tidak tersedia boleh menyebabkan peralihan senyap kepada laluan terus kecuali PAC ditandakan wajib. Dasar ProxySettings Chrome menyediakan ProxyPacMandatory khusus untuk menghalang peralihan terus itu.

WebRTC dan UDP memerlukan keputusan sendiri

Halaman boleh menggunakan laluan WebRTC yang tidak setara dengan permintaan URL HTTP dan HTTPS biasa. Dasar WebRtcIPHandling lalai Chrome boleh menggunakan semua antara muka tersedia. Mod disable_non_proxied_udp mengehadkan WebRTC kepada TCP pada antara muka awam kecuali proksi yang dikonfigurasi menyokong UDP.

Dasar itu didokumenkan pada peringkat profil, jadi ia relevan kepada proksi profil, tetapi kekal kawalan berasingan. Ia mungkin mengurangkan prestasi media atau menggagalkan aliran kerja yang memerlukan UDP terus. Pilih dan uji pertukaran ini secara jelas. Jangan dakwa semua trafik terkandung dalam proksi berdasarkan pemeriksaan muat halaman yang berjaya sahaja.

Tentukan sama ada kegagalan menyekat akses atau mengutamakan ketersediaan

Laluan terus gantian boleh munasabah bagi profil pelayaran umum yang mengutamakan ketersediaan. Ia tidak selamat bagi aliran kerja yang kebenaran, privasi atau kesahihan ujian serantaunya bergantung pada laluan keluar tertentu.

Dasar profil yang baik menamakan tingkah laku dimaksudkan:

• Proksi wajib: hentikan permintaan rangkaian terjejas apabila laluan dipilih tidak dapat digunakan.
• Set proksi diluluskan: cuba hanya alternatif bernama dengan dasar setara.
• Laluan terus gantian dibenarkan: tunjukkan perubahan laluan dan rekodkan peristiwa tanpa nilai rahsia.
• Pengecualian jelas: dokumentasikan kategori destinasi dan sebab akses terus diperlukan.

Antara muka perlu menunjukkan keadaan laluan sebelum pelancaran dan selepas kegagalan. Peralihan senyap daripada proksi kepada sambungan terus menukar ralat rangkaian menjadi ralat integriti: aliran kerja mungkin kelihatan berjaya sedangkan laluan yang salah digunakan.

Matriks pengesahan selamat

Uji dengan titik akhir dan zon DNS yang anda miliki atau dibenarkan memeriksa. Rekodkan hasil dijangka sebelum ujian.

1. Pastikan skim proksi yang dinyatakan sepadan dengan protokol sambungan sebenar pada titik akhir.
2. Sahkan HTTP, HTTPS, WebSocket dan tingkah laku WebRTC yang diperlukan berjaya.
3. Perhatikan alamat keluar pada destinasi terkawal.
4. Perhatikan penyelesai yang menerima carian destinasi dan yang menyelesaikan nama hos proksi pada permulaan.
5. Luputkan bukti kelayakan ujian dan sahkan tiada nilai mentah muncul dalam antara muka, log atau output automasi.
6. Jadikan proksi ujian tidak dapat dicapai dan sahkan hasil sekatan selamat atau laluan gantian yang dikonfigurasi.
7. Tolak satu destinasi CONNECT terkawal dan sahkan penolakan dasar tidak menjadi akses terus.
8. Jadikan PAC ujian tidak tersedia dan sahkan tingkah laku wajib.
9. Uji kes pengecualian hos tepat, subdomain, setempat, pautan setempat, IPv4 dan IPv6 yang diperlukan aliran kerja.
10. Tukar proksi semasa sambungan aktif dan sahkan bila laluan baharu berkuat kuasa.
11. Tangkap hanya butiran diagnostik yang diperlukan ujian, kemudian sahkan penyimpanan dan pemadaman.

Panduan NetLog Chromium menganggap pengelogan rangkaian sebagai isu privasi dan keselamatan. Mod yang menyembunyikan data boleh mengecualikan medan sensitif, manakala mod lebih terperinci mungkin mengandungi kuki atau pengepala pengesahan. Fail sokongan perlu dikendalikan mengikut mod tangkapan sebenar, bukan berdasarkan nama fail.