Apa yang sebenarnya dikatakan REMOTE_ADDR PHP di balik VPN
Ini nilai yang diberikan server web Anda, bukan kueri ke dalam terowongan. Telusuri jalur permintaan, periksa siapa yang boleh menulis ulang, dan simpan identitas di aplikasi.
Seseorang bertanya mengapa pengguna VPN muncul di log aplikasi dengan alamat milik gateway, atau dengan alamat yang berubah setelah makan siang. Jawabannya dimulai dari apa nilai itu: entri yang diletakkan server web di lingkungan permintaan. Ini bukan kueri ke dalam terowongan, bukan identitas sertifikat, dan bukan janji bahwa nomor itu milik satu orang. Membacanya sebagai salah satu dari ketiganya menghasilkan jawaban percaya diri yang salah dengan cara berbeda-beda.
Nilai berasal dari server, bukan dari terowongan
PHP menerima lingkungan permintaan dari apa yang menjalankan skrip. Referensi variabel server PHP menjelaskan entri ini sebagai buatan server web, dengan ketersediaan yang bergantung pada bagaimana permintaan datang.
Skrip yang dijalankan sebagai hook baris perintah VPN adalah konteks eksekusi yang sama sekali berbeda. Ia tidak punya permintaan web, soket klien, dan REMOTE_ADDR, itulah sebabnya kode web yang disalin ke hook menghasilkan nilai kosong alih-alih nilai salah. Hook punya lingkungan sendiri yang diisi daemon, dan didokumentasikan terpisah. Meraih REMOTE_ADDR di sana berarti meraih variabel yang tidak pernah disetel.
Ingat perbedaan itu sebelum membandingkan dua log. Mungkin Anda membandingkan permintaan halaman dengan hook, dan itu bukan perbandingan sama sekali. Periksa konteks eksekusi dulu, alamat kemudian.
Telusuri jalur permintaan sebelum memercayai angkanya
Alamat yang dilaporkan adalah peer dari koneksi yang dilihat server web. Sisipkan apa pun antara klien dan server itu dan peer berubah. Penerjemahan, penghentian, dan penyeimbangan beban masing-masing menggeser pengamatan satu lompatan lebih jauh dari pengguna.
Empat jalur umum menghasilkan empat pengamatan berbeda.
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
Tuliskan jalur itu dengan nama tujuan, keluarga alamat, dan setiap titik penerjemahan. Tanpa peta itu, nilai benar dan nilai salah tampak identik dalam satu baris log. Dua baris diagram menghemat satu sore perdebatan.
Penggantian hanya terjadi di tempat yang dikonfigurasi
Server atau kerangka kerja dapat dengan sengaja mengganti alamat klien. Modul remote-IP Apache dan modul real-IP NGINX keduanya melakukannya, dan nilai yang diterima PHP bergantung pada konfigurasi itu plus parameter yang diteruskan ke penangan skrip.
Jadi REMOTE_ADDR tidak selalu merupakan peer TCP yang tak tersentuh. Itu adalah peer sebagaimana server memilih melaporkannya setelah menerapkan kebijakannya sendiri. Perbedaan itu menentukan apakah nilai tersebut bukti atau hiasan.
Tanyakan kepada pemilik server bidang mana yang otoritatif dalam penerapan ini dan bagaimana peer asli dipertahankan ketika penggantian terjadi. Jika tidak ada yang bisa menjawab, log belum membuktikan apa pun.
Jangan membaca header penerusan dengan percaya
Pemanggil dapat mengirim header penerusan sendiri. Memperlakukan entri pertama yang dipisahkan koma sebagai alamat pengguna terverifikasi berarti memutuskan untuk percaya kepada siapa pun yang terhubung, tepat kebalikan dari tujuan header itu. Header menjelaskan sebuah rantai, dan hanya lapisan tepercaya yang dapat menjamin rantai itu.
Gunakan dukungan proxy tepercaya milik server atau kerangka kerja dengan rantai proxy sebenarnya dikonfigurasi, dan biarkan ia membuang nilai dari sumber di luar rantai tersebut. Penguraian yang ditulis tangan adalah tempat sebagian besar kegagalan menarik tinggal.
Alamat yang dilaporkan proxy juga tidak mengubah sumber paket yang dilihat firewall di hulu. Simpan metadata HTTP dan penyaringan jaringan sebagai pengamatan terpisah, karena keduanya menjawab pertanyaan berbeda.
Gunakan identitas aplikasi untuk keputusan
Untuk akses ke catatan pengguna, andalkan prinsipal yang terautentikasi dan aturan otorisasi aplikasi. Alamat internal dapat dialokasikan ulang, dan satu alamat yang diterjemahkan dapat mewakili ratusan pengguna bersamaan. Tidak satu pun sifat ini yang bisa diperbaiki oleh pemeriksaan alamat.
Jika operasi perlu mengaitkan permintaan dengan sesi VPN, gabungkan alamat yang diamati dan stempel waktu dengan catatan sesi otoritatif menurut model penerjemahan yang Anda dokumentasikan. Itu menghasilkan kaitan yang bisa Anda pertahankan; alamat saja tidak.
Untuk diagnosis, catat beberapa bidang yang diperlukan alih-alih seluruh larik server, yang bisa membawa header dan materi autentikasi. Kesimpulan yang berguna menyatakan apa arti nilai ini dalam penerapan ini, bukan nilai mana yang paling mirip klien.