HAProxy 302 ke aplikasi peribadi: siapa membuka lompatan kedua?

Seseorang menghalakan hos HAProxy awam ke aplikasi dalaman dan bertanya mengapa pelayar tidak dapat mengikuti. Proksi mencapai aplikasi melalui VPN-nya, ubah hala mengembalikan pengepala Location, dan pelayar kemudian mencuba alamat yang hanya wujud di dalam terowong. Dari luar halaman hanya tergantung. Keputusannya ialah pihak mana yang membuka sambungan kedua, dan itulah yang membezakan ubah hala daripada backend.

Dua laluan yang kelihatan serupa dalam konfigurasi

Ubah hala menamatkan pertukaran dengan respons. Klien membaca Location dan memulakan permintaan baharu dari mana pun klien berada, iaitu rangkaian yang tidak pernah anda kawal. Proksi tidak lagi terlibat. Semua yang berikutnya bergantung pada DNS, laluan dan kepercayaan klien itu sendiri, jadi hasilnya berbeza mengikut tempat pengguna membuka pelayar:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Backend proksi menyimpan peringkat kedua di sebelah pelayan. Proksi membukanya melalui laluan yang sudah dimilikinya, dan klien terus bercakap dengan satu nama awam. Jika terowong jatuh, klien menerima ralat dan bukannya URL yang tidak dapat diikutinya. Perbezaan itulah yang menjadikan kegagalan boleh didiagnosis, kerana ralat muncul di tempat log berada:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

Dokumentasi ubah hala HAProxy menarik garis yang tepat itu: menjawab klien dengan ubah hala ialah tindakan berbeza daripada menghantar permintaan ke backend. Kedua-dua arahan berada beberapa baris antara satu sama lain dalam fail konfigurasi dan berkelakuan sama sekali berbeza. Satu menamatkan permintaan, yang lain memulakan permintaan kedua yang dimiliki proksi.

Apa yang pelayar perlukan dan apa yang VPN pelayan tidak berikannya

Permintaan pelayar itu sendiri memerlukan empat perkara yang mungkin tidak dimilikinya: jawapan DNS untuk nama peribadi, laluan ke alamat itu, kebenaran untuk mencapai perkhidmatan yang mendengar, dan kepercayaan pada sijil yang dikemukakan oleh perkhidmatan itu. Hos proksi memiliki kesemua empat melalui terowongnya. Tiada satu pun berpindah kepada klien yang tidak pernah berada dalam terowong itu, kerana terowong ialah sifat hos, bukan sifat URL.

Jurang itulah yang menjelaskan gejala hampir-berfungsi. Permintaan pertama berjaya, bar alamat berubah, dan kemudian sambungan tergantung atau gagal sedangkan proksi sihat sepanjang masa. Tiada apa yang rosak dalam konfigurasi proksi, dan melarasnya tidak membantu klien yang tiada laluan ke 10.40.0.20. Sama ada klien mendapat laluan, atau proksi mesti membuat sambungan bagi pihaknya.

Apabila hanya proksi dapat mencapai aplikasi

Buang tindakan ubah hala dan hantar permintaan itu ke backend yang menunjuk ke alamat peribadi. Frontend mengekalkan nama awamnya sementara backend menentukan ke mana permintaan sebenarnya pergi. Tiada apa yang berubah pada laluan klien, kerana proksi berhenti menerangkan destinasi dan mula menjadi destinasi. Bagi aplikasi yang sengaja mendengar pada port dalaman 8080, blok pelayan itu pendek:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Baca blok itu sebagai pernyataan tentang jadual penghalaan proksi: 10.40.0.20 mesti boleh dicapai dari hos proksi itu sendiri, yang di sini bermaksud melalui antara muka VPN dan bukan melalui laluan lalai. Kata kunci check hanya melaporkan apa yang dilakukan oleh laluan itu, dan laluan kesihatan mesti wujud pada aplikasi atau setiap pemeriksaan menandakan pelayan sebagai mati. Pemeriksaan yang lulus tidak membuktikan apa-apa tentang klien dan tidak menggantikan dasar yang menentukan siapa boleh menggunakan backend.

Serpihan itu bukan frontend lengkap. Kekalkan pendengar, pengesahan, pemilihan hos dan laluan yang dibenarkan, serta peraturan yang menentukan siapa boleh mencapai aplikasi. Padankan juga protokol backend, kerana backend HTTPS memerlukan pengesahan sijil dan konfigurasi identiti pelayan, dan melangkau pemeriksaan itu menjadikan sambungan peribadi sebagai tidak disahkan.

Sahkan laluan balik dalam kedua-dua arah sebelum mengisytiharkan kemenangan. Aplikasi kini melihat sambungan daripada proksi, jadi lognya dan mana-mana metadata alamat klien menerangkan proksi melainkan anda mengaturnya sebaliknya. Tentukan bagaimana identiti dan alamat yang dihantar dikendalikan, dan uji keputusan itu dan bukannya menganggapnya.

Ubah hala aplikasi itu sendiri masih menunjuk ke dalam

Menghantar permintaan pertama hanyalah separuh daripada integrasi. Aplikasi mungkin mengeluarkan ubah hala mutlak, URL aset yang dikodkan keras, atau kuki yang terhad kepada nama yang dikenalnya secara dalaman, dan setiap satunya menghantar pelayar kembali ke alamat yang tidak dapat dicapainya. Pengepala Location yang menunjuk ke nama dalaman kelihatan sama seperti masalah asal, sebab itulah ia salah didiagnosis sebagai kegagalan proksi.

Tetapkan URL luaran terdokumentasi aplikasi dan pilihan proksinya, kemudian selaraskan pengepala Host dengan hos maya dan jangkaan sijil. Kuki yang terhad kepada nama dalaman tidak akan kembali melalui nama awam, dan gelung log masuk yang menyusul dibaca sebagai pepijat pengesahan. Tukar URL luaran dahulu, uji semula dari profil pelayar yang bersih, dan jangkakan tetapan yang baru separuh berpindah menghasilkan log masuk yang berjaya dan sesi yang mati serta-merta.

Percayai metadata yang dihantar hanya daripada proksi yang ditetapkan. Pengepala yang boleh ditetapkan oleh mana-mana klien tidak boleh menjadi nilai kebenaran, jika tidak proksi menjadi cara pemanggil menuntut identiti orang lain. Peraturan itu bebas daripada persoalan ubah hala dan bertahan dalam mana-mana reka bentuk semula kemudian.

Tentukan reka bentuk mana yang sebenarnya anda miliki

Jika setiap pengguna sudah mempunyai akses VPN yang dibenarkan, ubah hala ke URL peribadi boleh menjadi reka bentuk yang disengajakan. Sahkan keperluan itu secara eksplisit dan bukannya menganggapnya, kerana kedua-dua reka bentuk melayani populasi yang sama sekali berbeza. Salah satunya tidak berfungsi sama sekali dari rangkaian hotel, dan yang lain mendedahkan aplikasi kepada sesiapa yang boleh memuatkan URL awam. Perbezaan itu tergolong dalam nota reka bentuk.

Jalankan pemeriksaan dari mesin di rangkaian pengguna dan ikuti setiap lompatan yang dibuat oleh pelayar, bukan hanya respons pertama. Perhatikan bar alamat dan setiap permintaan berikutnya, kerana satu URL mutlak dalam tag aset sudah cukup untuk memecahkan aliran yang dilalui lompatan pertama. Log masuk mesti berfungsi melalui nama awam, dan sumber yang patut ditolak mesti kekal ditolak.

Menerbitkan proksi songsang ialah keputusan akses yang berasingan, bukan lanjutan telus VPN proksi itu sendiri kepada sesiapa yang boleh memuatkan URL awamnya. Kedua-duanya kelihatan serupa pada gambar rajah, dan berbeza pada siapa yang dibenarkan masuk. Memutuskan persoalan itu selepas penggunaan adalah cara aplikasi dalaman menjadi awam secara tidak sengaja.

Tuliskan yang mana antara keduanya yang anda bina dan mengapa. Orang seterusnya yang menyentuh konfigurasi akan menganggap yang satu lagi. Satu ubah hala yang ditambah atas sebab kemudahan sudah cukup untuk mencipta semula kegagalan asal, dan gejalanya akan kelihatan tepat seperti yang baru anda betulkan.