Mengapa Port-Share membuat semua pengunjung situs terlihat seperti localhost

Setiap baris dalam log akses menunjukkan alamat loopback yang sama, sementara halamannya sendiri termuat dan sertifikatnya terverifikasi dengan benar. Tidak ada yang rusak dalam arti tidak dapat dijangkau, dan itulah sebabnya kasus ini bertahan berbulan-bulan. Yang rusak adalah atribusi: backend web mencatat alamat lompatan yang meneruskan koneksi, dan setiap keputusan berikutnya yang mempercayai log mewarisi jawaban salah yang sama.

Pemeriksaan di bawah berjalan dari kabel ke dalam. Berhentilah pada pemeriksaan pertama yang menjelaskan nilai yang Anda lihat, karena setiap langkah berikutnya mengasumsikan langkah sebelumnya sudah benar. Tidak satu pun memerlukan menebak konfigurasi front-end.

Ikuti dua koneksi, bukan baris log

Port-Share memultipleks dua protokol pada satu pendengar TCP. OpenVPN memeriksa byte pertama koneksi masuk, menyimpannya ketika tampak seperti protokolnya sendiri, dan menyerahkan apa pun yang lain ke tujuan kedua. Tujuan itu biasanya server web pada host yang sama, sehingga soket yang diterima server web memiliki proses OpenVPN sebagai rekannya.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Perintah pertama menunjukkan siapa pemilik pendengar publik. Perintah kedua menunjukkan koneksi yang tiba di port backend, dan alamat rekan mereka adalah yang akan dicetak log akses. Jika rekan itu adalah loopback, log-nya akurat dan informasinya hilang satu lapisan lebih awal. Mengganti nama bidang log atau mengaktifkan modul IP klien tidak akan memulihkan alamat yang tidak pernah dibawa koneksi.

Inilah pemeriksaan yang menentukan semua hal lain. Jika rekan backend adalah alamat peramban, berbagi port bukan masalah Anda dan format log-lah masalahnya.

Penerusan transport bukan injeksi header

Penerus memindahkan byte. Ia tidak mengurai HTTP, sehingga tidak dapat menyisipkan header ke dalam permintaan yang tidak pernah dibacanya sebagai permintaan, dan tidak dapat menambahkan apa pun ke aliran TLS yang dilewatkannya tanpa disentuh. Modul yang mengharapkan header proksi akan terus menunggu header yang tidak dihasilkan komponen mana pun.

Dua mekanisme dapat membawa alamat asli, dan keduanya memerlukan kesepakatan di kedua ujung. Protokol PROXY menambahkan header kecil di awal koneksi, dan backend harus dikonfigurasi untuk mengharapkannya; backend yang tidak mengharapkannya akan memperlakukan byte itu sebagai awal permintaan dan gagal dengan cara yang membingungkan. Header proksi tepercaya seperti X-Forwarded-For berfungsi ketika proksi yang memahami HTTP menyetelnya dan backend diberi tahu rekan mana yang boleh menegaskannya.

Tak satu pun otomatis, dan tak satu pun aman secara bawaan. Backend yang percaya pada setiap header yang diteruskan masuk memungkinkan klien memilih alamatnya sendiri, yang mengubah ketidaktepatan log menjadi jalan pintas kontrol akses. Jalankan demonstrasinya sekali di host uji sebelum Anda mempercayai header apa pun di jalur produksi.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

Direktori pemetaan sumber yang opsional

Berbagi port memiliki argumen direktori opsional yang mencatat pemetaan antara alamat sumber asli dan koneksi penerusan, pada platform tempat fitur ini diterapkan. Sisi web diharapkan menanyakan pemetaan itu; itu bukan header, dan tidak disuntikkan ke permintaan.

Rancangan itu layak diketahui karena menjelaskan mengapa sebagian penerapan melaporkan alamat nyata dan sebagian tidak, dengan konfigurasi front-end yang tampak identik. Perbedaannya ada di sisi penerima, dan biasanya bersemayam di modul atau tambalan yang tidak diaktifkan secara bawaan oleh sebagian besar server web terpaket. Bacalah dokumentasi server web Anda untuk kait tepat yang ditawarkannya, dan pastikan modulnya termuat alih-alih menganggapnya begitu.

Jika Anda menempuh jalur ini, perlakukan sebagai integrasi dua bagian: pemetaan yang ditulis penerus dan pencarian yang dilakukan backend. Verifikasi keduanya, dan pastikan direktori bertahan setelah mulai ulang serta tidak tumbuh tanpa batas pada pendengar yang sibuk.

Putuskan komponen mana yang menjamin alamat

Sebelum mengubah konfigurasi, sebutkan komponen yang boleh menegaskan alamat klien dan komponen yang boleh mempercayainya. Satu jawaban tertulis mencegah penyimpangan biasa, ketika tiga lapisan berbeda masing-masing memercayai sumber yang berbeda.

Tiga rancangan mencakup sebagian besar kebutuhan. Pisahkan pendengar publik dan pendengar web, agar server web melihat rekan sungguhan dan tidak ada masalah atribusi. Taruh proksi terbalik yang memahami HTTP di depan, akhiri atau urai permintaan di sana, dan biarkan ia menyetel header yang diteruskan untuk backend yang hanya memercayai proksi itu. Atau pertahankan berbagi port dan terima bahwa log menunjukkan lompatan, dengan aturan akses yang ditulis terhadap identitas aplikasi alih-alih alamat.

Yang tidak berhasil adalah memperlakukan alamat loopback yang diteruskan sebagai bukti bahwa permintaan berasal dari mesin ini. Kesimpulan itu justru terbalik: alamat itu hadir justru karena komponen lokal membuat koneksinya. Aturan yang ditulis begitu menerima siapa pun yang dapat menjangkau pendengar.

Uji aturannya, bukan halamannya

Halaman yang termuat membuktikan jalur penerusan bekerja dan tidak mengatakan apa pun tentang atribusi. Uji konsumen alamatnya: aturan akses, batas laju, entri audit, pencarian geografis.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

Bandingkan permintaan eksternal yang diizinkan dengan catatan front-end maupun backend, dan pastikan aturan yang seharusnya menolak tetap menolak dan yang seharusnya mengizinkan tetap mengizinkan. Jika baris log benar tetapi aturan masih berperilaku seolah semua orang lokal, aturan itu membaca bidang yang berbeda dari yang Anda perbaiki.

Akhiri dengan menulis rantai atribusi ke dalam catatan penerapan: pendengar mana, penerus mana, header atau pemetaan mana, dan backend mana yang dikonfigurasi untuk mempercayainya. Orang berikutnya yang membaca baris log akan memerlukan keempatnya, dan tidak adanya catatan itu adalah cara tiket yang sama terbuka lagi setahun kemudian. Simpan di samping konfigurasi, bukan di utas obrolan.