Membuka Akses Home Server Tanpa Membuka Port dengan Cloudflare Tunnel

Menjalankan aplikasi di home server itu relatif mudah. Tantangannya muncul ketika aplikasi tersebut perlu diakses dari luar rumah: apakah harus melakukan port forwarding di router, memasang reverse proxy, membuka firewall, lalu menjaga IP publik agar tetap dapat ditemukan?

Untuk beberapa layanan self-hosted yang saya kelola, saya memilih pendekatan berbeda: aplikasi hanya mendengarkan koneksi lokal, sedangkan Cloudflare Tunnel menjadi jalur masuknya.

Cloudflare Tunnel membuat koneksi outbound-only dari server menuju jaringan Cloudflare. Artinya, saya tidak perlu membuka port inbound di router atau mengekspos alamat IP origin secara langsung. Pengguna mengakses hostname HTTPS seperti biasa, kemudian Cloudflare meneruskan request melalui tunnel ke service lokal.

Foto oleh Christina Morillo melalui Pexels.

Arsitektur Sederhananya

Alur request-nya dapat dibayangkan seperti ini:

Browser
   │ HTTPS
   ▼
Cloudflare Edge
   │ tunnel terenkripsi
   ▼
cloudflared di home server
   │ http://127.0.0.1:3000
   ▼
Aplikasi / container

Ada dua keputusan penting dalam desain ini:

1. Tidak ada port aplikasi yang dibuka ke internet.
2. Origin hanya menerima koneksi lokal, misalnya di 127.0.0.1:3000.

Tunnel bukan pengganti seluruh praktik keamanan, tetapi ia mengurangi attack surface di sisi jaringan. Internet tidak perlu mengetahui lokasi atau alamat IP origin untuk mengakses aplikasi.

Gambar dihasilkan melalui API cf/@cf/black-forest-labs/flux-2-klein-4b lewat 9router sebagai ilustrasi konseptual. Arah koneksi, gembok, dan shield divisualisasikan sesuai alur Cloudflare Tunnel; shield bukan logo resmi Cloudflare.

Kenapa Tidak Langsung Port Forwarding?

Port forwarding tetap valid untuk kebutuhan tertentu, tetapi membawa beberapa pekerjaan tambahan:

• port publik harus dibuka dan dipantau;
• firewall perlu dikonfigurasi dengan benar;
• perubahan IP publik dapat memerlukan Dynamic DNS;
• TLS dan reverse proxy harus dikelola sendiri;
• alamat IP origin lebih mudah terlihat;
• router menjadi bagian penting dari jalur deployment.

Cloudflare Tunnel memindahkan sebagian besar pekerjaan itu ke koneksi keluar dari cloudflared. Selama server bisa mencapai Cloudflare, tunnel dapat dibuat tanpa meminta router menerima koneksi baru dari internet.

Pendekatan ini juga cocok untuk koneksi rumahan yang berada di balik CGNAT, karena server tidak harus memiliki alamat IPv4 publik yang dapat menerima koneksi inbound.

1. Batasi Aplikasi ke Localhost

Sebelum membuat tunnel, saya memastikan service tidak mendengarkan di semua interface.

Untuk aplikasi Node.js, konsepnya seperti ini:

HOST=127.0.0.1 PORT=3000 npm start

Jika aplikasinya berjalan di Docker Compose, mapping port dapat dibatasi ke loopback host:

services:
  app:
    image: example/my-app:latest
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped

Perbedaannya kecil tetapi penting:

0.0.0.0:3000       → menerima koneksi dari seluruh interface
127.0.0.1:3000     → hanya menerima koneksi dari mesin yang sama

Sebelum melanjutkan, origin perlu diuji langsung dari server:

curl -I http://127.0.0.1:3000

Tunnel tidak akan memperbaiki aplikasi yang memang belum sehat. Karena itu, saya selalu memisahkan pemeriksaan origin lokal dan jalur publik saat troubleshooting.

2. Buat Tunnel dan Hubungkan Hostname

cloudflared dapat dikelola melalui dashboard Cloudflare atau CLI. Pada named tunnel yang dikonfigurasi dari file, bentuk dasarnya seperti berikut:

# /etc/cloudflared/config.yml
tunnel: TUNNEL_ID
credentials-file: /etc/cloudflared/TUNNEL_ID.json

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:3000
  - service: http_status:404

Rule terakhir adalah fallback. Request yang tidak cocok dengan hostname yang didefinisikan akan mendapat respons 404, bukan diteruskan secara tidak sengaja ke service lain.

Setelah konfigurasi siap, tunnel dapat dijalankan sebagai service:

sudo cloudflared service install
sudo systemctl enable --now cloudflared

Untuk remote-managed tunnel, dashboard Cloudflare memberikan token instalasi dan konfigurasi public hostname dapat dilakukan dari UI. Saya lebih menyukai jalur ini ketika tujuannya agar operasi harian dapat dilihat dan dikontrol dari dashboard, sedangkan konfigurasi file lebih nyaman untuk server yang seluruh infrastrukturnya dikelola sebagai kode.

3. Tambahkan Cloudflare Access untuk Layanan Privat

Tidak semua hostname yang berhasil diteruskan oleh tunnel harus terbuka untuk publik.

Untuk dashboard admin, monitoring, atau aplikasi internal, saya menambahkan Cloudflare Access di depannya. Access memeriksa identitas pengguna sebelum request diteruskan ke origin. Policy dapat dibatasi berdasarkan email, domain organisasi, identity provider, atau service token untuk komunikasi antarmesin.

Dengan susunan ini, lapisan aksesnya menjadi:

Internet
  → Cloudflare TLS
  → Access policy
  → Tunnel
  → Service lokal

Penting untuk membedakan dua hal:

• Tunnel menyediakan jalur koneksi ke origin.
• Access menentukan siapa yang boleh melewati jalur tersebut.

Untuk blog atau API publik, Access mungkin tidak diperlukan. Untuk panel administrasi, saya menganggapnya sebagai default yang lebih aman daripada hanya mengandalkan halaman login aplikasi.

4. Verifikasi dari Dalam dan Luar Server

Setelah deployment, saya memeriksa setiap lapisan secara terpisah.

Periksa service lokal

curl -I http://127.0.0.1:3000

Periksa status daemon

systemctl status cloudflared
journalctl -u cloudflared --since "15 minutes ago"

Periksa hostname publik

curl -I https://app.example.com

Pastikan port tidak terekspos di semua interface

ss -lntp

Yang saya harapkan adalah service muncul pada 127.0.0.1:3000, bukan 0.0.0.0:3000. Saya juga menguji hostname dari jaringan lain, misalnya koneksi seluler, agar hasilnya tidak tertukar dengan cache DNS atau akses jaringan lokal.

Pola Troubleshooting yang Saya Pakai

Ketika hostname tidak dapat diakses, saya tidak langsung mengubah DNS atau membuat ulang tunnel. Saya memeriksa jalurnya dari bawah ke atas:

1. Apakah aplikasi menjawab di localhost?
2. Apakah port dan protokol di ingress benar? HTTP dan HTTPS origin tidak boleh tertukar.
3. Apakah service cloudflared aktif dan tunnel berstatus healthy?
4. Apakah public hostname mengarah ke tunnel yang benar?
5. Apakah policy Access mengizinkan identitas yang sedang dipakai?
6. Apakah koneksi outbound server ke Cloudflare diblokir firewall?

Urutan ini membantu membedakan error aplikasi, error konektivitas tunnel, dan penolakan policy. Tanpa pemisahan tersebut, troubleshooting mudah berubah menjadi trial and error.

Batasan yang Tetap Perlu Dipahami

Cloudflare Tunnel bukan alasan untuk mengabaikan keamanan origin. Saya tetap melakukan beberapa hal berikut:

• rutin memperbarui image dan dependency;
• memakai autentikasi aplikasi selain Access jika datanya sensitif;
• tidak menaruh secret di repository;
• membatasi permission container dan volume;
• memantau log aplikasi serta cloudflared;
• menyiapkan backup yang diuji, bukan hanya dibuat;
• menggunakan jaringan privat seperti Tailscale untuk SSH dan administrasi host.

Ada juga risiko ketergantungan: ketika koneksi internet rumah, proses cloudflared, atau layanan Cloudflare bermasalah, hostname ikut tidak tersedia. Untuk layanan yang kritis, health check, alert, dan rencana pemulihan tetap dibutuhkan.

Kapan Pola Ini Cocok?

Menurut saya, Cloudflare Tunnel sangat cocok untuk:

• dashboard home lab;
• aplikasi web pribadi;
• dokumentasi internal;
• layanan monitoring;
• staging environment;
• webhook receiver dengan kontrol akses yang jelas.

Namun saya tidak menjadikannya jalan pintas untuk membuka database langsung ke internet. Database, SSH, dan control plane sebaiknya tetap berada di jaringan privat atau membutuhkan mekanisme akses khusus yang lebih ketat.

Penutup

Hal yang paling saya suka dari Cloudflare Tunnel bukan sekadar “tidak perlu port forwarding”. Nilai utamanya adalah pemisahan tanggung jawab yang lebih jelas:

• aplikasi hanya melayani origin lokal;
• cloudflared mengurus koneksi keluar;
• Cloudflare mengurus endpoint publik dan TLS;
• Access mengurus policy identitas;
• jaringan privat tetap digunakan untuk administrasi server.

Hasilnya adalah deployment self-hosted yang lebih mudah dioperasikan tanpa membuat setiap aplikasi menjadi port publik baru. Bagi saya, ini contoh bagus bahwa desain infrastruktur yang aman tidak selalu harus lebih rumit—asal boundary-nya dibuat dengan sengaja dan setiap lapisan diverifikasi.

Referensi lebih lanjut dapat ditemukan di dokumentasi Cloudflare Tunnel dan dokumentasi Cloudflare Access.

Kalau ingin memahami jalur request ini dari sisi fundamental jaringan, baca juga Memahami Layer-Layer Jaringan: Dari Kabel Sampai Aplikasi.