Laporan Kerja 7–8 Juli 2026 — Perbaikan & Eksposur Layanan

Kredensial Diredaksi

Halaman ini dipublikasikan di internet. Semua kredensial (passphrase, password, private key, token) yang muncul dalam sesi kerja asli sengaja tidak disertakan di sini — hanya fakta teknis, langkah perbaikan, dan hasil verifikasi. Kredensial lengkap tersimpan terpisah secara aman (lihat laporan kerja internal, tidak dipublikasikan).

Ringkasan

Sesi kerja ini mencakup investigasi dan perbaikan pada cluster oneKE, mencakup tiga area utama:

  1. WireGuard VNF — bug penamaan variabel yang menyebabkan key WireGuard di-generate ulang acak setiap restart, sehingga tunnel tidak pernah berhasil handshake.
  2. Longhorn UI — eksposur ke domain dengan sertifikat trusted + web security.
  3. Kubernetes Dashboard — eksposur ke domain dengan sertifikat trusted.

WireGuard — Investigasi & Perbaikan

Temuan

Interface wg0 berjalan normal secara struktural (firewall ACCEPT, port listening), namun kelima peer menunjukkan latest handshake = 0 — kontras dengan laporan 6 Juli yang mencatat Peer 0 pernah berhasil handshake. Ini mengindikasikan tunnel rusak kembali setelah laporan sebelumnya dibuat (kemungkinan akibat restart/re-context service).

Root Cause

File /etc/one-appliance/service.d/VRouter/WireGuard/main.rb baris 100 salah membaca nama environment variable:

VM_ID = env :VM_ID, nil    # SALAH — variabel context OpenNebula bernama "VMID" (tanpa underscore)

Karena VM ini adalah VNF oneKE (Service VM biasa, bukan resource Virtual Router asli), kode seharusnya fallback ke ID VM sendiri via variabel context VMID — tapi salah nama variabel membuat fallback ini selalu gagal. Akibatnya, setiap restart service one-wg, seluruh key WireGuard (server + 5 peer) di-generate ulang secara acak, dan config baru gagal dipublish ke OneGate — sehingga peer di sisi server tidak pernah cocok dengan klien manapun.

Modul lain pada appliance yang sama (Keepalived/main.rb) menggunakan nama variabel yang benar (env(:VMID, nil)), mengonfirmasi ini adalah bug/typo pada komponen WireGuard secara spesifik.

Perbaikan

Langkah Detail
Backup main.rb.bak-20260708
Fix Baris 100 diubah menjadi VM_ID = env :VMID, nil
Restart rc-service one-wg restart (2× untuk uji idempotensi)

Hasil: Log menunjukkan "Using configuration found in VM 22" (bukan lagi "Generating a new configuration"), dan public key server tetap konsisten pada 2 kali restart berturut-turut — konfirmasi config kini stabil dan tersimpan permanen di OneGate user-template VM 22.

Longhorn UI — Eksposur HTTPS & Web Security

Kondisi Awal

Ditemukan 4 objek routing yang saling konflik untuk host oneke-longhorn.ums.id (hasil beberapa percobaan sebelumnya): 1 K8s Ingress + 3 Traefik IngressRoute, dengan aturan tumpang tindih di entryPoint web/websecure. HTTP berhasil load UI, tapi HTTPS malah redirect ke path yang salah.

Tindakan

  1. Hapus 3 IngressRoute + 1 Middleware yang konflik.
  2. Install cert-manager v1.20.3 via Helm.
  3. Buat ClusterIssuer untuk Let's Encrypt (ACME HTTP-01).
  4. Buat 1 Ingress bersih: oneke-longhorn-ingress → longhorn-frontend:80.
  5. Bug ditemukan & diperbaiki: ingressClassName: traefik tidak match dengan nama resource IngressClass yang sebenarnya (one-traefik) → Traefik mengabaikan ingress sepenuhnya. Dikoreksi ke one-traefik.

Hasil: Sertifikat Let's Encrypt berhasil diterbitkan, berlaku s.d. 5 Oktober 2026, auto-renew oleh cert-manager.

Web Security

Atas permintaan Admin, ditambahkan 2 lapis proteksi tambahan:

  • IP Whitelist — diterapkan di level HAProxy (VNF), bukan Traefik/K8s. Ini karena HAProxy melakukan SNAT: semua koneksi yang diteruskan ke backend tampak berasal dari IP internal 10.0.0.1, bukan IP publik client asli — sehingga pembatasan IP di level Traefik tidak akan efektif. Solusinya adalah ACL berbasis SNI pada frontend lb2_443 di /etc/haproxy/servers.cfg, hanya mengizinkan IP admin yang terdaftar.
  • Basic Auth — via Traefik Middleware (kredensial tidak dipublikasikan di sini).
  • Redirect HTTP → HTTPS — memastikan akses plain HTTP selalu di-redirect permanen (308).

Verifikasi: HTTP → 308 redirect; HTTPS tanpa kredensial → 401; HTTPS + kredensial benar (dari IP whitelisted) → 200 OK; HTTPS + kredensial salah → 401.

Migrasi ke Path-Based Routing (8 Juli 2026, sesi lanjutan)

Sama seperti Dashboard, Longhorn UI dipindahkan ke https://oneke.ums.id/longhorn/ — domain lama tetap ada, hanya redirect 301.

Trade-off keamanan: IP whitelist hilang

Keputusan sadar bersama Admin: IP whitelist Longhorn bekerja berdasarkan SNI (nama domain) di level HAProxy — begitu pindah ke path bersama di oneke.ums.id, HAProxy tidak bisa lagi membedakan berdasarkan path (SNI cuma tahu domain, bukan URL). IP whitelist untuk Longhorn dihapus, Basic Auth tetap dipertahankan sebagai satu-satunya lapis proteksi. Menariknya, saat pengecekan ditemukan ACL IP whitelist ini sudah hilang duluan dari servers.cfg — kena dampak insiden revert yang sama dengan Dashboard (lihat Errata).

Keuntungan: Longhorn ternyata sudah punya dukungan resmi untuk path /longhorn dari Helm chart vendornya sendiri (IngressRoute longhorn-frontend dengan middleware redirect-longhorn-frontend + rewrite-longhorn-frontend) — tinggal ditambahkan entryPoint websecure, tls, dan middleware longhorn-basicauth ke resource yang sudah ada.

Bug kedua: Traefik priority berbasis panjang rule, bukan spesifisitas path

Setelah dipatch, /longhorn/ malah menampilkan halaman demo-app (404 nginx), bukan Longhorn. Root cause: Traefik menghitung priority router secara default dari panjang string rule, bukan spesifisitas path. Rule Longhorn (PathPrefix('/longhorn') saja, tanpa Host) mendapat priority 23 — lebih rendah dari rule demo-app (Host('oneke.ums.id') && PathPrefix('/'), priority 39) karena string rule-nya lebih panjang (walau path-nya jelas kurang spesifik). Akibatnya trafik /longhorn/ "dicuri" oleh ingress root. Solusi: set priority: 100 eksplisit pada route Longhorn. Berlaku juga untuk kasus serupa di masa depan — kapan pun path baru ditambahkan berdampingan dengan ingress root/wildcard, cek priority computed via Traefik API (/api/http/routers), jangan asumsikan path lebih spesifik otomatis menang.

Kubernetes Dashboard — Eksposur HTTPS

Kondisi Awal

Ditemukan pekerjaan sebelumnya yang sudah menyiapkan DNS, sertifikat Let's Encrypt via acme.sh, ACL SNI HAProxy, dan config nginx — namun nginx berstatus stopped dan config-nya salah arah (proxy ke 127.0.0.1:8443 yang tidak ada apa pun di situ).

Tindakan

  1. Nonaktifkan config nginx basi yang berpotensi bentrok port 80 dengan HAProxy.
  2. Perbaiki oneke-dashboard.conf: listen 127.0.0.1:8443 ssl (lokal saja), proxy_pass ke upstream 4 worker NodePort (10.0.0.3-6:32767), proxy_ssl_verify off (backend self-signed).
  3. Update HAProxy dashboard_custom_backend: dari langsung ke 4 worker → ke nginx lokal (127.0.0.1:8443) yang meng-terminate TLS dengan sertifikat Let's Encrypt asli.
  4. Enable & start nginx, reload HAProxy (tanpa downtime).

Hasil: Sertifikat Let's Encrypt berhasil disajikan, berlaku s.d. 5 Oktober 2026.

Belum Diproteksi

Atas keputusan Admin, Dashboard belum diberi IP whitelist/Basic Auth tambahan — hanya mengandalkan login token Kubernetes bawaan (ServiceAccount admin-user dengan ClusterRoleBinding cluster-admin). Pola proteksi yang sama seperti Longhorn tersedia untuk diterapkan kapan saja bila diperlukan.

Migrasi ke Path-Based Routing (8 Juli 2026, sesi lanjutan)

Domain oneke-dashboard.ums.id sempat gagal diakses (menyajikan self-signed certificate, bukan Let's Encrypt) — root cause: HAProxy dashboard_custom_backend ternyata sudah kembali mengarah langsung ke NodePort worker (bypass nginx lokal), kemungkinan tertimpa oleh aktivitas sesi kerja lama yang belum dibersihkan (lihat Errata).

Alih-alih memperbaiki jalur lama, Dashboard dipindahkan ke https://oneke.ums.id/oneke-dashboard/ — path baru di domain utama, memakai arsitektur yang jauh lebih sederhana dan tidak lagi bergantung pada nginx+HAProxy di level VNF:

  • ServersTransport Traefik dengan insecureSkipVerify: true (backend Dashboard pakai sertifikat self-signed sendiri).
  • IngressRoute dengan PathPrefix('/oneke-dashboard'), middleware stripPrefix + redirect trailing-slash — reuse sertifikat oneke-root-tls yang sudah ada untuk oneke.ums.id.
  • Dashboard (Angular SPA) ternyata memakai relative path untuk semua aset (CSS/JS/gambar) — bekerja normal di subpath tanpa perlu rewrite khusus (berbeda dari kekhawatiran awal).

Domain lama oneke-dashboard.ums.id tidak dihapus — nginx lokal di VNF diubah untuk melakukan redirect 301 ke path baru, demi kompatibilitas mundur bagi siapa pun yang sudah menyimpan bookmark lama.

Bug HAProxy: ACL SNI perlu tcp-request content accept eksplisit

Saat memperbaiki jalur lama, ditemukan ACL req.ssl_sni tidak ter-commit meski pattern-nya match sempurna (diverifikasi lewat tcpdump — SNI diterima benar, show acl/show stat HAProxy juga menunjukkan konfigurasi termuat dan backend UP). Trafik tetap salah arah ke default_backend (Traefik). Solusi: tambahkan baris eksplisit tcp-request content accept if is_dashboard setelah definisi ACL — begitu ditambahkan, routing langsung benar. Kemungkinan perilaku spesifik HAProxy 2.6.17 terkait commit backend selama inspect-delay yang tidak terdokumentasi jelas.

Halaman Utama (oneke.ums.id) → demo-app

Sebagai tambahan, https://oneke.ums.id/ diarahkan ke aplikasi contoh (demo-app, nginx) via Ingress baru dengan sertifikat Let's Encrypt, dilengkapi tautan navigasi ke Longhorn UI dan Kubernetes Dashboard.

Backup & Rollback

File Lokasi (di VNF/cluster) Keterangan
WireGuard appliance script main.rb.bak-20260708 Sebelum fix VM_ID→VMID
HAProxy servers.cfg servers.cfg.bak-<timestamp> Sebelum penambahan ACL Longhorn & perubahan backend dashboard

Rekomendasi Tindak Lanjut

  1. Ganti password Basic Auth Longhorn agar tidak identik dengan kredensial SSH admin lain (prinsip: jangan reuse kredensial lintas sistem).
  2. Pertimbangkan proteksi tambahan untuk Kubernetes Dashboard (IP whitelist + Basic Auth).
  3. Rotasi token admin-user Dashboard secara berkala.
  4. Bersihkan file nginx basi di VNF yang sudah tidak relevan.
  5. Dokumentasikan runbook internal untuk arsitektur HAProxy TCP-passthrough + SNI-ACL ini, karena cukup non-standar.

Sesi kerja interaktif, 7–8 Juli 2026. Detail kredensial tersimpan terpisah secara aman, tidak dipublikasikan di halaman ini.