Remote Access & WireGuard (Laporan 6 Juli 2026)

Laporan Konfigurasi WireGuard & Remote Access · Infrastruktur: OneKE Kubernetes Service (Service ID 4) — HyperCX/OpenNebula, Cloud UMS · Tanggal pemeriksaan: 6 Juli 2026

Status per 8 Juli 2026

Laporan ini adalah snapshot per 6 Juli. Antara 6–7 Juli, service WireGuard sempat rusak kembali (bug baru, berbeda dari yang dilaporkan di sini) dan sudah diperbaiki lagi. Lihat Laporan Kerja 7–8 Juli dan Errata untuk kondisi terkini.

1. Topologi Virtual Machine

VM ID Nama Peran IP Publik IP Privat
22 vnf_0_(service_4) VNF / Gateway 103.226.174.229 10.0.0.1
23 master_0_(service_4) K8s Master — 10.0.0.2
24–27 worker_0..3_(service_4) K8s Worker — 10.0.0.3 – 10.0.0.6
28–30 storage_0..2_(service_4) Storage (Longhorn) — 10.0.0.7 – 10.0.0.9

2. Konfigurasi WireGuard (VM 22 / VNF)

Atribut Nilai
ONEAPP_VNF_WG_ENABLED YES
ONEAPP_VNF_WG_INTERFACE_IN eth1 (privat)
ONEAPP_VNF_WG_INTERFACE_OUT eth0 (publik)
ONEAPP_VNF_WG_LISTEN_PORT 51820
ONEAPP_VNF_WG_DEVICE wg0
ONEAPP_VNF_WG_SUBNET 169.254.33.0/24
ONEAPP_VNF_WG_PEERS 5

Status saat itu: SUDAH BENAR. Sebelumnya interface IN/OUT tertukar sehingga Endpoint & AllowedIPs pada peer config terbalik (endpoint mengarah ke IP privat, AllowedIPs mengarah ke subnet publik). Setelah perbaikan atribut dan pembersihan cache OneGate, konfigurasi ter-generate ulang dengan benar.

Contoh Peer Config (Peer 0) — hasil generate saat itu

Parameter Nilai
Address (client) 169.254.33.2/24
Endpoint (server) 103.226.174.229:51820
AllowedIPs 10.0.0.0/24
PrivateKey / PresharedKey (disembunyikan demi keamanan)

Verifikasi Live per 6 Juli (wg show di shell VM 22)

Peer Allowed IPs Endpoint aktif Handshake terakhir
Peer 0 169.254.33.2/32 103.226.174.25:55734 31 menit lalu (aktif, transfer data terjadi)
Peer 1 169.254.33.3/32 — belum pernah connect
Peer 2 169.254.33.4/32 — belum pernah connect
Peer 3 169.254.33.5/32 — belum pernah connect
Peer 4 169.254.33.6/32 — belum pernah connect

Tunnel WireGuard terkonfirmasi aktif dan berfungsi saat itu — sudah ada client (peer 0) yang berhasil melakukan handshake dan transfer data melalui VPN ini.

3. Konfigurasi Remote Access (SSH)

Parameter (sshd_config, VM 22) Nilai
PermitRootLogin without-password (hanya via key)
PasswordAuthentication no
PubkeyAuthentication yes (default)
/root/.ssh/authorized_keys 4 public key terdaftar
/root/.ssh/known_hosts 10.0.0.2 (master_0) tercatat

Jalur akses yang tersedia:

  • Jump host via VNF: bash ssh -J root@103.226.174.229 root@10.0.0.2 # ke master ssh -J root@103.226.174.229 root@10.0.0.3 # ke worker-0 (pola sama untuk 10.0.0.4-.6) ssh -J root@103.226.174.229 root@10.0.0.7 # ke storage-0 (pola sama untuk 10.0.0.8-.9)
  • Langsung via WireGuard VPN: setelah peer config (169.254.33.x) diaktifkan di mesin admin, node internal (10.0.0.0/24) dapat diakses langsung tanpa jump host.

Verifikasi cluster dari master:

kubectl get nodes -o wide
# harus tampil 1 master + 4 worker + 3 storage, semua STATUS = Ready

Catatan terbuka (dibiarkan untuk sementara)

Saat boot, muncul error kosmetik pada eth1 VM 22: "Error: Nexthop has invalid gateway" karena baris gateway 10.0.0.1 pada /etc/network/interfaces menunjuk ke alamat interface itu sendiri. Interface tetap berhasil UP dan berfungsi normal — ini tidak mengganggu WireGuard maupun SSH.

B.8 — Akses Longhorn Web UI (metode lama)

Traefik aktif pada deployment ini (berbeda dari rencana awal) — metode resmi vendor untuk expose Longhorn UI memang berbasis Traefik IngressRoute, sehingga jalur ini bisa langsung dipakai.

kubectl -n longhorn-system get svc longhorn-frontend
kubectl apply -f ingressroute_longhorn-frontend.yml

Akses via browser: http://103.226.174.229/longhorn

Direkomendasikan menambahkan reverse-proxy nginx di VNF dengan HTTPS + basic-auth pada port terpisah (mis. 7443) sebelum dipakai secara operasional.

Update 8 Juli 2026

Metode di atas sudah digantikan dengan pendekatan berbasis domain + sertifikat Let's Encrypt trusted: https://oneke-longhorn.ums.id/, lengkap dengan IP whitelist + Basic Auth. Lihat Laporan Kerja 7–8 Juli.

B.9 — Deploy & Akses Kubernetes Dashboard (metode lama)

Tambahkan konfigurasi HAProxy tambahan di VNF untuk expose NodePort Dashboard (32767) lewat IP publik pada port pilihan (mis. 8443), diarahkan ke ke-4 worker (10.0.0.3–.6) untuk redundansi, lalu restart one-haproxy.

Di master: pasang Kubernetes Dashboard via Helm (chart 7.5.0, kompatibel RKE2 1.29), lalu ubah service kong-proxy menjadi NodePort 32767:

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \
  --version 7.5.0 --namespace kubernetes-dashboard --create-namespace

Akses via https://103.226.174.229:8443, login memakai bearer token dari ServiceAccount admin-user + ClusterRoleBinding cluster-admin.

Token Dashboard

Token Dashboard setara akses admin penuh ke cluster — tidak disertakan dalam dokumen ini, simpan terpisah dengan aman.

Update 8 Juli 2026

Dashboard sekarang diakses via domain + sertifikat Let's Encrypt trusted: https://oneke-dashboard.ums.id/. Metode IP:port (8443) di atas sudah digantikan. Lihat Laporan Kerja 7–8 Juli.

B.10 — Catatan Keamanan Tambahan

Dengan WireGuard aktif dan beberapa port publik terbuka (80/443 ingress, 8443 dashboard, opsional 7443 Longhorn UI), disarankan meninjau iptables hardening di node VNF untuk membatasi akses hanya ke port yang benar-benar dipakai (SSH, DNS, WireGuard, dan port layanan yang aktif saja).

B.11 — Redundansi VNF (2 Node): VRRP Aktif & Teruji, HAProxy Belum (17–18 Juli 2026)

Menyusul ekspansi VNF dari 1 → 2 node pada Perubahan Konfigurasi A.8 (node baru vnf_1, VM 35), diperiksa langsung (shell kedua VM) apakah redundansi load balancer sudah benar-benar berjalan. Pemeriksaan awal (17 Juli, tabel di bawah "kondisi awal") menemukan VRRP terpasang tapi tidak aktif; pada sesi lanjutan, VRRP dikonfigurasi & diuji failover sungguhan (bukan simulasi), sekaligus ditemukan bahwa HAProxy di vnf_1 ternyata belum pernah dijalankan sama sekali — koreksi dari catatan sebelumnya yang keliru mengasumsikan simetris.

Kondisi Awal (temuan 17 Juli, sebelum konfigurasi)

vnf_0 (VM 22) vnf_1 (VM 35)
IP Publik (eth0) 103.226.174.229 103.226.174.225
IP Privat (eth1) 10.0.0.1 10.0.0.14
HAProxy Aktif Ternyata tidak berjalan (rc-service haproxy status → stopped) — baru ketahuan saat percobaan konfigurasi VIP, bukan saat pemeriksaan awal
keepalived (VRRP) Aktif, priority 100, virtual_ipaddress {} kosong Aktif, priority 100 (sama), virtual_ipaddress {} kosong

Tidak ada VIP bersama, priority kedua node sama, dan DNS oneke.ums.id hanya menunjuk ke 103.226.174.229 — redundansi murni provisioning, belum fungsional (detail argumen lengkap ada di riwayat versi dokumen ini).

Konfigurasi yang Diterapkan (18 Juli 2026)

Karena akses ke context variable resmi OpenNebula (ONEAPP_VROUTER_ETH0_VIP0 / ONEAPP_VROUTER_ETH1_VIP0 — mekanisme resmi appliance VRouter untuk fitur ini) tidak tersedia tanpa akses oned/frontend OpenNebula (sudah dicoba lewat onegate vm update + one-context-run, terbukti tidak terpropagasi ke context.sh), konfigurasi diterapkan manual langsung ke /etc/keepalived/conf.d/vrrp.conf di kedua node (backup file asli disimpan sebagai vrrp.conf.bak-<timestamp>):

Parameter vnf_0 (10.0.0.1) vnf_1 (10.0.0.14)
Priority 150 (MASTER pilihan utama) 100 (BACKUP)
VIP privat (eth1) 10.0.0.20/24 sama
VIP publik (eth0) 103.226.174.226/24 sama
virtual_router_id 5 (tidak berubah) 5

net.ipv4.ip_nonlocal_bind=1 juga diaktifkan (persisten via /etc/sysctl.conf) di kedua node, prasyarat agar HAProxy nantinya bisa bind ke VIP yang belum tentu ada di interface lokal. HAProxy di vnf_1 (yang ternyata tidak jalan) dinyalakan (rc-service one-haproxy start).

Hasil Uji Failover — Layer VRRP: ✅ Berhasil Penuh

Diuji nyata (bukan simulasi): keepalived di vnf_0 dihentikan paksa, lalu dihidupkan lagi.

Tahap VIP privat (10.0.0.20) VIP publik (103.226.174.226)
Normal (vnf_0 MASTER) Dipegang vnf_0 Dipegang vnf_0
vnf_0 dimatikan Berpindah ke vnf_1 dalam <4 detik, ping dari master node 0% loss Berpindah ke vnf_1, ping dari luar 0% loss
vnf_0 dihidupkan lagi Preemption — direbut kembali vnf_0, vnf_1 lepas bersih Preemption — sama, 0% loss selama transisi

Kesimpulan layer VRRP: solid. Kedua VIP (publik & privat) berpindah bersamaan (satu vrrp_sync_group), preemption bekerja, tidak ada packet loss pada lapisan IP.

Hasil Uji Failover — Layer HAProxy: ❌ Belum Reliable

HAProxy tidak konsisten ikut pindah ke VIP — root cause ditemukan

HAProxy di kedua node bind ke IP statis masing-masing, bukan ke VIP — dicoba tambal manual (tambah baris bind <VIP>:<port> di servers.cfg) dan awalnya berhasil (HTTP 200 lewat VIP). Namun saat diuji failover sungguhan, request HTTP lewat VIP publik gagal (connection refused) justru pada saat MASTER mati.

Akar masalah: appliance VRouter OpenNebula (/etc/one-appliance/service.d/VRouter/HAProxy/) menjalankan daemon (one-haproxy) yang me-render ulang servers.cfg dari ONEGATE/context data setiap kali ada perubahan backend dan setiap kali servicenya di-restart — termasuk dipicu oleh transisi state VRRP (lewat keepalived → vrrp_notify_fifo → service one-failover). Karena proses render ulang itu membaca VIP dari context variable ETH0_VROUTER_IP/ONEAPP_VROUTER_ETH0_VIP0 yang kosong (masalah akses oned yang sama seperti di atas), setiap render ulang mengembalikan bind ke IP statis — persis pada momen failover, saat VIP paling dibutuhkan.

Tambalan manual ke servers.cfg karenanya tidak reliable: bisa bertahan selama tidak ada restart/render ulang, tapi dijamin hilang tepat saat terjadi failover sungguhan.

Dampak ke produksi: tidak ada. oneke.ums.id tetap menunjuk ke IP statis 103.226.174.229 (bukan VIP), dan dikonfirmasi tetap HTTP 200 sepanjang seluruh pengujian di atas — perubahan ini murni menambah kapabilitas baru (VIP) di samping konfigurasi lama, tidak menggantikannya.

Status & Keputusan (18 Juli 2026)

Keputusan: cukupkan di layer VRRP, JANGAN arahkan DNS ke VIP dulu

VRRP+VIP dibiarkan aktif (harmless, dan bermanfaat untuk kebutuhan internal/masa depan), tapi:

  • DNS oneke.ums.id TETAP di IP statis 103.226.174.229 — jangan diarahkan ke VIP sampai HAProxy benar-benar reliable ikut failover.
  • Jangan mengandalkan HAProxy ikut pindah saat vnf_0 mati — service K8s API/ingress akan tetap down sampai vnf_0 pulih, meskipun VIP-nya sendiri sudah dipegang vnf_1.
  • Perbaikan permanen memerlukan akses oned/frontend OpenNebula untuk set ONEAPP_VROUTER_ETH0_VIP0 / ONEAPP_VROUTER_ETH1_VIP0 di level context VM secara resmi — dengan itu, mekanisme render-ulang appliance yang sekarang jadi masalah justru akan otomatis menghasilkan bind yang benar setiap kali (termasuk saat failover).

Referensi Konfigurasi (untuk siapa pun yang melanjutkan)

  • Backup config asli: /etc/keepalived/conf.d/vrrp.conf.bak-* dan /etc/haproxy/servers.cfg.bak-* di kedua VNF.
  • VIP privat 10.0.0.20, VIP publik 103.226.174.226 — keduanya sudah diverifikasi kosong/tidak terpakai sebelum dipasang.
  • Modul appliance terkait: /etc/one-appliance/service.d/VRouter/Keepalived/main.rb (baca ETH<N>_VROUTER_IP / ONEAPP_VROUTER_ETH<N>_VIP<M>) dan /etc/one-appliance/service.d/VRouter/HAProxy/execute.rb (loop ONEAPP_VNF_HAPROXY_ONEGATE_ENABLED, refresh 30 detik, render ulang servers.cfg dari detect_vips — kosong selama context var di atas tidak diset).

B.12 — Referensi

  • Vendor: wiki.virtalus.com — OneKE Service (Kubernetes)
  • Internal: Laporan Implementasi OneKE — Bab X, SEKSI-01/02/03

Dokumen internal Cloud UMS — dibuat otomatis berdasarkan pemeriksaan langsung terhadap atribut VM (HyperCX UI) dan shell VM 22 (read-only, tanpa modifikasi sistem). Universitas Muhammadiyah Surakarta — 2026. Sumber: sispada.ums.id/reports/oneke/