Metode untuk Mengambil Client Source IP

Dalam situasi tertentu, layanan kami memerlukan penggunaan IP klien untuk alasan bisnis atau keamanan tertentu. Namun, skenario yang biasa terjadi adalah lalu lintas melewati beberapa jaringan, load balancer, atau layanan proxy sebelum mencapai layanan yang sebenarnya. Pada setiap lapisan proses ini, IP klien asli mungkin hilang, meninggalkan layanan kami hanya dengan IP dari jaringan sebelumnya. Hasil ini tidak ideal bagi kami.

Karena kompleksitas tumpukan teknologi kami, mendapatkan IP klien melibatkan penggunaan berbagai metode, terkadang dalam kombinasi.

Mengelola IP Klien melalui NAT

Dalam beberapa infrastruktur IDC yang didirikan atau disewa oleh pengguna, layanan kami mungkin berada di jaringan LAN terpisah di belakang gateway. Ketika klien mencoba terhubung ke layanan kami dari jaringan eksternal, lalu lintas akan diarahkan melalui gateway.

Skenario serupa mungkin terjadi ketika menggunakan layanan cloud. Jaringan VPC yang disediakan oleh platform cloud publik berfungsi sebagai jaringan LAN independen, terisolasi dari VPC lain dan internet. Akibatnya, gateway diperlukan untuk memfasilitasi akses internet eksternal dan terhubung ke layanan eksternal.

Gateway ini, yang bisa berupa router atau perangkat firewall, biasanya menawarkan layanan translasi alamat DNAT (Destination NAT) untuk layanan internal. Ini melibatkan gateway yang memiliki satu atau lebih alamat IP publik dan meneruskan lalu lintas dari port tertentu pada IP publik ke port tertentu pada IP internal. Gateway mengelola penerusan lalu lintas dan pemetaan port. Namun, karena modifikasi alamat sumber dalam header paket IP asli oleh gateway, layanan kami di dalam jaringan internal hanya dapat mengidentifikasi alamat IP gateway, bukan alamat klien yang sebenarnya.

Secara historis, kemampuan DNAT yang disediakan oleh perangkat jaringan atau perangkat lunak relatif dasar. Mereka beroperasi terutama di lapisan 3 dan tidak memiliki kesadaran dan kemampuan manipulasi untuk payload lapisan yang lebih dalam. Tujuan utama mereka adalah eksposur layanan, dan mereka tidak dapat meneruskan IP klien ke hilir. Selain itu, karena keterbatasan kinerja perangkat atau perangkat lunak ini, ada batasan pada jumlah koneksi aktif dan jumlah maksimum koneksi baru yang dapat mereka tangani. Skalabilitas tanpa peningkatan perangkat keras seringkali sulit, membuat mereka kurang adaptif terhadap lingkungan dinamis saat ini.

Untuk mengatasi keterbatasan ini, kami beralih ke load balancing, yang memiliki kemampuan manipulasi lalu lintas yang lebih canggih.

IP Klien dalam Load Balancing

Secara umum, load balancing terutama dikategorikan menjadi dua jenis berdasarkan lapisan kerjanya: lapisan 4 dan lapisan 7, yang masing-masing sesuai dengan aliran data TCP dan lalu lintas aplikasi (diwakili oleh HTTP).

Berbeda dengan gateway IP, load balancing tidak memodifikasi header paket IP. Pada tingkat paket IP, load balancing hanya melakukan penerusan transparan. Akibatnya, berbeda dengan DNAT yang dibahas sebelumnya, load balancing memastikan alamat IP sumber yang terkandung dalam paket IP diteruskan dengan benar ke komponen di belakang load balancer.

Untuk load balancing lapisan 4, setelah menyelesaikan penerusan lalu lintas dasar, layanan berikutnya dapat mengambil IP klien dengan akurat tanpa memerlukan pemrosesan khusus. Dalam skenario luar biasa, load balancing dapat memanfaatkan Proxy Protocol. Ini melibatkan penambahan bagian baru sebelum payload lalu lintas asli, yang mencakup IP klien. Server proxy terbalik lainnya atau layanan itu sendiri di belakang load balancer kemudian dapat menginterpretasikan data Proxy Protocol untuk mendapatkan IP klien.

Untuk load balancing lapisan 7, load balancing memiliki kemampuan pemrosesan lalu lintas yang lebih mendalam. Load balancing dapat langsung menyampaikan alamat IP sumber pada tingkat protokol HTTP. Pendekatan yang umum adalah penggunaan header HTTP X-Forwarded-For. Komponen load balancing mengekstrak alamat IP sumber dari paket IP lalu lintas, kemudian mengurai dan menulis ulang permintaan HTTP. Load balancing menyisipkan bidang XFF baru di header permintaannya, yang mencakup nilai IP klien.

HTTPS menimbulkan tantangan khusus karena payloadnya yang terenkripsi, membuat komponen load balancing tidak dapat langsung memanipulasi header HTTP-nya. Dalam situasi seperti ini, pendekatan berikut dapat dipertimbangkan:

• Tanpa persyaratan khusus, memperlakukan lalu lintas HTTPS sebagai lalu lintas TLS standar dan meneruskannya langsung di lapisan 4 adalah pilihan. Dalam skenario ini, IP klien masih dapat dikirim ke layanan di belakang load balancer melalui header paket IP.

• Ketika fungsionalitas lapisan 7 diperlukan, hosting sertifikat TLS pada komponen load balancing memungkinkan terminasi TLS. Proses ini melibatkan penghapusan enkripsi TLS di lapisan load balancing, menggunakan HTTP biasa di LAN di belakang load balancer, atau membangun koneksi HTTPS baru ke layanan alih-alih penerusan langsung. Ini memungkinkan komponen load balancing untuk kembali menangani lalu lintas HTTP asli dan terus meneruskan IP menggunakan metode XFF.

Melalui penanganan lalu lintas yang cermat, load balancing menawarkan berbagai metode untuk menyampaikan IP klien ke layanan backend. Implementasi representatif dari komponen load balancing termasuk layanan ELB berbasis cloud, F5 BIG-IP berbasis perangkat keras, Linux Virtual Server (LVS) berbasis kernel Linux, dan NGINX berbasis perangkat lunak pengguna.

Transmisi IP Klien dalam Layanan CDN

Terkadang, kami memanfaatkan layanan CDN yang disediakan oleh platform cloud publik untuk meningkatkan kecepatan akses pengguna ke layanan kami. Fungsi mereka mirip dengan server proxy terbalik lapisan 7, tetapi dalam konteks yang lebih luas, CDN dapat dianggap sebagai bagian dari domain load balancing.

Layanan CDN biasanya menyediakan kemampuan terminasi TLS dan dapat memasukkan IP klien dalam permintaan HTTP yang dikirim ke layanan. Misalnya, layanan CDN AWS CloudFront mendukung penerusan IP klien menggunakan metode XFF, mirip dengan pendekatan yang digunakan dalam load balancing lapisan 7.

Pemanfaatan API Gateway

Sementara komponen load balancing biasanya menawarkan kemampuan kontrol dasar untuk lalu lintas, API yang disediakan oleh load balancer berbasis cloud atau perangkat keras bisa sulit disesuaikan dengan kebutuhan bisnis spesifik kami. Dalam skenario seperti ini, kami beralih ke komponen yang lebih adaptif untuk menerapkan strategi yang disesuaikan dengan layanan kami. Di sinilah API gateway, seperti Apache APISIX atau API7 Enterprise, berperan.

APISIX dan API7 Enterprise mendukung Proxy Protocol, memungkinkan pengambilan IP klien dari load balancer.

Selain itu, mereka memiliki plugin bernama "real-ip," mirip dengan ngx_http_realip_module pada NGINX. Plugin ini mengambil IP klien dari sumber dan menggunakannya untuk transmisi hilir dan pencatatan. Plugin real-ip pada APISIX dan API7 Enterprise meningkatkan fungsionalitas yang ditemukan pada NGINX. Ini memungkinkan aktivasi atau deaktivasi dinamis fitur IP sumber asli dan memperluas sumber IP klien di luar batasan ngx_http_realip_module, yang terbatas pada header HTTP dan Proxy Protocol. Ini dapat memanfaatkan variabel NGINX atau APISIX yang diperluas, seperti parameter query atau bidang POST form.

Ringkasan

Dengan memanfaatkan kombinasi teknologi di berbagai lapisan, kami dapat secara efektif meneruskan IP klien melalui setiap komponen layanan, melayani kebutuhan bisnis dan keamanan.

Untuk mempelajari lebih lanjut tentang solusi manajemen API, hubungi API7.ai.