Mengapa 403 daripada laman VPN bukan kegagalan proksi

Pengguna memutuskan VPN, menerima 403 di laman dalaman dan melaporkan proksi rosak. Tiga perkara berasingan boleh menghasilkan halaman itu: asal menolak permintaan, proksi hadapan enggan membuka terowong, atau proksi menuntut kelayakan sendiri. Setiap satunya ialah jawapan betul kepada soalan berbeza, dan meratakannya menjadi satu halaman kegagalan generik memusnahkan satu-satunya bukti yang anda ada. Susun penolakan mengikut komponen yang menghasilkannya, kemudian bandingkan laluan rangkaian yang sebenarnya digunakan setiap komponen.

Namakan komponen yang menghasilkan 403

Kod status HTTP milik pihak yang menghantarnya. Apabila asal memulangkan 403, ia telah menghuraikan permintaan dan memutuskan pemanggil mungkin tidak mempunyai sumber itu, yang merupakan jawapan kebenaran dan bukan masalah pengangkutan. Apabila proksi hadapan menjawab 403 kepada CONNECT, ia enggan membina terowong itu langsung, dan tiada apa di huluan pernah dihubungi. Apabila ia menjawab 407, ia mahukan kelayakan sendiri, yang tidak ada kaitan dengan log masuk aplikasi.

RFC 9110 mentakrifkan peranan ini, termasuk cabaran khusus proksi. Baca status respons itu sendiri dan mana-mana pengepala Proxy-Authenticate sebelum membaca badan, kerana halaman ralat HTML yang mesra biasanya menyembunyikan komponen mana yang menulisnya.

Apa yang disembunyikan terowong CONNECT daripada penyampai bait

Setelah proksi memulangkan 200 kepada CONNECT, ia menyampaikan bait dan pelayar mengekalkan sesi TLS sendiri dengan asal. Oleh itu proksi yang menyampaikan bait tidak boleh membaca 403 yang disulitkan dalam sesi itu, dan ia tidak pernah menjadi pengarang penolakan. Penolakan sebelum terowong dibuka ialah peristiwa yang sama sekali berbeza, dihasilkan satu lapisan lebih rendah.

Proksi songsang yang menamatkan TLS berada dalam kedudukan berbeza: ia memiliki sempadan TLS, menghuraikan HTTP dan boleh menulis semula atau memintas respons secara sah. Keupayaan itu ialah pilihan konfigurasi, bukan sifat proksi secara umum, dan ia tidak memberi kuasa untuk memintas dasar akses aplikasi. Membaca respons ialah keupayaan; memutuskan apa yang boleh dilihat pemanggil kekal tugas asal.

Akibat praktikalnya ialah anda mesti tahu bentuk mana antara tiga yang anda jalankan sebelum mentafsir 403. Menambah peraturan pemeriksaan HTTP pada proksi aliran tidak memberinya keterlihatan, dan mengharapkan penyampai bait menjelaskan penolakan asal akan menghantar anda mencari dalam log yang salah.

Bandingkan laluan keluar proksi dengan alamat terowong pelayar

Pelayar yang disambungkan kepada VPN tidak memindahkan pelayan proksi berasingan ke terowong itu secara automatik. Asal melihat alamat keluar proksi, dan jika proksi masih keluar melalui laluan lalai tempatan, laman yang dilindungi melihat alamat yang tidak pernah dikonfigurasikan untuk dipercayai. Alamat VPN dalaman pada komputer riba tidak kelihatan kepada asal itu. Inilah sebab paling biasa terowong yang berfungsi masih memberikan 403 daripada laman yang berkelakuan betul kepada semua orang lain.

Uji kedua-dua laluan secara berasingan supaya alamat tidak boleh dikelirukan.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Permintaan pertama menunjukkan apa yang dijawab asal untuk alamat anda sendiri, yang kedua menunjukkan apa yang dijawabnya untuk alamat proksi. Pasangan 403 yang sepadan menunjuk kepada peraturan kebenaran asal; 200 yang diikuti 403 menunjuk kepada laluan proksi. Tanya pemilik asal alamat sumber mana yang benar-benar diterima oleh set peraturan itu, bukannya menganggap kumpulan VPN disertakan.

Uji setiap sempadan dengan permintaan yang mengasingkannya

Asingkan lapisan proksi dengan memintanya sesuatu yang tidak boleh ditolaknya atas sebab aplikasi. CONNECT ke hos yang dibenarkan dicapai oleh proksi, dengan output dibuang, memberitahu anda sama ada kemasukan terowong berfungsi langsung.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Jika itu mencetak 200 untuk CONNECT dan kemudian jabat tangan TLS, kemasukan proksi adalah baik dan 403 kemudian datang daripada asal. Jika ia mencetak 407, berikan kelayakan proksi dengan --proxy-user dan ulangi sebelum membuat apa-apa kesimpulan tentang laman itu. Jika ia mencetak 403 pada baris CONNECT, senarai benaran proksi itu sendiri ialah sempadan yang perlu diperiksa, dan aplikasi tidak terlibat.

Jauhkan kelayakan daripada sejarah shell dan daripada transkrip yang ditampal. Kata laluan proksi yang ditaip pada baris arahan kelihatan kepada pengguna tempatan lain, dan jejak CONNECT yang ditangkap dengan kelayakan lebih buruk daripada tiada jejak.

Kekalkan keputusan boleh dibaca daripada menulis semula halaman

Setelah anda tahu komponen mana yang menolak, peliharalah jawapan itu. Proksi songsang yang melabel semula 403 asal sebagai tamat masa 504, atau menggantikannya dengan halaman kejayaan, menyembunyikan keputusan kebenaran di sebalik kisah ketersediaan dan menghantar responden seterusnya ke pasukan yang salah. Halaman ralat tersuai adalah baik apabila ia mengekalkan status dan menambah konteks.

Cache patut mendapat penjagaan yang sama. RFC 9111 mengawal cara cache dikongsi boleh menggunakan semula respons, dan penolakan yang dihasilkan untuk seorang pemanggil tidak boleh diserahkan kepada yang lain seolah-olah ia kebenaran. Jika respons penolakan disimpan sama sekali, kekalkannya peribadi dan terhad, dan jangan sekali-kali menambah peraturan kesegaran awam hanya untuk mengurangkan trafik huluan.

Akhiri dengan keputusan bertulis yang menamakan komponen, status yang dihasilkannya dan alamat sumber yang dilihat asal. Rekodkan permintaan tepat, tetapan proksi yang berkuat kuasa dan masa, supaya laporan seterusnya boleh dipadankan dengan bukti yang sama daripada diterbitkan semula daripada ingatan. Rekod itu menjawab laporan seterusnya dalam beberapa saat dan menghalang 403 yang sama daripada didiagnosis semula sebagai gangguan VPN.