Isolasi Egress Cloudflare WARP untuk 9Router di Balik Traefik: Studi Kasus Arsitektur Multi-Container

Mengintegrasikan jaringan proxy VPN ke dalam klaster Docker server produksi kerap menjadi dilema: Anda ingin satu layanan tertentu keluar melalui terowongan terenkripsi seperti Cloudflare WARP untuk memotong pembatasan jaringan atau menjaga privasi, tetapi Anda tidak ingin seluruh server—apalagi Traefik dan aplikasi web lainnya—ikut terjerat di dalamnya. Menjadikan VPN sebagai default gateway global di host VPS adalah resep bencana yang dapat memutus sesi SSH, mengacaukan sertifikat SSL, dan merusak perutean masuk (inbound routing).

Solusi paling elegan dan tahan banting untuk mengisolasi trafik keluar (outbound egress) satu kontainer tanpa mengorbankan akses masuk dari Traefik adalah menggunakan Container Network Namespace Sharing (network_mode: "service:warp-gw"). Dengan pendekatan ini, kontainer gateway WARP dan aplikasi 9Router berbagi satu stack jaringan terisolasi; perutean masuk dari Traefik tetap normal melalui domain publik, sementara seluruh koneksi keluar otomatis diarahkan ke Cloudflare WARP tanpa menyentuh rute host VPS.

Dalam artikel studi kasus ini, kami membedah arsitektur teknis, tantangan perutean asimetris, implementasi Docker Compose, serta hasil pengujian empiris yang telah divalidasi langsung pada lingkungan server privat.

Tantangan Arsitektur: Dilema Inbound vs Outbound

Pada skenario server tunggal berbasis Docker, sebuah host sering kali menjalankan lusinan layanan heterogen: reverse proxy utama (Traefik), beberapa instance sistem CMS, database MariaDB/PostgreSQL, hingga gateway antarmuka AI seperti 9Router.

Kebutuhan spesifik yang dihadapi adalah sebagai berikut:

• Akses Masuk (Inbound): Pengguna publik harus tetap dapat mengakses dashboard 9Router via URL terenkripsi (https://9router.example.com) yang ditangani oleh Traefik dengan sertifikat Let’s Encrypt otomatis.
• Akses Keluar (Outbound): Saat 9Router menghubungi penyedia LLM upstream atau API eksternal, koneksi tersebut wajib keluar menggunakan IP Anycast Cloudflare WARP.
• Isolasi Total: Traefik, host VPS, dan layanan lain di server tidak boleh melewati WARP dan harus tetap menggunakan IP publik asli server.

Kesalahan umum yang sering terjadi adalah memasang cloudflare-warp langsung di host OS dengan mode tunnel penuh. Ketika perintah perutean 0.0.0.0/0 -> warp0 dieksekusi, semua soket di server teralihkan. Sesi SSH terancam putus seketika, dan Traefik gagal menerima paket balasan dari jaringan Docker bridge karena terjadinya asymmetric routing drop.

Solusi Arsitektur: Konsep “Pod” Menggunakan Docker Compose

Penerapan pola jaringan antar-container ini hanyalah satu bagian kecil dari orkestrasi infrastruktur skala produksi yang lebih luas. Untuk memahami integrasi reverse proxy Traefik, pengelolaan SSL otomatis, hingga alur pipeline server yang resilien, pelajari Panduan Lengkap DevOps & Deployment Modern: Mengelola Server, Container, SSL, dan CI/CD dari Nol. Fondasi tersebut penting agar isolasi routing aplikasi tetap berjalan harmonis dengan ekosistem deployment utama.

Untuk menghindari manipulasi tabel routing (iptables / nftables) manual pada host yang rapuh saat sistem direboot, pendekatan terbaik mengadopsi konsep Pod mirip Kubernetes: menggabungkan dua kontainer ke dalam satu Network Namespace yang identik.

                     INTERNET
                        │
                        ▼ (Port 80/443)
                ┌──────────────┐
                │   Traefik    │ (Egress: IP Asli Server)
                └──────┬───────┘
                       │ (Network: traefik-public)
                       ▼
         ╔═════════════════════════════════╗
         ║   Shared Network Namespace      ║
         ║                                 ║
         ║  ┌───────────────────────────┐  ║
         ║  │   warp-gw (Gateway WARP)  │  ║ ── Cloudflare WARP ──▶ INTERNET
         ║  │   (IP: 172.x.x.x)         │  ║                       (Egress WARP)
         ║  └─────────────▲─────────────┘  ║
         ║                │ localhost:20128║
         ║  ┌─────────────┴─────────────┐  ║
         ║  │   9router                 │  ║
         ║  │   (network_mode:          │  ║
         ║  │    service:warp-gw)       │  ║
         ║  └───────────────────────────┘  ║
         ╚═════════════════════════════════╝



Container Lain (WordPress, DB, Agent) ─────────▶ INTERNET (IP Asli Server)
Host VPS ──────────────────────────────────────▶ INTERNET (IP Asli Server)

Dalam desain ini:

• Kontainer warp-gw bertindak sebagai pemilik antarmuka jaringan (network holder). Kontainer ini memiliki hak NET_ADMIN di dalam namespacenya sendiri dan menjalankan daemon WireGuard / Cloudflare WARP.
• Kontainer 9router tidak memiliki antarmuka virtual sendiri; ia dikonfigurasi dengan network_mode: "service:warp-gw". Bagi aplikasi 9Router, antarmuka jaringannya adalah antarmuka milik warp-gw, sehingga default route otomatis melewati terowongan Cloudflare.
• Traefik Routing: Traefik mengarahkan trafik domain langsung ke kontainer warp-gw pada port aplikasi (20128). Karena berada di namespace yang sama, port yang didengarkan oleh 9Router di 0.0.0.0:20128 dapat langsung dijangkau oleh Traefik melalui IP internal milik warp-gw.

Konfigurasi Docker Compose Final

Berikut adalah berkas docker-compose.yaml yang telah dianonymisasi dan siap digunakan pada lingkungan produksi:

services:
  warp-gw:
    image: caomingjun/warp:latest
    container_name: 9router-warp-gw
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
    volumes:
      - warp-data:/var/lib/cloudflare-warp
    networks:
      - app_network
      - traefik-public
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik-public"
      - "traefik.http.routers.9router.rule=Host(`9router.example.com`)"
      - "traefik.http.routers.9router.entrypoints=websecure"
      - "traefik.http.routers.9router.tls.certresolver=letsencrypt"
      - "traefik.http.services.9router.loadbalancer.server.port=20128"



9router:
    image: decolua/9router:latest
    container_name: 9router
    restart: unless-stopped
    network_mode: "service:warp-gw"
    depends_on:
      - warp-gw
    volumes:
      - ~/9router/data:/app/data



volumes:
  warp-data:



networks:
  app_network:
    external: true
  traefik-public:
    external: true

Poin Kunci Konfigurasi:

• cap_add: [NET_ADMIN]: Memberikan izin kepada kontainer gateway untuk membuat interface virtual tunnel (BoringTun/WireGuard) tanpa perlu hak akses privileged yang berlebihan.
• warp-data:/var/lib/cloudflare-warp: Menjamin kunci registrasi akun WARP tetap tersimpan meskipun kontainer dibuat ulang, mencegah keharusan mendaftar ulang perangkat setiap kali server booting.
• Penempatan Label Traefik: Label diletakkan pada service warp-gw, bukan pada 9router. Karena 9router tidak memiliki IP Docker mandiri, meletakkan label pada 9router akan membuat Traefik bingung mencari endpoint backend.

Hasil Pengujian dan Validasi Empiris

Setelah konfigurasi dijalankan dengan docker compose up -d, kami melakukan serangkaian verifikasi ketat untuk membuktikan isolasi jaringan berjalan 100% akurat:

1. Verifikasi Status Koneksi WARP

Memeriksa status daemon di dalam kontainer gateway:

$ docker exec 9router-warp-gw warp-cli status
Status update: Connected
Network: healthy

2. Pengujian Egress IP (9Router vs Host Server)

Kami membandingkan IP publik yang terbaca dari dalam kontainer 9Router dan dari shell host server:

# Periksa outbound dari dalam 9Router
$ docker exec 9router wget -qO- https://www.cloudflare.com/cdn-cgi/trace
ip=2a09:bac1:xxxx:xxxx::xxxx
warp=on



# Periksa outbound dari host VPS
$ curl -s https://ifconfig.me/ip
203.0.113.50 (IP Asli Server)

Hasil menunjukkan bahwa trafik dari 9Router keluar melalui jaringan Anycast Cloudflare dengan status warp=on, sementara host VPS tetap menggunakan IP publik aslinya.

3. Verifikasi Container Lain di Server

Kontainer lain yang berjalan di server yang sama (seperti agen otomasi dan instance web) diuji secara paralel:

$ docker exec other-app-container curl -s https://ifconfig.me/ip
203.0.113.50 (IP Asli Server)

Hal ini mengonfirmasi bahwa tidak terjadi kebocoran perutean (route leaking) ke kontainer tetangga.

4. Verifikasi Inbound Reverse Proxy Traefik

Permintaan HTTPS dari jaringan internet publik dilakukan ke domain target:

$ curl -I https://9router.example.com
HTTP/2 307 
location: /dashboard
server: traefik

Traefik berhasil meneruskan trafik ke port 20128 di dalam namespace gateway tanpa mengalami masalah perutean asimetris.

Panduan Troubleshooting Cepat

• Traefik Mengembalikan Error 502 Bad Gateway: Pastikan label Traefik tidak berada di servis 9router, melainkan di warp-gw. Periksa juga apakah port load balancer pada label sesuai dengan port aplikasi (20128).
• Kontainer WARP Gagal Terhubung (CrashLoop): Cek log dengan docker logs 9router-warp-gw. Jika terdapat pesan error terkait nftables atau rtnetlink, pastikan flag cap_add: [NET_ADMIN] dan sysctl IPv6 telah dideklarasikan dengan benar.
• Pergantian Kunci Registrasi: Selalu gunakan Docker volume untuk direktori /var/lib/cloudflare-warp agar perangkat tidak terdaftar berulang kali yang dapat memicu limit perangkat gratis Cloudflare.

Kesimpulan

Keberhasilan mengisolasi lalu lintas jaringan pada tingkat kontainer membuktikan pentingnya kontrol infrastruktur mandiri demi efisiensi jangka panjang. Ketika tim mulai melangkah melampaui ketergantungan solusi instan pihak ketiga, adopsi Arsitektur Modern Management Usaha: Menghapus Friksi Operasional Skala Menengah Lewat Otomasi Sistem Terintegrasi menjadi kunci memangkas biaya koordinasi serta menjaga skalabilitas proses bisnis.

Memisahkan perutean jaringan keluar untuk aplikasi spesifik tidak harus mengorbankan stabilitas server atau merusak tatanan reverse proxy produksi. Dengan memanfaatkan arsitektur shared network namespace di Docker Compose, Cloudflare WARP dapat difungsikan secara presisi sebagai gateway egress khusus untuk 9Router—menghadirkan privasi dan keandalan tingkat tinggi tanpa kompromi.

FAQ

Referensi

• Cloudflare WARP Official Documentation
• Traefik Docker Provider Documentation
• Docker Compose Specification: Network Mode