Belajar L2TP IPsec - Transport Mode vs Tunnel Mode

#Pendahuluan

Setelah menguasai IKE, mari fokus pada ESP — protokol yang benar-benar melindungi data. Episode 5 membedah dua mode kerjanya: transport mode dan tunnel mode. Keduanya menentukan apa saja yang dienkripsi dan bagaimana paket disusun ulang, sekaligus menjadi salah satu opsi paling awal yang kalian temui di file konfigurasi.

Pertanyaan yang selalu muncul: mengapa ada dua mode, dan kapan harus memakai yang mana? Jawabannya bergantung pada siapa yang berkomunikasi — dua host atau dua gateway. Kita akan menjawabnya dengan melihat isi paket secara detail, lalu menutup dengan peran keduanya di arsitektur L2TP/IPsec.

#Transport Mode: Melindungi Payload

#ESP Transport untuk Endpoint

Dalam transport mode, ESP hanya mengenkripsi payload dari paket IP asli — header IP tetap utuh dan terlihat di jaringan. Mode ini dipakai untuk komunikasi endpoint-to-endpoint: dua host atau dua daemon yang berbicara langsung. Karena header asli dipertahankan, tidak ada header luar tambahan, sehingga overhead lebih kecil.

Gambaran paket dalam transport mode:

[IP header asli][ESP header][payload terenkripsi][ESP trailer]

Transport mode cocok saat kedua ujung komunikasi adalah pihak yang sama — misalnya dua server yang mengirim data langsung, atau saat L2TP sendiri yang menyediakan tunneling. Dalam kasus L2TP, inilah alasan banyak implementasi remote access memakai ESP transport mode: IPsec melindungi paket UDP 1701, sementara L2TP yang membawa frame PPP.

#Tunnel Mode: Membungkus Seluruh Paket

#ESP Tunnel untuk Gateway

Dalam tunnel mode, ESP mengenkripsi seluruh paket IP asli — termasuk header-nya — dan membungkusnya dalam paket IP baru dengan header luar. Header luar berisi alamat gateway, sedangkan header dalam (yang asli) disembunyikan di dalam payload terenkripsi. Mode ini adalah mode default untuk site-to-site dan remote access VPN gateway-to-gateway.

Gambaran paket dalam tunnel mode:

[Header IP luar][ESP header][paket IP asli terenkripsi][ESP trailer]

Karena seluruh paket asli disembunyikan, tunnel mode melindungi detail internal seperti topologi jaringan dan alamat host di belakang gateway. Inilah yang kalian butuhkan saat dua jaringan terpisah disambungkan lewat internet.

#L2TP/IPsec dan Pemilihan Mode

#Kedua Mode Diizinkan RFC 3193

RFC 3193 mengizinkan ESP dalam transport mode maupun tunnel mode untuk L2TP/IPsec. Yang tidak pernah diizinkan adalah mengirim traffic L2TP tanpa perlindungan ESP. Pilihan praktisnya bergantung topologi:

• Remote access (satu LNS): lazim memakai transport mode, karena L2TP sudah menyediakan tunneling dan IPsec cukup melindungi paket UDP 1701. Inilah konfigurasi type=transport yang kita tulis di episode 3.
• Site-to-site L2TP/IPsec (dua LNS): lazim memakai tunnel mode, karena traffic harus melintasi dua gateway jaringan yang berbeda.

Jadi pernyataan bahwa L2TP/IPsec selalu memakai tunnel mode perlu dipahami dengan hati-hati: yang pasti selalu adalah kehadiran ESP, sementara mode-nya mengikuti topologi. Detail konkretnya di kolom type= di bawah.

#Memilih Mode di Konfigurasi

#Kolom type di Libreswan

Di Libreswan, mode ESP ditentukan oleh nilai type=. Untuk remote access L2TP klasik:

conn L2TP-PSK
    type=transport
    leftprotoport=17/1701
    rightprotoport=17/%any

Untuk site-to-site, ganti menjadi tunnel mode dan hapus batasan port:

conn office-to-dc
    type=tunnel
    left=203.0.113.10
    right=198.51.100.20
    leftsubnet=10.10.10.0/24
    rightsubnet=192.168.1.0/24

Cek mode SA yang aktif lewat baris encapsulation: transport atau tunnel pada output berikut:

ipsec status
ipsec statusall | grep -i encapsulation

Perintah ipsec statusall menampilkan seluruh detail SA, termasuk mode enkapsulasi dan algoritma yang disepakati. Membacanya secara rutin adalah kebiasaan baik untuk troubleshooting.

#Memilih Mode: Aturan Praktis

#Panduan Keputusan Cepat

Keputusan mode ESP sebenarnya cukup sederhana. Tanyakan satu hal: apakah kedua ujung koneksi berada di jaringan yang sama?

• Jika ya — dua host saling berbicara langsung — pakai transport mode.
• Jika tidak — traffic harus melewati dua jaringan berbeda lewat gateway — pakai tunnel mode.

Dalam konteks L2TP/IPsec, terjemahannya menjadi: remote access dengan satu server memakai transport mode, sedangkan site-to-site dengan dua gateway memakai tunnel mode. Aturan ini berlaku konsisten di Libreswan dan strongSwan.

#Kesalahan Umum Pemilihan Mode

Dua kesalahan yang sering terjadi. Pertama, memakai tunnel mode untuk remote access L2TP — hasilnya tetap berfungsi, tapi overhead bertambah tanpa manfaat karena L2TP sudah menjadi tunnel-nya. Kedua, lupa mencocokkan type di kedua sisi — Libreswan akan menolak SA atau membangun SA dengan mode yang tidak terduga.

Jika ipsec statusall menampilkan encapsulation: tunnel padahal kalian menulis type=transport, periksa dulu apakah file konfigurasi dimuat ulang:

sudo ipsec setup --restart

Perintah ipsec setup --restart memuat ulang seluruh konfigurasi. Kebiasaan baik: setelah mengubah type=, selalu restart dan verifikasi ulang output ipsec statusall.

#Penutup

Episode 5 menjelaskan perbedaan inti transport mode dan tunnel mode: transport mode melindungi payload dengan overhead kecil untuk komunikasi endpoint, sedangkan tunnel mode membungkus seluruh paket IP untuk gateway. Kalian juga tahu bahwa RFC 3193 mengizinkan keduanya untuk L2TP/IPsec — selama ESP selalu hadir — dan cara memilihnya lewat kolom type=.

Inti yang harus dibawa pulang:

• Transport mode hanya mengenkripsi payload; header IP tetap terlihat.
• Tunnel mode membungkus seluruh paket IP dalam header luar baru.
• Transport mode cocok untuk host-to-host dan remote access L2TP.
• Tunnel mode cocok untuk site-to-site dan VPN gateway.
• RFC 3193 mengizinkan kedua mode; yang wajib adalah kehadiran ESP.
• Di Libreswan, pilihan mode ditulis pada kolom type=.

Di episode 6 selanjutnya kita akan membahas authentication: PSK, sertifikat, dan XAUTH — tiga cara memvalidasi identitas di L2TP/IPsec, kekuatan dan kelemahan masing-masing, serta kapan memakai PSK sederhana, X.509 enterprise, atau XAUTH untuk pengguna.