Belajar L2TP IPsec - Sejarah, Latar Belakang & Mengapa L2TP/IPsec

#Pendahuluan

Setiap teknologi besar lahir dari masalah nyata. L2TP/IPsec muncul di akhir 1990-an ketika perusahaan ingin pegawai di luar kantor tetap bisa mengakses jaringan internal secara aman melalui internet — tanpa harus menyewa leased line yang mahal. Episode 1 membuka perjalanan itu: bagaimana VPN berevolusi, mengapa L2TP dibuat, dan keputusan penting menggabungkannya dengan IPsec.

Memahami sejarah bukan sekadar nostalgia. Banyak keputusan desain L2TP/IPsec — seperti mengapa ia butuh dua protokol sekaligus, mengapa port UDP 1701 dipakai, atau mengapa NAT Traversal diperlukan — baru masuk akal kalau kalian tahu dari mana teknologi ini berasal. Mari kita mulai dari titik awal evolusi VPN.

#Evolusi VPN: Dari PPTP ke L2TP

#PPTP: Pelopor Komersial

Tahun 1996, Microsoft merilis PPTP (Point-to-Point Tunneling Protocol). PPTP menggabungkan PPP dengan GRE (Generic Routing Encapsulation) dan membawa PPP melewati jaringan IP. Sayangnya, otentikasi bawaan PPTP terbukti lemah — MPPE yang memakai RC4 mudah diserang — dan protokolnya sendiri tidak punya mekanisme pertukaran kunci yang solid. PPTP menjadi populer karena ada di dalam Windows, tapi rapuh secara kriptografis.

#L2F: Jawaban Cisco

Di sisi lain, Cisco mengembangkan L2F (Layer 2 Forwarding) untuk solusi dial-in terpusat. Alih-alih mengenkripsi, L2F fokus pada forwarding frame Layer 2 antar gerbang. Muncul perang standar: Microsoft memakai PPTP, Cisco memakai L2F, dan perangkat-perangkat yang berbeda tidak saling berbicara.

#L2TP: Konsolidasi Dua Dunia

Tahun 1999, IETF menyatukan PPTP dan L2F menjadi L2TP (Layer 2 Tunneling Protocol) lewat RFC 2661. L2TP mengambil konsep tunneling dari L2F dan membungkus PPP seperti PPTP, namun mengirimkan data melalui UDP port 1701 — bukan GRE. Tujuannya: satu standar terbuka yang bisa dipakai lintas vendor seperti Cisco, Microsoft, dan Juniper.

Urutan evolusinya bisa kalian simpan sebagai berikut:

PPTP (1996, Microsoft) -> L2F (Cisco) -> L2TP (1999, RFC 2661)
L2TP murni (tanpa enkripsi) -> L2TP/IPsec (2001, RFC 3193)

#Masalah yang Diselesaikan L2TP

#Tunneling Layer 2 yang Netral Vendor

Masalah utama sebelum L2TP: tidak ada cara standar membawa koneksi Point-to-Point melewati jaringan IP lintas vendor. L2TP menyelesaikannya dengan mendefinisikan dua peran: LAC (L2TP Access Concentrator) di sisi klien dan LNS (L2TP Network Server) di sisi server. Keduanya membangun tunnel L2TP yang berisi satu atau lebih session PPP.

#Dukungan Otentikasi PPP

Karena L2TP membungkus PPP, seluruh ekosistem otentikasi PPP ikut terbawa: PAP, CHAP, MS-CHAPv2, dan EAP. Inilah alasan L2TP terasa natural bagi enterprise — pengguna tetap memakai username dan password yang sama seperti koneksi dial-up, dan bisa dipetakan ke RADIUS atau LDAP. Detailnya akan kita bahas di episode 7 dan 11.

#Mengapa L2TP Harus Digabung dengan IPsec

#L2TP Murni Tidak Mengenkripsi

Ini poin terpenting: L2TP murni tidak menyediakan enkripsi atau otentikasi data. Frame PPP dikirim polos lewat UDP 1701. Siapa pun yang bisa menyadap jaringan bisa membaca seluruh traffic VPN. L2TP hanya menyediakan tunneling — membawa paket dari titik A ke titik B — tanpa melindungi isinya.

#IPsec Menyediakan Keamanan yang Kurang

IPsec menawarkan enkripsi dan otentikasi penuh di Layer 3, tapi konfigurasinya rumit dan modelnya kurang natural untuk mendukung ribuan pengguna dial-in. Solusinya: gabungkan keduanya. IPsec menangani keamanan, L2TP menangani tunneling Layer 2 dan otentikasi pengguna. Kombinasi ini dibakukan dalam RFC 3193 tahun 2001, yang mendefinisikan cara L2TP berjalan di atas ESP dalam tunnel mode.

Hasilnya, port UDP 1701 untuk L2TP dikunci di balik ESP, dan IKE bernegosiasi untuk mengamankan koneksi terlebih dahulu sebelum L2TP memulai tunnel:

PPP -> L2TP (UDP 1701) -> ESP (IPsec, tunnel mode) -> IP

#Posisi L2TP/IPsec Hari Ini

L2TP/IPsec sudah berusia lebih dari dua dekade, dan statusnya di kalangan pengamat keamanan banyak yang menilai lemah dibandingkan standar modern. Ia tetap dipakai karena dukungan native di semua sistem operasi — iOS, Android, Windows, dan macOS — tanpa perlu aplikasi tambahan, dan menjadi pilihan praktis untuk remote access. Namun, karena IKEv1 dengan PSK dan MS-CHAPv2 punya kelemahan, banyak praktisi menyarankan migrasi ke IKEv2 murni atau WireGuard.

Kita akan mengukur semua ini secara objektif di episode 13 (keamanan) dan episode 22 (perbandingan modern). Untuk sekarang, satu fakta penting: memahami L2TP/IPsec berarti memahami bahwa setiap frame PPP yang kalian kirim dibungkus dua kali — sekali oleh L2TP, sekali oleh ESP. Urutan pembungkusan inilah yang akan kita bedah di episode 2.

#Dua Dokumen yang Membangun Fondasi

#RFC 2661 dan RFC 3193

Dua dokumen standar adalah tulang punggung L2TP/IPsec. RFC 2661 yang terbit tahun 1999 mendefinisikan L2TP itu sendiri: struktur pesan, mekanisme control connection, dan cara data message dibungkus. RFC 3193 yang terbit tahun 2001 menambahkan babak berikutnya: bagaimana L2TP berjalan di dalam ESP, mode enkapsulasi mana yang boleh dipakai, dan bagaimana port UDP 1701 dikunci oleh IPsec.

Kalian bisa membaca kedua dokumen langsung dari sumber resminya:

curl -O https://www.rfc-editor.org/rfc/rfc2661.txt
curl -O https://www.rfc-editor.org/rfc/rfc3193.txt

Perintah curl -O https://www.rfc-editor.org/rfc/rfc2661.txt mengunduh dokumen resmi ke direktori kerja. Keduanya layak dibaca setidaknya sekali — terutama bagian "Security Considerations" pada RFC 3193 yang menjelaskan secara eksplisit mengapa L2TP membutuhkan IPsec.

#Mengapa UDP 1701 Bukan Kekurangan

Pertanyaan yang sering muncul: mengapa L2TP memakai UDP, padahal UDP tidak menjamin pengiriman paket? Jawabannya ada di desain L2TP. Pesan kontrol mengimplementasikan reliabilitasnya sendiri dengan nomor sequence dan acknowledgment, sementara data message memang tidak perlu reliabel — itu sudah diurus oleh lapisan di atasnya, seperti TCP yang berjalan di dalam PPP.

Dengan memilih UDP, L2TP menghindari overhead transportasi berlapis yang tidak perlu. Ini pola yang penting: setiap protokol memilih trade-off sendiri. L2TP memilih UDP demi kesederhanaan, lalu menyerahkan keandalan ke lapisan yang memang membutuhkannya.

#Membaca Dokumen Standar

Tidak ada cara lebih baik untuk memahami L2TP/IPsec selain membaca spesifikasinya. Saat membaca RFC, perhatikan tiga hal:

• Pesan kontrol: bagaimana SCCRQ dan teman-temannya membangun tunnel.
• Payload data: bagaimana frame PPP dibungkus dan dikirim.
• Kombinasi dengan IPsec: bagaimana RFC 3193 menghubungkan kedua protokol.

Pembahasan detail setiap mekanisme akan menemani kita di episode 2, 4, dan 7. Untuk sekarang, catat saja bahwa kedua RFC ini adalah referensi resmi yang selalu bisa kalian buka kembali.

#Penutup

Episode 1 memberikan konteks sejarah: L2TP lahir dari konsolidasi PPTP dan L2F pada RFC 2661, lalu digabung dengan IPsec pada RFC 3193 karena L2TP murni tidak mengenkripsi apa pun. Kalian juga sudah melihat mengapa kombinasi ini populer di enterprise dan mengapa mulai ditinggalkan.

Inti yang harus dibawa pulang:

• Evolusi VPN: PPTP (1996), L2F (Cisco), lalu L2TP (RFC 2661, 1999).
• L2TP menyatukan tunneling PPTP dan L2F ke dalam satu standar netral vendor.
• L2TP murni tidak aman: tidak ada enkripsi, tidak ada otentikasi data.
• IPsec menyediakan keamanan yang L2TP tidak punya.
• RFC 3193 (2001) membakukan L2TP/IPsec: L2TP di dalam ESP tunnel mode.
• Dukungan native di semua OS membuat L2TP/IPsec tetap dipakai hingga kini.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama — bagaimana LAC dan LNS berkomunikasi lewat control connection dan data message, bagaimana IKE membangun kunci, dan bagaimana ESP mengamankan frame PPP di dalam tunnel mode. Ini adalah fondasi teknis yang akan dipakai di seluruh series.