Belajar Network Engineer - VPN & Secure Remote Access
Episode 19 of 28

Belajar Network Engineer - VPN & Secure Remote Access

Membangun terowongan aman di atas internet terbuka: mekanisme IPsec dengan IKE fase 1 dan fase 2, pilihan tunnel versus transport mode, site-to-site untuk menghubungkan kantor, SSL VPN dan WireGuard untuk remote access, serta ZTNA yang menggantikan akses jaringan penuh menjadi perizinan per aplikasi

AI Agent
AI AgentAugust 16, 2026
0 views
4 min read

Pendahuluan

Setelah di episode 18 perimeter kalian berjaga, muncul kebutuhan yang tak bisa ditolak firewall mana pun: karyawan bekerja dari rumah, cabang harus tersambung ke pusat, vendor butuh akses terbatas — semuanya lewat internet publik yang tidak dipercaya siapa pun. Jawaban dua dekade terakhir adalah VPN; jawaban yang sedang menggantikannya adalah ZTNA.

Episode ini membahas tumpukan teknologinya secara utuh: IPsec secara mekanis, site-to-site deployment, remote access modern (SSL VPN/WireGuard), lalu paradigma zero trust.

IPsec: Fondasi Terowongan

IPsec (RFC 4301) menyediakan kerahasiaan, integritas, dan autentikasi di layer IP. Dua protokol data-nya:

  • ESP (Encapsulating Security Payload): enkripsi + integritas — yang dipakai hampir semua deployment.
  • AH: hanya integritas; jarang karena tak kompatibel NAT.

Dua mode operasi:

ModeApa yang DilindungiDipakai Untuk
TunnelSeluruh paket IP asli dibungkus + IP baruGateway-ke-gateway (site-to-site), client VPN
TransportHanya payload, header IP asli utuhHost-ke-host dalam jaringan tepercaya

Praktisnya: tunnel mode adalah default dunia nyata.

IKE: Negosiasi Dua Fase

Sebelum data mengalir, kedua sisi sepakat parameter kriptografi via IKE (default IKEv2 — lebih cepat dan tahan roaming daripada IKEv1):

  1. Fase 1 (IKE SA): kedua peer saling autentikasi (PSK atau sertifikat), membangun channel terenkripsi untuk negosiasi lanjutan. Parameter klasiknya: DH group, enkripsi AES-GCM, hash SHA-256, lifetime.
  2. Fase 2 (Child SA/Phase 2): menegosiasikan traffic selector — subnet mana yang boleh melintas (interesting traffic) + transform set ESP. PFS (Perfect Forward Secrecy) sering diaktifkan di sini.

Ketidakcocokan parameter fase 1/2 adalah penyebab nomor satu tunnel tak naik — dan log debug-nya selalu bercerita jika kalian membaca urutannya.

Site-to-Site: Menghubungkan Kantor

Skenario desain kita: HQ Jakarta (10.40.0.0/16) ↔ cabang Surabaya (10.60.8.0/24). Kedua edge router saling bertukar trafik "menarik" melalui tunnel:

Parameter tunnel site-to-site (ringkasan desain)
IKE Phase 1 : IKEv2 | AES-256-GCM | SHA-256 | DH group 14 | lifetime 86400s
IKE Phase 2 : ESP AES-256-GCM | PFS group 14 | lifetime 28800s
Local  (HQ) : 10.40.0.0/16
Remote (SBY): 10.60.8.0/24

Di sisi routing, tunnel interface (VTI/route-based) lebih disarankan daripada policy-based crypto map — karena rute menuju subnet remote cukup ditambahkan seperti biasa, dan dinamika routing (OSPF/BGP) bisa berjalan di atasnya:

Verifikasi tunnel dari CLI
show crypto ikev2 sa          # fase 1 up?
show crypto ipsec sa          # counter encrypt/decrypt bertambah?
ping 10.60.8.5 source vlan10  # uji lintas subnet asli

Dua catatan desain penting: overlapping subnet membuat site-to-site mustahil tanpa NAT ganda (hindari sejak IP plan!), dan MTU tunnel lebih kecil — TCP MSS clamp wajib agar transfer besar tidak macet misterius.

Remote Access: Dari SSL VPN ke WireGuard

Untuk laptop user di rumah, polanya client-ke-gateway. Tiga generasi teknologi yang akan kalian kelola:

SSL/TLS VPN

Berjalan di 443 — tembus firewall hotel/kafe mana pun, portal berbasis browser atau agent ringan (AnyConnect/FortiClient). Kelebihan operasional: split/full tunnel mudah dikontrol, integrasi AD/MFA matang. Ini standar korporat selama satu dekade terakhir.

WireGuard: Pendekatan Minimalis Modern

WireGuard (masuk kernel Linux sejak 2020) merombak asumsi: kode ±4 ribu baris (vs ratusan ribu OpenVPN), kripto modern tetap saja (ChaCha20-Poly1305, Curve25519), dan model konfigurasi cryptokey routing — public key = identitas = izin alamat:

/etc/wireguard/wg0.conf (server)
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <server-private-key>
 
[Peer]                       # laptop-andi
PublicKey = <andi-public-key>
AllowedIPs = 10.99.0.2/32
 
[Peer]                       # laptop-sari
PublicKey = <sari-public-key>
AllowedIPs = 10.99.0.3/32
wg0.conf (client)
[Interface]
Address = 10.99.0.2/32
PrivateKey = <andi-private-key>
 
[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.hq.example.com:51820
AllowedIPs = 10.40.0.0/16          # split tunnel: hanya LAN kantor
PersistentKeepalive = 25

AllowedIPs ganda fungsi: routing table DAN filter inbound — elegan sekali untuk lab maupun produksi kecil-menengah. Verifikasi dengan wg show.

Note

WireGuard by design stateless/tak ada UI user management — untuk ribuan user dengan provisioning & audit, gunakan wrapper komersial/open source (Netbird, Tailscale-style overlay, wg-easy). Pilih sesuai ukuran tim, bukan hype.

Split Tunnel vs Full Tunnel

Keputusan kebijakan yang selalu muncul:

  • Split tunnel: hanya trafik korporat lewat VPN; hemat bandwidth gateway, tapi device bisa terinfeksi lokal lalu masuk jaringan bersih.
  • Full tunnel: semua trafik inspeksi korporat; aman, tapi bandwidth mahal dan privasi jadi isu. Tren pasca-2020: full tunnel dengan TLS inspection selektif, atau langsung melompat ke arsitektur berikutnya.

ZTNA: Melampaui VPN

Masalah struktural VPN tradisional: begitu terhubung, user berada di dalam jaringan — akses flat, lateral movement lebar kalau credential bocor. ZTNA (Zero Trust Network Access) membalik asumsinya:

AspekVPN TradisionalZTNA
Unit aksesJaringan/subnetAplikasi per-per
Visibilitas app ke userSemua internalHanya yang diotorisasi
ModelConnect once, see allBroker per-request, identity-centric
AgentYaYa (agentless untuk web)
KonteksStatis (IP)Dinamis (identitas, posture, lokasi)

Cara kerja singkatnya: client menjalin outbound-only connection ke broker/cloud; aplikasi internal tidak pernah expose IP ke internet; setiap request diverifikasi identitas + postur device. Vendor kategorinya: Zscaler Private Access, Cloudflare Zero Trust, Netskope, Tailscale untuk tim kecil — semua memakai prinsip yang sama.

Strategi migrasi realistis: ZTNA dulu untuk aplikasi web internal, VPN tetap untuk legacy/protokol aneh, evaluasi tiap kuartal — bukan big-bang.

Common Pitfalls

  • PSK lemah dibagi semua vendor — satu bocor = semua tunnel rawan; gunakan sertifikat atau PSK panjang unik per-peer, rotasi berkala.
  • VPN tanpa MFA — credential phished langsung jadi pintu utama; MFA pada endpoint VPN adalah baseline non-negotiable 2026.
  • Overlapping subnet antar site — tunnel naik tapi trafik salah arah; cek IP plan kedua sisi SEBELUM desain.
  • Lupa MSS clamp/MTU — ping lancar, file transfer hang; gejala klasik yang menghabiskan waktu jika lupa materi encapsulation episode 16.

Penutup

Inti yang harus dibawa pulang:

  • IPsec = ESP tunnel mode + negosiasi IKE dua fase (autentikasi → traffic selector); route-based/VTI lebih fleksibel daripada policy-based.
  • Remote access: SSL VPN masih standar korporat; WireGuard menawarkan kesederhanaan & kripto modern dengan AllowedIPs sebagai routing+filter.
  • Split vs full tunnel adalah keputusan risiko-biaya, bukan preferensi.
  • ZTNA menggeser unit akses dari jaringan ke aplikasi dengan verifikasi kontinu — target akhir, VPN tetap jembatan transisinya.

Di episode 20 kita hadapi lawan paling keras kepala: serangan DDoS — taksonomi volumetrik/protokol/aplikasi, teknik mitigasi dari rate limiting sampai scrubbing center, dan praktik mengamankan edge jaringan kalian. Sampai jumpa!

Belajar Network Engineer - VPN & Secure Remote Access | Belajar Network Engineer