Merancang Jaringan yang Tahan Banting

Dari LAN kantor kecil, cabang, remote worker, sampai hybrid cloud — tanpa jargon kosong.

IN THIS STORY

Masalah nyata di belakang "internet lemot" OSI bukan teori: di layer mana kamu debug VLAN dan segmentasi yang masuk akal Routing: statis, dinamis, dan bocor ke internet VPN site-to-site vs remote access Firewall stateful, NGFW, dan ACL Hybrid cloud: menyambungkan VPC ke kantor Troubleshooting nyata FAQ

Masalah nyata di belakang "internet lemot"

Kamu tidak pernah ditelepon karena "layer 3 bermasalah". Kamu ditelepon karena kasir di toko tidak bisa kirim struk, atau tim accounting tiba-tiba tidak lihat server pajak. Di situlah jaringan dimulai: bukan dengan topologi, tapi dengan siapa yang tidak bisa ngomong dengan siapa.

Skenario klasik kecil: warung kopi dengan 1 router WiFi dari provider, 5 karyawan, 1 printer, dan 1 CCTV. Begitu ada 30 pelanggan pakai WiFi tamu, kasir mulai lemot. Kenapa? Karena semuanya di satu broadcast domain. Broadcast dari DHCP, mDNS (printer Apple), dan ARP menyebar ke semua port. Switch murah tidak memisahkan itu. Solusinya bukan beli router lebih mahal, tapi pisahkan tamu dari operasional.

Di enterprise, bentuknya lain tapi akarnya sama: VLAN tidak didesain, lalu server IoT nyempil di VLAN staff, dan saat IoT itu kena exploit, pelaku sudah di dalam segmen yang sama dengan domain controller. Segmentasi buruk adalah penyebab mayoritas penyebaran lateral yang saya tangani.

Mengapa ini penting

Setiap keluhan "lemot" atau "putus" adalah gejala dari satu keputusan desain yang salah: siapa boleh bicara dengan siapa, di layer berapa, dan apa batasnya. Jangan obati gejala dengan bandwidth; obati topologinya.

OSI bukan teori: di layer mana kamu debug

Saya jarang menyebut "layer 4" di diskusi, tapi saat debug saya selalu kerjakan berurutan. Jika kamu langsung curiga DNS (layer 7) padahal kabel putus (layer 1), kamu buang 30 menit. Urutan debug yang saya pakai:

• Layer 1 (fisik): lampu link nyala? Kabel rusak? SFP mismatch?

• Layer 2 (data link): MAC belajar? VLAN tag benar? Spanning-tree blokir port?

• Layer 3 (network): IP dapat? Gateway bisa di-ping? Routing ada?

• Layer 4 (transport): port tujuan terbuka? Firewall drop?

• Layer 7 (aplikasi): baru di sini curiga protokol/app.

Diagram OSI — di mana paket dicek

7 Application (HTTP, DNS, TLS) 6 Presentation (encoding) 5 Session (keepalive) 4 Transport (TCP/UDP port) — firewall utama 3 Network (IP, routing) — gateway & subnet 2 Data Link (VLAN, MAC, STP) 1 Physical (kabel, SFP, lampu link)

Kesalahan umum

Curiga DNS sebelum cek kabel. Saya lihat teknisi reset router 3 kali padahal SFP tidak duduk. Mulai dari bawah.

VLAN dan segmentasi yang masuk akal

VLAN adalah cara membagi switch fisik jadi beberapa broadcast domain logis. Di MikroTik, Ubiquiti, Cisco, Juniper — konsepnya sama, perintahnya beda. Tanpa VLAN, CCTV 20 kamera dan laptop direktur ada di segmen sama; broadcast CCTV bisa makan 10% bandwidth switch kecil.

Desain yang saya pakai untuk kantor 50 orang:

• VLAN 10 — Staff (DHCP 10.10.10.0/24)

• VLAN 20 — Server (10.10.20.0/24, statis)

• VLAN 30 — WiFi tamu (terisolasi, hanya NAT ke internet)

• VLAN 40 — IoT/CCTV (hanya boleh ke NVR dan internet, tidak ke staff)

Topologi VLAN sederhana

Router L3 Switch Core Staff Server Tamu CCTV trunk 802.1Q

Inter-VLAN routing terjadi di router (atau switch L3). Di sini kamu pasang aturan: tamu tidak boleh ke 10.10.10.0/24 dan 10.10.20.0/24. Di pfSense/OPNsense ini mudah: buat alias, buat rule "block tamu to RFC1918". Di MikroTik, pakai /ip firewall filter dengan out-interface ke VLAN staff di-drop.

Kapan TIDAK pakai VLAN

Jika hanya 3 perangkat dan 1 user, jangan over-engineer. VLAN menambah kompleksitas debug. Tambahkan saat kamu punya >15 device atau perlu pisahkan traffic sensitif dari tamu.

Routing: statis, dinamis, dan kapan bocor ke internet

Routing statis cocok untuk topologi diam (kantor kecil, 1 gateway). Kamu tulis ip route add 10.20.0.0/24 via 10.10.20.1 dan lupa. Masalahnya: kalau link itu mati, tidak ada jalur cadangan kecuali kamu rancang. OSPF/BGP baru masuk saat ada banyak router atau multi-homed ISP.

Saya pernah lihat kantor dengan 2 ISP (ISP A utama, ISP B cadangan) tapi semua traffic tetap lewat A karena default route statis cuma satu. Saat A mati, B idle. Perbaikan: pakai recursive gateway check di MikroTik atau IP SLA + track di Cisco. Biar gateway berpindah otomatis.

Packet flow: client ke internet

Client Switch Router Firewall Net L2 L3 route filter egress

Warning

Jangan pasang BGP ke upstream kalau kamu tidak paham prefix filtering. Satu salah announce bisa bocor route ke internet dan kamu jadi penyebab hijack global.

VPN site-to-site vs remote access

Banyak yang mencampur dua ini. Site-to-site menyambungkan dua jaringan utuh: kantor pusat ke cabang, atau VPC ke data center lama. Remote access menyambungkan satu user (laptop) ke jaringan kantor. Bedakan dari awal, karena tools dan keamanannya beda.

Untuk site-to-site murah dan handal: WireGuard atau IPsec (strongSwan di Linux, built-in di MikroTik/Fortinet). WireGuard simpel — 1 file config, handshake cepat, overhead kecil. Tapi tidak ada user-auth bawaan; kamu kelola key per peer. IPsec lebih berat tapi punya integrasi vendor luas (Fortinet↔Cisco↔Juniper bicara IPsec dengan mudah).

VPN site-to-site: kantor ↔ cabang

Kantor Pusat Internet Cabang IPsec/WG tunnel IPsec/WG tunnel

Kapan TIDAK pakai site-to-site

Kalau cuma 2 orang WFH butuh akses file share, pasang OpenVPN/WireGuard remote access. Site-to-site ke rumah tiap karyawan itu overkill dan sulit diaudit.

Implementasi WireGuard sederhana di Linux:

# /etc/wireguard/wg0.conf (peer cabang)
[Interface]
Address = 10.99.0.2/24
PrivateKey = <private-cabang>

[Peer]
PublicKey = <public-pusat>
Endpoint = vpn.kantor.id:51820
AllowedIPs = 10.10.0.0/16
PersistentKeepalive = 25

Perhatikan AllowedIPs: di situlah kamu tentukan route apa yang lewat tunnel. Salah set (misal 0.0.0.0/0) malah jadi full tunnel dan traffic internet cabang ikut lewat pusat — lemot dan mungkin melanggar kebijakan.

Firewall stateful, NGFW, dan ACL

Firewall stateful (pfSense, Fortinet, iptables/nftables) melacak koneksi: balasan dari server dibolehkan karena merupakan bagian dari sesi yang dimulai dari dalam. ACL statis (daftar izin di switch L3) tidak punya state — hanya cek src/dst/IP/port. Untuk isolasi antar-VLAN, ACL cukup. Untuk internet edge, butuh stateful.

NGFW (Fortinet FortiGate, Palo Alto) menambah inspeksi DPI: bisa lihat TLS di-decrypt (kalau kamu pasang CA internal), blokir signature IPS, dan kenali aplikasi (bukan cuma port). Biayanya: lisensi mahal dan latency naik. Untuk klinik kecil, pfSense + Snort sudah cukup. Untuk bank, NGFW dengan SLA vendor wajib.

Warning — Kesalahan fatal

Rule "allow any any" untuk tes lalu lupa dicabut. Saya temukan ini di production bank kecil. Hapus rule allow-all segera setelah debug. Audit rule tiap kuartal.

Hybrid cloud: menyambungkan VPC ke kantor

Hybrid cloud bukan "server di AWS lalu akses dari kantor". Itu VPN biasa. Hybrid yang proper: VPC punya CIDR sendiri, ada BGP atau tunnel ke on-prem, dan route diiklankan dua arah. Di AWS, pakai Transit Gateway + VPN IPsec ke FortiGate kantor. Di GCP, Cloud VPN. Di Azure, Virtual WAN.

Masalah nomor satu: overlap subnet. Kantor pakai 10.0.0.0/8, VPC juga 10.x.x.x — tidak bisa di-route. Solusi: redesign CIDR kantor ke 172.16.0.0/12 atau pakai NAT pada tunnel (VPC melihat kantor sebagai 100.64.x.x). NAT di tunnel menambah kompleksitas tapi menyelamatkan kita dari re-IP seluruh kantor.

Topologi hybrid cloud

On-Prem FortiGate Server Cloud VPC Transit GW EC2 IPsec / BGP

Trade-off: hybrid memberi kamu elastic compute tanpa tinggalkan data lama, tapi latency antar-site naik (3–20 ms tambahan). Aplikasi yang butuh transaksi lokal cepat sebaiknya tetap on-prem. Jangan pindahkan database ke cloud cuma karena tren kalau aplikasinya di kantor.

Troubleshooting nyata

Tool wajib di tas saya: ping (reachability), traceroute/mtr (di mana putus), tcpdump (lihat paket beneran), ss -tlnp (port listen), dan iperf3 (ukur throughput murni).

Kasus: user bilang "website lambat". Jangan langsung salahin server app. Jalankan mtr -n website.com. Kalau hop terakhir mengalami packet loss, masalah di server/hosting. Kalau loss di hop tengah tapi stabil di akhir, itu biasanya ICMP throttling carrier — abaikan. Kalau loss mulai dari gateway kantor, cek bandwidth atau QoS.

# Lihat paket benar-benar sampai interface?
tcpdump -i eth0 -n host 10.10.20.5 and port 443
# Ukur troughput antar dua host
iperf3 -s   # di server
iperf3 -c server-ip -t 10

Tips

Selalu catat baseline. Saat normal, mtr ke Google berapa ms? Kalau besok jadi 2x lipat, kamu punya angka pembanding, bukan tebakan.

Checklist pre-deploy jaringan

• ✓ CIDR tidak overlap (on-prem vs cloud)

• ✓ VLAN sudah didesain berdasarkan fungsi, bukan lokasi

• ✓ Default route punya failover (track/SLA)

• ✓ Rule firewall audited, tidak ada allow-any

• ✓ VPN punya monitoring tunnel up/down

• ✓ Backup config (MikroTik export, pfSense xml)

FAQ

Apakah VLAN bisa menggantikan firewall antar-segment?

Tidak sepenuhnya. VLAN memisahkan broadcast domain tapi lalu lintas antar-VLAN masih bisa lewat jika tidak difilter. Kamu butuh ACL atau firewall stateful di gateway Layer-3 untuk mengontrolnya.

Kapan sebaiknya tidak menggunakan VPN site-to-site?

Kalau hanya satu atau dua user yang butuh akses, VPN remote access lebih murah dan lebih mudah diaudit. Site-to-site baru masuk akal kalau kamu menyambungkan dua jaringan utuh (kantor ke kantor, atau VPC ke DC lama).

MikroTik cukup untuk enterprise?

Cukup untuk routing, VLAN, dan VPN di banyak kasus menengah. Tapi untuk NGFW (IPS/AV terurai), tim dukungan 24/7, dan kepatuhan, Fortinet atau perangkat vendor dengan SLA jauh lebih nyaman.

Afry Articles — ditulis dari pengalaman lapangan.