Mengapa 403 dari situs VPN bukan kegagalan proxy

Pengguna memutus VPN, menerima 403 di situs internal, dan melaporkan bahwa proxy rusak. Tiga hal terpisah dapat menghasilkan halaman itu: origin menolak permintaan, proxy maju menolak membuka terowongan, atau proxy menuntut kredensialnya sendiri. Masing-masing adalah jawaban benar atas pertanyaan berbeda, dan meratakannya menjadi satu halaman kegagalan generik menghancurkan satu-satunya bukti yang Anda miliki. Urutkan penolakan menurut komponen yang menghasilkannya, lalu bandingkan jalur jaringan yang benar-benar digunakan setiap komponen.

Sebutkan komponen yang menghasilkan 403

Kode status HTTP milik pihak yang mengirimnya. Saat origin mengembalikan 403, ia telah mengurai permintaan dan memutuskan bahwa pemanggil mungkin tidak memiliki sumber daya, yang merupakan jawaban otorisasi dan bukan masalah transportasi. Saat proxy maju menjawab 403 atas CONNECT, ia menolak membangun terowongan sama sekali, dan tidak ada yang di hulu pernah dihubungi. Saat ia menjawab 407, ia menginginkan kredensialnya sendiri, yang tidak ada hubungannya dengan login aplikasi.

RFC 9110 mendefinisikan peran ini, termasuk tantangan khusus proxy. Baca status respons itu sendiri dan header Proxy-Authenticate apa pun sebelum membaca isi, karena halaman kesalahan HTML yang ramah biasanya menyembunyikan komponen mana yang menulisnya.

Apa yang disembunyikan terowongan CONNECT dari relai byte

Setelah proxy mengembalikan 200 atas CONNECT, ia meneruskan byte dan browser mempertahankan sesi TLS-nya sendiri dengan origin. Proxy yang meneruskan byte karena itu tidak dapat membaca 403 terenkripsi di dalam sesi itu, dan ia tidak pernah menjadi penulis penolakan. Penolakan sebelum terowongan dibuka adalah peristiwa yang sama sekali berbeda, dihasilkan satu lapis lebih rendah.

Proxy balik yang mengakhiri TLS berada di posisi berbeda: ia memiliki batas TLS, mengurai HTTP, dan dapat menulis ulang atau mencegat respons secara sah. Kemampuan itu adalah pilihan konfigurasi, bukan sifat proxy secara umum, dan tidak memberi wewenang untuk melewati kebijakan akses aplikasi. Membaca respons adalah kemampuan; memutuskan apa yang boleh dilihat pemanggil tetap menjadi tugas origin.

Konsekuensi praktisnya adalah Anda harus tahu bentuk mana dari ketiganya yang Anda jalankan sebelum menafsirkan 403. Menambahkan aturan inspeksi HTTP ke proxy aliran tidak memberinya visibilitas, dan mengharapkan relai byte menjelaskan penolakan origin akan membuat Anda mencari di log yang salah.

Bandingkan jalur keluar proxy dengan alamat terowongan browser

Browser yang terhubung ke VPN tidak otomatis memindahkan server proxy terpisah ke terowongan itu. Origin melihat alamat keluar proxy, dan jika proxy masih keluar melalui rute default lokal, situs yang dilindungi melihat alamat yang tidak pernah dikonfigurasi untuk dipercaya. Alamat VPN internal di laptop tidak terlihat oleh origin itu. Inilah alasan paling umum mengapa terowongan yang berfungsi masih menghasilkan 403 dari situs yang berperilaku benar bagi semua orang lain.

Uji kedua jalur secara terpisah agar alamatnya tidak tertukar.

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 origin untuk alamat Anda sendiri, yang kedua menunjukkan apa yang dijawabnya untuk alamat proxy. Sepasang 403 yang cocok menunjuk pada aturan otorisasi origin; 200 yang diikuti 403 menunjuk pada jalur proxy. Tanyakan kepada pemilik origin alamat sumber mana yang benar-benar diterima kumpulan aturan, alih-alih menganggap kumpulan VPN disertakan.

Uji setiap batas dengan permintaan yang mengisolasinya

Isolasi lapisan proxy dengan memintanya sesuatu yang tidak dapat ditolaknya karena alasan aplikasi. CONNECT ke host yang boleh dijangkau proxy, dengan keluaran dibuang, memberi tahu Anda apakah penerimaan terowongan berfungsi sama sekali.

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 lalu jabat tangan TLS, penerimaan proxy baik-baik saja dan 403 berikutnya berasal dari origin. Jika mencetak 407, berikan kredensial proxy dengan --proxy-user dan ulangi sebelum menarik kesimpulan apa pun tentang situs. Jika mencetak 403 pada baris CONNECT, daftar izin proxy sendiri adalah batas yang harus diperiksa, dan aplikasi tidak terlibat.

Jauhkan kredensial dari riwayat shell dan dari transkrip yang ditempel. Kata sandi proxy yang diketik di baris perintah terlihat oleh pengguna lokal lain, dan jejak CONNECT yang tertangkap dengan kredensial lebih buruk daripada tidak ada jejak.

Jaga putusan tetap terbaca alih-alih menulis ulang halaman

Setelah Anda tahu komponen mana yang menolak, pertahankan jawaban itu. Proxy balik yang melabeli ulang 403 origin sebagai timeout 504, atau menggantinya dengan halaman sukses, menyembunyikan keputusan otorisasi di balik cerita ketersediaan dan mengirim responden berikutnya ke tim yang salah. Halaman kesalahan khusus baik-baik saja bila mempertahankan status dan menambahkan konteks.

Cache layak mendapat perawatan yang sama. RFC 9111 mengatur bagaimana cache bersama boleh menggunakan ulang respons, dan penolakan yang dihasilkan untuk satu pemanggil tidak boleh diberikan kepada yang lain seolah-olah itu izin. Jika respons penolakan disimpan sama sekali, jaga tetap privat dan terbatas, dan jangan pernah menambahkan aturan kesegaran publik hanya untuk mengurangi lalu lintas hulu.

Akhiri dengan putusan tertulis yang menyebut komponen, status yang dihasilkannya, dan alamat sumber yang dilihat origin. Catat permintaan persisnya, pengaturan proxy yang berlaku, dan waktunya, agar laporan berikutnya dapat dicocokkan dengan bukti yang sama alih-alih diturunkan ulang dari ingatan. Catatan itu menjawab laporan berikutnya dalam hitungan detik dan menghentikan 403 yang sama didiagnosis ulang sebagai gangguan VPN.