Reverse Proxy vs VPN vs Tunnel: Kapan Pakai yang Mana
Hampir setiap tim yang mengelola aplikasi internal — entah itu sistem informasi rumah sakit, dashboard operasional, atau API yang cuma boleh diakses aplikasi tertentu — cepat atau lambat menghadapi pertanyaan yang sama: bagaimana cara mengekspos layanan yang jalan di jaringan lokal atau di server tanpa IP publik, supaya bisa diakses dari luar? Jawabannya biasanya jatuh ke salah satu dari tiga pendekatan: reverse proxy, VPN, atau tunnel. Ketiganya sering disebut seolah bisa saling menggantikan, padahal masing-masing menyelesaikan masalah yang berbeda, dan salah pilih bisa berarti membuka lubang keamanan yang tidak perlu, atau sebaliknya membuat sesuatu yang sederhana jadi terlalu rumit.
Reverse Proxy: pintu masuk untuk satu layanan spesifik
Reverse proxy duduk di depan satu atau beberapa layanan web dan meneruskan request yang masuk ke backend yang sesuai, biasanya berdasarkan domain atau path. Nginx dan Traefik adalah dua contoh yang paling sering saya pakai. Pola paling umum: server punya IP publik, reverse proxy jalan di situ, lalu meneruskan traffic ke container atau service backend yang sebenarnya tidak punya akses langsung dari internet.
Kelebihannya ada di kontrol granular per-layanan: terminasi TLS di satu tempat, rate limiting, header keamanan, sampai load balancing ke beberapa instance backend — semuanya tanpa backend itu sendiri tahu apa-apa soal jaringan luar. Contoh konfigurasi sederhana untuk mengekspos satu aplikasi:
server {
listen 443 ssl;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Yang perlu diingat: reverse proxy memang ditujukan untuk membuka akses publik ke sebuah layanan. Kalau backend-nya sensitif — misalnya panel admin atau API internal — reverse proxy saja tidak cukup, harus ditambah lapisan otentikasi atau whitelist IP.
VPN: menyatukan jaringan, bukan cuma satu layanan
Kalau reverse proxy adalah pintu untuk satu ruangan, VPN adalah kunci untuk masuk ke seluruh gedung. VPN (baik model klasik seperti OpenVPN/IPsec, maupun yang lebih modern seperti WireGuard) membuat perangkat klien seolah-olah berada di jaringan yang sama dengan server tujuan. Begitu terhubung, klien bisa mengakses banyak layanan sekaligus — database, panel admin, mesin internal lain — persis seperti sedang duduk di kantor.
Ini yang membuat VPN jadi pilihan tepat untuk akses tim, bukan akses publik. Kalau saya perlu memberi beberapa orang akses ke banyak service internal sekaligus, VPN jauh lebih masuk akal daripada membuka reverse proxy untuk tiap layanan satu per satu. Konfigurasi WireGuard minimal biasanya cuma butuh beberapa baris, sebagai ilustrasi:
[Interface]
PrivateKey = <private-key-server>
Address = 10.20.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <public-key-klien>
AllowedIPs = 10.20.0.2/32Trade-off-nya: VPN memberi akses jaringan yang lebih luas, jadi permukaan risikonya ikut lebih luas kalau kredensial atau device klien bocor. Karena itu VPN idealnya dipasangkan dengan segmentasi jaringan yang jelas — jangan sampai satu koneksi VPN otomatis bisa menjangkau semua subnet tanpa batas.
Tunnel: solusi cepat tanpa IP publik atau buka port
Tunnel — seperti lanproxy yang saya pakai, atau alternatif seperti Cloudflare Tunnel dan ngrok — menyelesaikan masalah berbeda lagi: bagaimana mengekspos layanan yang jalan tanpa IP publik sama sekali, atau di belakang NAT/firewall yang konfigurasinya tidak bisa saya ubah. Server lokal membuat koneksi keluar ke relay di internet, dan relay itu yang meneruskan traffic publik masuk lewat koneksi tersebut. Tidak perlu buka port inbound di router atau firewall.
Ini sangat berguna untuk mesin di jaringan kantor atau fasilitas kesehatan yang tidak punya IP publik tetap, tapi perlu diakses dari luar untuk keperluan tertentu seperti deployment atau demo. Konsekuensinya, tunnel menambah satu pihak ketiga (relay) di jalur traffic — untuk layanan yang datanya sensitif, pastikan koneksi ke relay terenkripsi end-to-end.
Cara saya memilih
Disederhanakan jadi pertanyaan praktis: pakai reverse proxy kalau yang mau diekspos satu layanan web spesifik dan servernya sudah punya IP publik. Pakai VPN kalau yang butuh akses adalah sekelompok orang ke banyak layanan sekaligus, dan saya bisa mengontrol siapa yang boleh konek. Pakai tunnel kalau servernya tidak punya IP publik atau saya tidak bisa mengubah konfigurasi jaringan di sisi server, tapi layanan itu tetap harus bisa diakses dari luar.
Ketiganya juga tidak eksklusif — kombinasi sering dipakai: tunnel membawa traffic keluar dari jaringan tanpa IP publik, reverse proxy di ujung menerima traffic itu untuk routing ke layanan yang tepat, sementara VPN dipakai terpisah untuk akses tim ke infrastruktur backend. Prinsip yang saya pegang: pilih pendekatan berdasarkan siapa yang butuh akses dan ke berapa banyak layanan, bukan mana yang paling gampang di-setup. Kemudahan setup itu menggoda, tapi permukaan risiko yang salah ukur biasanya baru terasa belakangan.