Isolasi Total Server Tanpa Port Publik Menggunakan Cloudflare Tunnel (cloudflared)

Menjalankan server web atau laboratorium rekayasa sistem (homelab) mandiri sering kali menghadapkan kita pada dilema klasik keamanan jaringan: bagaimana cara mempublikasikan layanan web ke internet publik tanpa mengekspos IP publik rumah atau membuka port router?

Metode konvensional seperti Port Forwarding (membuka port 80 dan 443 di NAT router) memiliki risiko keamanan yang sangat tinggi: IP publik Anda langsung tercatat di radar mesin pencari seperti Shodan atau Censys, mengundang serangan brute-force tanpa henti, pemindaian vulnerabilitas otomatis, hingga ancaman Distributed Denial of Service (DDoS).

Artikel ini mendokumentasikan arsitektur ingress modern yang diadopsi oleh Lab Regsi: mengisolasi infrastruktur lokal secara total dari dunia luar menggunakan Cloudflare Tunnel (cloudflared), merutekan belasan subdomain ke port lokal yang sama, serta menerapkan catch-all 404 fallback sebagai benteng pertahanan terakhir.

1. Perbandingan Paradigma: Tradisional vs Zero Trust Tunnel

Mari kita bandingkan perbedaan arsitektur antara pembukaan port tradisional dengan teknologi tunneling terenkripsi modern:

+-------------------------------------------------------------------------+
|                  PARADIGMA 1: PORT FORWARDING TRADISIONAL               |
|                                                                         |
|  [ Internet ] ---> [ Router Port 80/443 Terbuka ] ---> [ Server Lokal ] |
|                         |                                               |
|                         +-- IP Publik terekspos langsung                |
|                         +-- Rentan scanning Shodan / Botnet             |
|                         +-- Memerlukan Dynamic DNS (DDNS)               |
|                         +-- Tidak bisa menembus CGNAT ISP               |
+-------------------------------------------------------------------------+

+-------------------------------------------------------------------------+
|                  PARADIGMA 2: CLOUDFLARE TUNNEL (ZERO TRUST)            |
|                                                                         |
|  [ Internet ] ---> [ Cloudflare Anycast Edge (DDoS, WAF, SSL) ]         |
|                                      |                                  |
|     Koneksi Keluar (Outbound QUIC)   | (Tidak ada port inbound terbuka!)|
|     dibuat oleh cloudflared          v                                  |
|  [ Server Lokal: cloudflared ] <-----+                                  |
|          |                                                              |
|          v (Loopback 127.0.0.1:80)                                      |
|  [ Caddy Web Server ]                                                   |
+-------------------------------------------------------------------------+

Keunggulan Mendasar Cloudflare Tunnel:

1. Zero Open Inbound Ports: Tidak ada satu pun port yang dibuka pada firewall router lokal. Seluruh aturan firewall router disetel ke mode default DROP INBOUND.
2. Menembus CGNAT (Carrier-Grade NAT): Sebagian besar ISP seluler dan broadband perumahan tidak lagi memberikan IP publik statis, melainkan IP privat di balik CGNAT. Karena cloudflared membuat koneksi keluar (outbound-only), tunnel berfungsi mulus tanpa peduli topologi NAT ISP Anda.
3. Perlindungan DDoS Terdistribusi: Seluruh traffic internet disaring terlebih dahulu oleh jaringan Anycast Cloudflare di tepi (edge). Serangan layer 3, 4, dan 7 dibersihkan sebelum sempat mendekati server fisik Anda.
4. Enkripsi Kuat Berbasis QUIC/HTTP2: Terowongan komunikasi antara server lokal dan edge Cloudflare dibangun di atas protokol transport QUIC (UDP port 7844) dengan enkripsi TLS 1.3 dan algoritma post-quantum.

2. Anatomi File Konfigurasi Ingress (config.yml)

Di tingkat sistem operasi, daemon cloudflared membaca sebuah file konfigurasi deklaratif yang menentukan bagaimana traffic dari berbagai nama domain publik diteruskan ke layanan lokal.

Berikut adalah konfigurasi produksi aktual yang digunakan di Lab Regsi (/etc/cloudflared/config.yml):

tunnel: 3ae71b58-5a89-4fb2-932b-92016cd06476
credentials-file: /home/apu/.cloudflared/3ae71b58-5a89-4fb2-932b-92016cd06476.json

ingress:
  - hostname: hermes.apu.web.id
    service: http://localhost:80
  - hostname: mcp.apu.web.id
    service: http://localhost:80
  - hostname: apu.web.id
    service: http://localhost:80
  - hostname: keuangan.apu.web.id
    service: http://localhost:80
  - hostname: next.apu.web.id
    service: http://localhost:80
  - hostname: router.apu.web.id
    service: http://localhost:80
  - hostname: api.apu.web.id
    service: http://localhost:80
  - hostname: regsi.my.id
    service: http://localhost:80
  - hostname: fb-bot.apu.web.id
    service: http://localhost:80
  # Aturan Wajib Terakhir: Catch-All Fallback
  - service: http_status:404

3. Logika Evaluasi Ingress: First Match Wins

Konfigurasi ingress dievaluasi secara berurutan dari atas ke bawah (top-to-bottom).

1. Host Header Preservation: Ketika sebuah request untuk regsi.my.id tiba di edge Cloudflare, edge membungkus paket tersebut dan mengirimkannya melalui tunnel ke daemon cloudflared lokal.
2. cloudflared mencocokkan hostname dengan entri:

   - hostname: regsi.my.id
     service: http://localhost:80

3. Daemon membuat koneksi TCP lokal ke http://localhost:80 dan meneruskan header Host: regsi.my.id asli.
4. Di sisi server lokal, Caddy menerima request tersebut pada port 80. Caddy membaca blok virtual host http://regsi.my.id:80, lalu menyajikan konten direktori /srv/www/lab.
5. Begitu pula saat request untuk apu.web.id tiba, request diarahkan ke port 80 yang sama, namun Caddy menyajikan direktori /srv/www/etalase karena perbedaan Host header.

Pola ini disebut Unified Single Port Ingress: alih-alih membuka port yang berbeda-beda untuk setiap microservice di cloudflared, seluruh domain dialirkan ke reverse proxy lokal (Caddy) yang bertindak sebagai traffic dispatcher cerdas.

4. Mengapa Baris Catch-All - service: http_status:404 Mutlak Diperlukan?

Aturan arsitektural terpenting pada Cloudflare Tunnel yang sering diabaikan pemula adalah: baris ingress terakhir wajib berupa fallback tanpa matcher hostname.

  - service: http_status:404

Mengapa?

1. Validasi Startup Cloudflared: Jika Anda lupa menyertakan aturan fallback ini, daemon cloudflared akan menolak berjalan saat booting dengan pesan error fatal: Validation failed: Ingress rule must end with a catch-all service.
2. Mitigasi Salah Arah DNS (Misconfigured DNS): Jika suatu hari Anda menambahkan CNAME baru di dashboard Cloudflare DNS yang mengarah ke UUID tunnel ini tetapi lupa mendaftarkannya di config.yml, cloudflared akan secara aman menolak request dengan status HTTP 404 standar, alih-alih melempar exception atau drop packet yang membingungkan.
3. Penyekatan Internal Host: Mencegah kebocoran request yang mencoba menyusup ke internal loopback address selain host yang telah diverifikasi secara eksplisit.

5. Alur Kerja Implementasi & Validasi Lapangan

Untuk menerapkan dan memverifikasi arsitektur ini secara mandiri di Linux:

Langkah 1: Validasi Sintaks Ingress

Sebelum me-restart service sistem, selalu validasi bahwa struktur YAML dan aturan ingress Anda bebas kesalahan:

cloudflared tunnel ingress validate

Jika konfigurasi valid, terminal akan mengembalikan respons konfirmasi bersih:

OK

Langkah 2: Uji Coba Routing URL Spesifik

Anda dapat menguji bagaimana aturan ingress mengevaluasi URL tertentu tanpa perlu mengirim traffic internet riil:

cloudflared tunnel ingress rule https://regsi.my.id

Output:

Matched rule #8:
  Hostname: regsi.my.id
  Service: http://localhost:80

Dan ketika menguji domain yang tidak terdaftar:

cloudflared tunnel ingress rule https://unregistered-domain.com

Output:

Matched rule #10 (catch-all):
  Service: http_status:404

Langkah 3: Menjalankan Daemon via Systemd

Pastikan service berjalan otomatis saat sistem booting:

sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

6. Kesimpulan & Manfaat Strategis

Mengganti metode port forwarding konvensional dengan Cloudflare Tunnel adalah lompatan besar dalam standar keamanan infrastruktur mandiri.

Dengan topologi ini:

• Server fisik di Lab Regsi berada dalam status Dark Origin (tidak terlihat oleh mesin pemindai internet publik).
• Tidak ada kekhawatiran terkait kebocoran IP publik rumah atau serangan DDoS volumetrik.
• Seluruh manajemen multi-domain dan microservice tersentralisasi secara rapi, elegan, dan teruji di satu titik ingress.