Bagaimana proksi publik mencapai origin privat melalui VPN

Menerbitkan situs web melalui terowongan dan memberi pengguna akses VPN adalah dua pengaturan berbeda yang berbagi satu kabel. Pada yang pertama, proksi terbalik publik menerima permintaan pengunjung dan meneruskannya melalui terowongan ke origin yang tidak dapat dijangkau siapa pun secara langsung. Pada yang kedua, pengguna harus bergabung dengan VPN sebelum aplikasi dapat dijangkau sama sekali. Mencampur kedua deskripsi itulah cara sebuah backend privat akhirnya terekspos secara publik.

Dua model yang terlihat sama pada diagram

Gambar panahnya sebelum memilih apa pun. Model penerbitan publik berjalan dari peramban ke proksi melalui HTTPS, lalu dari proksi ke origin melalui terowongan, dan origin tidak pernah menerima koneksi dari internet. Model hanya-VPN berjalan dari klien ke gerbang, dan aplikasi hanya dapat dijangkau dari dalam jalur itu. Laptop pengguna berada di jaringan yang sama dengan aplikasi, dan itulah inti dari model tersebut.

Model-model itu berbeda dalam siapa yang mengautentikasi dan di mana. Pada yang pertama, proksi adalah pintu masuk publik dan meneruskan permintaan apa pun yang datang, termasuk yang bermusuhan, tunduk pada kebijakan yang dikonfigurasi padanya. Pada yang kedua, keterjangkauan itu sendiri adalah gerbang, yang merupakan penerimaan kasar tetapi nyata.

Di mana TLS berhenti, dan apa yang sebenarnya dibuktikannya

TLS antara peramban dan proksi melindungi lompatan itu dan memungkinkan peramban memverifikasi situs yang ingin dikunjunginya. Jika proksi mengakhiri TLS, permintaan itu ada dalam bentuk yang dapat dibaca di dalam proses tersebut sebelum diteruskan. Sesi TLS kedua ke origin dapat melindungi lompatan berikutnya dan memverifikasi titik akhir aplikasi secara terpisah. Tidak ada sesi yang memutuskan manusia mana yang boleh menggunakan aplikasi. Sertifikat wildcard pada proksi juga tidak mencakup lompatan kedua itu.

Inilah bagian yang orang-orang rangkum menjadi kata terenkripsi. Kerahasiaan, integritas, dan identitas server adalah sifat transportasi; otorisasi adalah keputusan aplikasi. Alamat privat di balik terowongan mengubah siapa yang dapat mencapai soket, bukan siapa yang boleh masuk setelah mencapainya.

Percayai header yang diteruskan hanya dari proksi

Aplikasi yang mencatat atau mengotorisasi berdasarkan alamat klien biasanya membaca header yang ditambahkan proksi. Header itu hanya teks, jadi apa pun yang dapat mencapai origin secara langsung dapat mengklaim alamat apa pun yang diinginkannya. Batasi origin sehingga hanya alamat terowongan proksi yang dapat terhubung, dan konfigurasikan aplikasi untuk menerima header hanya dari alamat itu.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Jika permintaan itu berhasil dari host yang bukan proksi, origin memercayai header yang seharusnya diabaikannya. Perbaiki listener sebelum menyentuh aplikasi. Penolakan adalah hasil yang jauh lebih baik daripada baris log yang membawa alamat palsu.

Jaga origin tetap dapat dijangkau dari tepat satu tempat

Ikat listener origin ke alamat terowongan atau pagari dengan firewall ke arah proksi, lalu konfirmasi apa yang sebenarnya mendengarkan. Layanan yang dimulai dengan pengikatan wildcard menerima koneksi pada setiap antarmuka yang dimiliki host, termasuk yang Anda lupa dapat dirutekan. Tabel pendengaran adalah kebenaran dasar, bukan berkas konfigurasi yang ingin Anda terapkan. Jika pengikatan wildcard memang disengaja, firewall tetap harus menjadi komponen yang mempersempitnya.

ss -ltnp | grep -E ':(80|443)'

Lakukan tinjauan yang sama untuk antarmuka manajemen, yang merupakan paparan tak sengaja yang biasa. Lalu tuliskan kedua model secara terpisah: situs publik melalui proksi, dan antarmuka administrasi yang hanya dapat dijangkau melalui terowongan. Kalimat bahwa server berada di balik VPN tidak mengatakan satu pun dari itu.