Alur Proses Penelitian Openswan Kesimpulan

dilakukan untuk melakukan verifikasi terhadap kemampuan sistem remote access IPsec berbasis perangkat lunak IKEv2 strongSwan untuk mengatasi permasalahan remote access IPsec. Langkah-langkah yang diterapkan dalam fase ini adalah : a. Pembuatan Simulasi Jaringan b. Penerapan Perangkat Lunak c. Pengujian Sistem 4. Fase Implementation, Monitoring, dan Management Tahapan berikutnya yaitu Implementation, Monitoring, dan Management tidak penulis lakukan dikarenakan selain dari fokus penelitian skripsi ini yang melakukan simulasi pembangunan sistem, terdapat keterbatasan yang menghambat pelaksanaan tahapan-tahapan tersebut. Keterbatasan-keterbatasan yang menghambat proses penelitian skripsi ini adalah: a. Waktu yang tidak mendukung, dikarenakan sempitnya waktu yang dimiliki penulis untuk melakukan penelitian. b. Peralatan yang terbatas, kebutuhan alat penelitian seperti hardware yang terbatas.

3.6 Alur Proses Penelitian

47 Gambar 3.2 Alur Proses Penelitian Perencanaan Penelitian Skripsi Perumusan Pendefinisian Masalah Perumusan Hipotesis Metode Pengembangan Sistem Metode Pengumpulan Data NETWORK DEVELOPMENT LIFE CYCLE NDLC Simulation Prototyping Design Analysis Desain Topologi Jaringan Internet Pengujian Sistem Evaluasi Penentuan Masalah Studi Literatur Desain Skenario Jaringan Pengujian Pembuatan Simulasi Jaringan Internet Perumusan Kesimpulan Pembuatan Laporan Penentuan Kebutuhan Sistem Pemberian Solusi Penerapan Perangkat Lunak Managemement Implementation Monitoring 48 BAB IV ANALISIS DAN PEMBAHASAN

4.1 Fase Analysis

Fase ini merupakan fase awal dalam proses penelitian skripsi ini. Pada fase ini, langkah yang kami lakukan adalah melakukan penentuan masalah, pemberian solusi, dan penentuan kriteria kebutuhan sistem.

4.1.1 Penentuan Masalah Remote Access VPN berbasis IPsec

Pada bagian ini, akan diulas secara detail permasalahan yang ada pada penerapan Remote Access VPN Berbasis IPsec yang telah berhasil kami temukan melalui kegiatan studi pustaka.

4.1.1.1 Kebutuhan Algoritma Kriptografi Yang Kuat

Kebutuhan algoritma kriptografi dalam remote access IPsec dapat dibagi menjadi kedalam beberapa bagian yaitu algoritma endpoint authentication, algoritma pembuatan kunci shared secret, algoritma message integrity, algoritma enkripsi. Saat ini berbagai vendor penyedia solusi sistem remote access IPsec memiliki suatu set algoritma kriptografi atau algorithm suite sendiri. Pilihan– pilihan algoritma yang bervariasi itu belum tentu menyediakan tingkat keamanan yang baik. Contoh dari pemilihan algoritma kriptografi itu adalah seperti pilihan algoritma digital signature RSA sebagai algoritma autentikasi endpoint, pilihan grup MODP Diffie-Hellman 768bit dan 1024bit sebagai input dalam algoritma pembuatan shared secret, pilihan HMAC-MD5-96 sebagai algoritma message integrity, dan pilihan algoritma 3DES atau CAST128 sebagai algoritma enkripsi. Masalahnya adalah bahwa pihak-pihak yang ingin menerapkan sistem remote access IPsec dihadapkan pada banyak pilihan algoritma kriptografi dimana 49 pilihan-pilihan tersebut belum tentu menyediakan tingkat keamanan yang baik. Oleh karena itu, dibutuhkan suatu referensi ilmiah yang menyediakan rujukan set pilihan algoritma kriptografi atau algorithm suite yang memberikan tingkat keamanan yang kuat.

4.1.1.2 Kebutuhan Pengulangan Autentikasi

Dalam skenario remote access, terkadang masing-masing peer IPsec ingin melakukan autentikasi mutual diulangi secara periodik. Proses ini disebut sebagai pengulangan autentikasi. Tujuan pengulangan autentikasi adalah untuk membatasi waktu bahwa suatu SA Security Association dapat digunakan oleh pihak ketiga yang telah mengambil alih kendali peer IPsec. Masalahnya adalah proses pengulangan autentikasi bisa saja dilakukan dengan secara sederhana mengulang proses initial exchange, akan tetapi pada skenario remote access IPsec, dibutuhkan interaksi user pada klien remote access untuk membuat ulang proses initial exchange. Oleh karena itu, dibutuhkan suatu prosedur otomatis yang bisa menjalankan skema pengulangan autentikasi secara periodik tanpa interaksi user. Selain itu dibutuhkan suatu standar rentang waktu untuk pengulangan autentikasi.

4.1.1.3 Masalah Ketidakcocokan NAT-IPsec

Remote Access VPN terutama digunakan untuk menyediakan akses bagi pengguna remote access seperti teleworkerbekerja dari rumah atau mobile user. Pengguna tersebut umumnya berada dalam suatu lingkungan yang menjalankan fungsi NAT. Berdasarkan RFC3715IPsec-NAT Compatibility Requirements, diketahui bahwa penerapan IPsec dalam suatu lingkungan NAT tidak dapat berjalan lancar atau dengan kata lain terdapat ketidakcocokan antara IPsec dengan 50 NAT. Luasnya penggunaan NAT membuat penerapan IPsec sebagai solusi standar VPN khususnya remote access VPN teleworker dan mobile user mengalami hambatan. Salah satu penyebab masalah ketidakcocokan antara NAT dan IPsec adalah mekanisme kerja kedua teknik tersebut yang saling bertolak belakang. Di satu sisi, NAT memodifikasi data alamat dan nomor port pada header IP. Di sisi lain, IPsec mencoba memberikan suatu tingkat pengamanan komunikasi data dengan mengantisipasi adanya modifikasi itu. Jadi pada dasarnya IPsec berfungsi untuk mencegah apa yang NAT lakukan dan secara fundamental saling berlawanan.

4.1.1.4 Masalah Alamat Klien IPsec yang Overlapping

Berdasarkan RFC3938UDP Encapsulation of IPsec ESP Packets pada bagian 5.1, terdapat sebuah kemungkinan kasus yang dapat menimbulkan konflik pada penerapan IPsec mode operasi tunnel dalam situasi NAT Traversal. Yaitu ketika terdapat IPsec Remote Access Client IRAC yang memiliki alamat IP yang saling overlapping tumpang tindih. IPsec Remote Access Server IRAS atau gateway IPsec akan melihat klien-klien tersebut adalah sama karena memiliki alamat IP yang sama sehingga akan memiliki SA IPsec yang akan overlapping. Server bisa saja menggunakan SA yang salah ketika akan mengirimkan paket dari jaringan LAN ke klien IPsec. Masalah ini membutuhkan solusi yang tidak dapat diselesaikan hanya dengan menggunakan mekanisme NAT Traversal saja. 51 Gambar 4.1 Alamat IP Klien IPsec yang overlapping Pada gambar diatas bisa dilihat bahwa klien A dan klien B memiliki alamat IP private yang sama yaitu 10.1.0.1024. Dengan demikian SA pada server IPsec memiliki nilai traffic selector yang sama atau overlapping. Hal ini akan menjadi masalah bagi server IPsec karena dia memiliki kemungkinan untuk mengirimkan paket IPsec ke tujuan klien yang salah.

4.1.1.5 Masalah NAT Traversal Mode Transport

Berdasarkan RFC3938UDP Encapsulation of IPsec ESP Packets pada bagian 5.2, terdapat situasi yang berpotensi menimbulkan masalah IPsec pada mode operasi transport dalam situasi NAT Traversal. Misalnya terdapat beberapa klien dibelakang NAT yang sama membangun suatu VPN IPsec mode transport. Bagi server IPsec, dalam mode transport, klien-klien dibelakang NAT adalah klien yang sama baginya, yaitu alamat IP NAT eksternal. SA yang dibangun antara server IPsec dan NAT memuat traffic description yang berisi keterangan protokol dan informasi port. Jika traffic description tersebut saling overlapping tumpang tindih, maka server bisa mengirimkan paket IPsec ke klien dengan SA yang salah. GW2 IPsec Security Gateway .10 .10 192.168.0.030 .1 .2 .1 10.1.0.024 A .3 .1 10.1.0.024 B NAT NAT L A N 192.168.1.024 Outbound SA pada IPsec GW2: SA1, server GW2 to A, tcp, udp-encap 4500,2501 traffic selector 192.168.0.232 - 10.1.0.1024 SA2, server GW2 to B, tcp, udp-encap 4500,2502 traffic selector 192.168.0.232 - 10.1.0.1024 - GW1 GW3 52 Gambar 4.2 Traffic description yang overlapping Pada gambar diatas bisa dilihat bahwa klien A dan klien B memilih traffic descriptor port TCP 80 yang sama. Dalam mode transport IPsec, Hal ini akan menjadi masalah bagi server IPsec karena dia mungkin saja mengirimkan paket IPsec ke tujuan klien yang salah.

4.1.1.6 Kebutuhan Peer IPsec yang Mobile dan Multihoming

IKEv2 digunakan untuk melakukan autentikasi mutual dan juga untuk membangun dan mengelola SA Security Association. SA IKE dan SA IPsec mode tunnel dibuat secara implisit antara alamat IP yang digunakan ketika SA IKE dibangun. Alamat IP ini kemudian digunakan sebagai outer IP header header IP terluar pada paket IPsec mode tunnel. Jika SA IKE telah dibuat, maka menjadi tidak mungkin untuk mengubah alamat IP tersebut. Terdapat skenario dimana alamat IP tersebut bisa berubah. Misalnya terdapat suatu klien IPsec yang mobile dan sering berpindah jaringan sehingga memiliki alamat IP yang sering berubah. Selain itu terdapat juga klien yang bersifat multihoming yang terhubung ke lebih dari satu jaringan dengan interfacenya masing-masing. Jika interface yang digunakan untuk membangun tunnel IPsec tiba-tiba down, maka peer IPsec IPsec Server .20 .10 192.168.0.030 .3 .2 .1 10.1.0.024 GW2 A B NAT Overlapping traffic descriptor Outbound SA pada Server IPsec GW2: SA1, GW2 to A , tcp:80, udp-encap 4500,2501, mode transport, traffic selector 192.168.0.232 – 192.168.0.332 SA2, GW2 to B , tcp:80, udp-encap 4500,2502, mode transport, traffic selector 192.168.0.232 – 192.168.0.332 53 GW1 itu harus membangun dari ulang kembali SA IKE dan SA IPsec. Pembangunan ulang tunnel bukan merupakan pilihan yang ideal bagi user remote access dikarenakan dibutuhkan adanya interaksi user. Untuk alasan tersebut, dibutuhkan adanya suatu prosedur yang mampu secara otomatis melakukan update SA untuk memenuhi kebutuhan mobility dan multihoming peer IPsec.

4.1.2 Pemberian Solusi Dengan Protokol IKEv2

Tabel berikut menjelaskan solusi yang diberikan untuk setiap permasalahan pada remote access VPN berbasis IPsec. Tabel 4.1 Solusi yang diberikan berdasarkan protokol IKEv2 No Masalah yang dihadapi Solusi yang diberikan 1 Kebutuhan algoritma kriptografi yang kuat Algoritma kritpgrafi suite B RFC4869 2 Kebutuhan Pengulangan autentikasi repeated authentication RFC4478 3 Masalah Ketidakcocokan NAT-IPsec NAT Traversal pada IKEv2 4 Masalah Alamat Klien IPsec yang overlapping virtual IP melalui configuration payload pada IKEv2 5 Masalah NAT Traversal mode transport konfigurasi Tunnel Mode policy 6 Kebutuhan Peer IPsec yang mobile dan multihoming MOBIKE RFC4555

4.1.2.1 Algoritma Suite B

Untuk pemilihan set algoritma kriptografi IPsec, kami memutuskan untuk memilih acuan Suite B Cryptography. Suite B adalah suatu kumpulan standar kriptografi yang dispesifikasikan oleh NSA National Security Agency sebuah badan keamanan Amerika. Suite B membuat standar acuan bagi industri melalui suatu set algoritma kriptografi yang bisa digunakan untuk membuat produk yang memenuhi kebutuhan pemerintahan. Termasuk didalam spesifikasi Suite B adalah algoritma Integrity, Enkripsi, Key Exchange, Digital Signature. Seluruh algoritma 54 dalam Suite B sudah di-approve oleh FIPS Federal Information Processing Standards Amerika. FIPS bertugas untuk mengatur standar dan guidelines bagi sumber daya komputasi Federal Amerika Serikat. Sebagian besar algoritma kriptografi dalam Suite dipublikasikan oleh NIST National Institute of Standards and Technology Amerika. Tabel 4.2 Kekuatan Algoritma Suite B NSA berdasarkan level kerahasiaan Sumber: Wheeler, 2009:3 Tabel diatas menunjukkan set algoritma dalam suite B dan kekuatannya untuk algoritma enkripsi, hashing, digital signature, dan key exchange. Algoritma enkripsi menggunakan AES-GCMAdvance Encryption Standard-Galois Counter Mode dengan kunci berukuran 128 bit untuk pengamanan data level secret dan dibawahnya, dan kunci berukuran 256 bit untuk pengamanan data level top secret. Algoritma Hashing menggunakan SHA-256 Secure Hash Algorithm-256 dengan digest berukuran 256 bit pada level secret and below, dan SHA-384 dengan digest berukuran 384 bit untuk top secret. Algoritma Digital Signature menggunakan ECDSA Elliptic Curve Digital Signature Algorithm dengan kunci berukuran 256bit pada level secret and below, dan kunci berukuran 256 bit untuk pengamanan data level top secret. Untuk key exchange, digunakan protokol ECDH elliptic curve Diffie-Hellman dengan dengan kunci berukuran 256bit pada level secret and below, dan kunci berukuran 256 bit untuk pengamanan data level top secret. 55 Menurut Wheeler, 2009:5, elliptic-curve cryptography ECC mengacu pada masalah elliptic-curve discrete-logarithm problem, yang merupakan evolusi terhadap pendekatan discrete-logarithm yang digunakan pada mekanisme Diffie- Hellman DH and DSA tradisional, sedangkan RSA menggunakan pendekatan berbasis integer factorization. Tabel dibawah menunjukkan perbandingan kekuatan algoritma asimetris berbasis pendekatan konvensional discrete logarithm modulus DSA dan DH, dan pendekatan integer factorization modulus RSA dengan algoritma asimetris berbasis pendekatan elliptic curve ECC prime field. Algoritma kriptografis tersebut dibandingkan dengan patokan algoritma enkripsi per ukuran bit 80, 112, 128, 192, dan 256 bit. Tabel 4.3 Perbandingan kekuatan algoritma kriptografi Sumber: Wheeler, 2009:4 Seperti bisa dilihat pada tabel diatas, untuk mendapatkan tingkat keamanan bit bits of security 128 bit enkripsi simetris dengan AES-128, dibutuhkan nilai modulus pada DSA Digital Signature Algorithm, DH Diffie- Helman, dan berukuran 3072bit. Dengan alternatif ECCelliptic curve cryptography, hanya dibutuhkan nilai prima berukuran 256 bit untuk tingkat keamanan bit bits of security 128 bit enkripsi simetris dengan AES-128 yang sama. Dengan demikian, algoritma berbasis penggunaan ECC prime field 56 menawarkan efisiensi penggunaan ukuran bit dibandingkan dengan DSA, DH, maupun standar DSA biasa. RFC 4869 Suite B Cryptographic Suites for IPsec memberikan dukungan kompatibilitas terhadap spesifikasi Suite B dari NIST untuk protokol IKEv2. Dokumen RFC 4869 mengajukan 4 “User Interface Suites” yang mengacu pada spesifikasi Suite B dari NIST. Tabel 4.4 Cryptography Suite B pada RFC 4869 Algoritma Suite B GCM-128 Suite B GCM-256 Suite B GMAC-128 Suite B GMAC-256 ESP Encryption AES-GCM 128bit 16 octet ICV AES-GCM 256bit 16 octet ICV Null Null Integrity Null Null AES-GMAC 128bit AES-GMAC 256bit IKEv2 Encyrption AES-CBC 128bit AES-CBC 256bit AES-CBC 128bit AES-CBC 256bit prf HMAC-SHA- 256 HMAC-SHA- 384 HMAC-SHA- 256 HMAC-SHA- 384 Integrity HMAC-SHA- 256-128 HMAC-SHA- 384-192 HMAC-SHA- 256-128 HMAC-SHA- 384-192 DH Group 256-bit random ECP group 384-bit random ECP group 256-bit random ECP group 384-bit random ECP group Authentication ECDSA-256 ECDSA-384 ECDSA-256 ECDSA-384 Keempat suite dibedakan oleh pilihan algoritma kriptografi pada negosiasi pengamanan paket IKEv2 dan tunnel ESP. Suite B GCM-128Galois Counter Mode-128 dan GMAC-128Galois Message Authentication Code-128 memiliki pilihan algoritma kriptografi untuk IKEv2 tetapi berbeda untuk ESP. Begitu pula pilihan suite B GCM-256 dan GMAC-256 adalah sama untuk IKEv2 tetapi berbeda untuk ESP. Pilihan ESP ada yang menggunakan algoritma enkripsi AES-GCM 128 atau 256 dan ada yang menggunakan algoritma integrity AES-GMAC 128 atau 256. Pilihan untuk IKEv2 menggunakan algoritma enkripsi AES-CBC Advanced Encryption Standard-Cipher Block Chaining 128 atau 256 bit, algoritma integrity 57 HMAC-SHA-256-128 atau HMAC-SHA-384-192, algoritma key exchange DH dengan grup ecp elliptic curve prime 128 atau 256 bit, dan algoritma digital signature ECDSA Elliptic Curve Digital Signature Algorithm 256 atau 384 bit.

4.1.2.2 Repeated Authentication untuk IKEv2

Untuk solusi pengulangan autentikasi, kami memilih RFC 4478 Repeated Authentication in IKEv2 Protocol. Dalam RFC 4478, dijelaskan suatu mekanisme untuk memenuhi kebutuhan pengulangan autentikasi secara otomatis bagi host IPsec pada skenario Remote Access IPsec. RFC 4478 mendefinisikan suatu pesan notifikasi baru bagi original responder dapat kirim kepada original initiator untuk menetapkan waktu sebelum autentikasi harus diulang. Rentang waktu untuk autentikasi ulang didefinisikan RFC 4478 antara 300 detik5 menit sampai 86400 detik 24 jam.

4.1.2.3 NAT Traversal pada IKEv2

Suatu solusi dikembangkan untuk mengatasi masalah ketidakcocokan antara NAT dan IPsec yaitu dengan membentuk suatu standar mekanisme pada enkapsulasi IPsec. Solusi ini dinamakan “NAT-Traversal” atau NAT-T yang diajukan sebagai standar oleh Internet Engineering Task Force IETF. Terdapat RFC Request For Proposal yang mendefinisikan standar NAT Traversal yaitu RFC 3947Negotiation of NAT-Traversal in IKE, dan RFC 3948UDP Encapsulation of IPsec ESP Packets. RFC3947 mendefinisikan mekanisme untuk mendeteksi satu atau lebih NAT antara host IPsec, dan bagaimana cara IKE menegosiasikan penggunaan enkapsulasi UDP terhadap paket IPsec melewati NAT. Sedangkan RFC3948 menspesifikasikan metode untuk enkapsulasi dan 58 dekapsulasi paket ESP di dalam suatu paket UDP untuk melewatkannya melalui NAT. Standar Protokol IKEv2RFC 4306 sudah secara default mendukung kemampuan NAT-Traversal. Hal ini merupakan peningkatan dari IKEv1 yang secara default tidak mengatur penanganan masalah IPsec dengan NAT. Gambar 4.3 UDP Encapsulated ESP pada mode transport Gambar 4.4 UDP Encapsulated ESP pada mode tunnel Gambar 4.5 UDP encapsulation of IPsec ESP packet Header Floated IKE yang digunakan adalah yang sesuai dengan yang ditentukan dalam RFC 3947 Negotiation of NAT-Traversal in the IKE. Format header IKE akan menggunakan port 4500. Non-ESP Marker di dalam header 59 berukuran 4 bytes dengan nol yang sejajar dengan SPI field dari sebuah paket ESP. Gambar 4.6 Format Floated IKE Header. Paket NAT keepalive digunakan untuk membuat pemetaan NAT dengan nomor port dinamis tetap hidup. Gambar 4.7 Format Header UDP untuk paket NAT-keepalive.

4.1.2.4 Virtual IP

Untuk menangani masalah alamat klien IPsec yang overlapping pada mode operasi tunnel dalam situasi NAT Traversal, dapat digunakan mekanisme Virtual IP Address Alamat IP Virtual. Alamat IP virtual adalah suatu alamat IP yang digunakan oleh klien IPsec secara virtual untuk mengidentifikasi terhadap server IPsec. Virtual IP address dapat digunakan untuk menyelesaikan masalah konflik alamat IP overlapping oleh klien-klien IPsec. Ketika metode virtual IP digunakan, maka klien akan memesan sebuah alamat IP virtual dan kemudian server IPsec akan mengalokasikan sebuah alamat IP virtual baginya. Data SA kemudian akan 60 berisi traffic selector alamat IP virtual dari klien IPsec tersebut. Dengan demikian, adanya alamat IP klien overlapping dapat dihindari. Gambar 4.8 Virtual IP address Virtual IP address diperoleh melalui configuration payload CP yang dinegosiasikan dalam proses pertukaran IKEv2. Seperti bisa dilihat pada gambar diatas, klien A dan klien B memiliki alamat IP private yang sama atau overlapping yaitu 10.0.1.1024. Dengan mekanisme penggunaan virtual IP, Walaupun A dan B memiliki alamat IP private yang overlapping, klien A akan memiliki alamat unik dengan virtual IP 10.10.0.1 dan klien B memiliki virtual IP 10.10.0.2. Dengan demikian, masalah dapat diselesaikan.

4.1.2.5 NAT Traversal Tunnel Mode Policy

Untuk mengatasi masalah NAT Traversal mode transport dalam situasi NAT Traversal, solusi yang dapat digunakan adalah dengan memaksakan enforcement policy penggunaan mode enkapsulasi tunnel pada enkapsulasi UDP NAT Traversal pada konfigurasi sistem IPsec. Dengan penggunaan mode tunnel, masalah konflik traffic descriptor tidak akan muncul karena setiap klien adalah unik dengan alamat IP yang berbeda. Virtual IP Address via configuration payload SA1, server GW2 to A, tcp, udp-encap 4500,2501 Virtual IP=10.3.0.132 traffic selector 192.168.1.024 - 10.10.0.132 SA2, server GW2 to B, tcp, udp-encap 4500,2502 Virtual IP=10.3.0.232 traffic selector 192.168.1.024 - 10.10.0.232 IPsec Security Gateway .10 .10 192.168.0.030 .1 .2 .1 10.1.0.024 GW2 A .2 .1 10.1.0.024 B NAT NAT L A N 192.168.1.024 Virtual IP 61 Gambar 4.9 Policy NAT Traversal Tunnel Mode NAT Traversal Tunnel Mode dibuat dengan melakukan konfigurasi mode tunnel pada sistem remote access berbasis perangkat lunak IKEv2 strongSwan. Seperti bisa dilihat pada gambar diatas, dengan kebijakan atau policy mode tunnel, tidak akan ditemui masalah traffic descriptor yang overlap sehingga dengan demikian, tidak akan muncul konflik masalah NAT Traversal mode transport.

4.1.2.6 MOBIKE

Sebagai alternatif solusi permasalahan kebutuhan mobility dan multihoming IPsec, dapat digunakan protokol MOBIKE. Protokol IKEv2 melalui ekstensi RFC 4555 IKEv2 Mobility and Multihoming Protocol memungkinkan alamat IP yang diasosiasikan dengan IKEv2 dan mode tunnel IPsec untuk berubah. Dengan demikian, suatu peer IPsec mobile atau multihoming dapat menggunakan protokol MOBIKE untuk mempertahankan koneksi IKEv2 dan IPsec dengan gateway IPsec sementara alamat IP-nyaalamat IP klien itu berubah. Protokol MOBIKE menjelaskan suatu mekanisme yang memungkinkan pengguna Remote Access VPN untuk berpindah dari satu alamat IP ke alamat IP lainnya tanpa harus membuat ulang SA baru hanya update SA Address. Kebijakan enforced Tunnel Mode IPsec Encapsulation: SA1, GW2 to A , tcp 80, udp-encap 4500,2501, mode tunnel traffic selector 192.168.0.1032 – 10.1.0.1024 SA2, GW2 to B , tcp 80, udp-encap 4500,2502, mode tunnel traffic selector 192.168.0.1032 – 10.1.0.2024 IPsec Server .20 .10 192.168.0.024 .3 .2 .1 10.1.0.024 GW2 A B NAT GW1 Tunnel Mode membuat traffic SA menjadi unik 62 MOBIKE juga mendukung skenario dimana gateway VPN atau klien IPsec memiliki beberapa interface jaringan Network Interface. Interface ini bisa saja terhubung ke ISP yang berbeda sehingga peer IPsec tersebut berada dalam kondisi multihoming. Ada kemungkinan bahwa salah satu dari host IPsec tersebut ingin memindahkan suatu tunnel IPsec aktif ke interface lain, misalnya karena interface yang down, dia dapat tetap mempertahankan SA yang aktif dan menggunakan interface lainnya untuk tunnel IPsec.

4.1.3 Menentukan Kebutuhan Sistem

Pada bagian ini, akan diberikan uraian mengenai alternatif solusi perangkat lunak IKEv2 untuk lingkungan sistem operasi Linux yang bersifat open source, dan juga free lisensi GPL. Kami menggunakan implemetasi perangkat lunak IKEv2 strongswan dengan pertimbangan bahwa ia memberikan dukungan fitur yang paling luas dan memenuhi seluruh kriteria kebutuhan sistem yang diajukan. StrongSwan merupakan salah satu pengembang awal perangkat lunak protokol IKEv2 untuk sistem Linux. StrongSwan menyediakan fungsi layanan IKEv2 melalui daemon charon. Proyek strongSwan berfokus pada dukungan kuat terhadap mekanisme autentikasi x.509 termasuk fitur private key dengan smart cardtoken. Fitur yang luas lainnya menjadi kelebihan tersendiri dari alternatif IKEv2 yang satu ini. StrongSwan merupakan proyek yang dikembangkan dari proyek sebelumnya yaitu FreesWAN yang sudah berhenti. Situs resminya ada di http:www.strongswan.org. Pemilihan solusi perangkat lunak IPsec IKEv2 dilakukan dengan membandingkan fitur dan kemampuan setiap aplikasi dengan kriteria kebutuhan 63 sistem. Kriteria kebutuhan sistem dibuat berdasarkan analisis masalah dan solusi yang telah dibahas pada bagian sebelumnya. Berdasarkan data dokumentasi software-software implementasi IKEv2 yang dikumpulkan sampai pada saat skripsi ini dibuat, kami mendapatkan data yang dibutuhkan untuk membandingkan fitur dan kemampuan dari berbagai solusi perangkat lunak IPsec IKEv2 terhadap kriteria kebutuhan sistem yang diajukan. Berikut adalah daftar kriteria kebutuhan sistem dan perbandingan berbagai alternatif solusi perangkat lunak IPsec IKEv2. Tabel 4.5 Perbandingan perangkat lunak IKEv2 sesuai kebutuhan sistem Fitur Kebutuhan Sistem OpenIKEv2 0.9.8 IKEv2 release-2.0- alpha1 Racoon2 20090327c Strongswan

4.4.0 Openswan

2.6.8 RFC 4869 Suite B Cryptography Tidak Tidak Tidak Ya Tidak Repeated Authentication Tidak Tidak Tidak Ya bukan RFC 4478 Tidak NAT Traversal Tidak Ya Ya Ya Ya Virtual IP via config payload Ya Tidak Eksperimental Ya Ya NAT Traversal tunnel mode Ya Ya Ya Ya Ya MOBIKE Tidak Tidak Tidak Ya Tidak Sebagaimana dapat dilihat, aplikasi Strongswan dengan implementasi IKEv2-nya paling banyak memiliki fitur dan kemampuan yang memenuhi keseluruhan kriteria kebutuhan sistem yang diharapkan. Oleh karena itu, kami memutuskan untuk memilih menggunakan solusi perangkat lunak IKEv2 dari StrongSwan.

4.2 Fase Design

Fase ini merupakan fase kedua dalam proses penelitian skripsi ini. Pada fase ini, langkah yang kami lakukan adalah melakukan perancangan topologi jaringan Internet, dan perancangan skenario jaringan pengujian. 64

4.2.1 Perancangan Topologi Jaringan Internet

Skema topologi jaringan Internet yang akan menjadi dasar perancangan skenario pengujian Remote Access IPsec adalah seperti gambar berikut. Gambar 4.10 Desain Topologi Jaringan Internet Skema jaringan diatas digunakan untuk merepresentasikan keadaan jaringan WANInternet dimana terdapat LANdengan alamat IP private yang terhubung ke Internetjaringan IP publik melalui gateway. Komputer di jaringan LAN dapat mengakses jaringan IP publik melalui gateway yang bertindak sebagai router. Gateway router tersebut juga melakukan fungsi NAT agar dapat mengakomodasi kebutuhan akses internet oleh LAN. Jaringan komputer dengan nomor 10.1.0.024 dan 10.2.0.024 merepresentasikan dua buah jaringan private LAN yang saling terpisah. Jaringan komputer dengan nomor 192.168.0.024 merepresentasikan jaringan publik Internet yang menjadi media penghubung antara dua LAN yang terpisah.

4.2.2 Perancangan Skenario Pengujian

Rancangan skenario jaringan pada tahap ini dibuat untuk merepresentasikan masalah yang ada pada sistem Remote Access VPN berbasis IPsec sesuai dengan fase analysis bagian pemberian solusi. Desain skenario jaringan pengujian ini nantinya akan digunakan dalam pengujian sistem. 10.1.0.024 publik .2 10.2.0.024 .10 .1 GW1 GW2 .3 .1 192.168.0.024 A B NAT NAT LAN 1 LAN 2 private private 65 Tabel 4.6 Masalah, solusi, dan skenario pengujian sistem No Masalah yang dihadapi Solusi yang diberikan Skenario Pengujian 1 Kebutuhan algoritma kriptografi yang kuat Algoritma kriptografi suite B Skenario Algoritma Suite B 2 Pengulangan autentikasi repeated authentication Skenario Repeated Authentication 3 Ketidakcocokan NAT- IPsec NAT Traversal Skenario NAT Traversal 4 Alamat Klien IPsec yang overlapping Virtual IP Skenario Virtual IP 5 NAT Traversal Mode Transport Tunnel Mode policy Skenario Dua Roadwarrior Tunnel Mode 6 Peer IPsec yang mobile dan multihoming MOBIKE Skenario MOBIKE

4.2.2.1 Skenario Pengujian Algoritma Suite B

Pengujian Algoritma Kriptografi bertujuan untuk menguji kemampuan dukungan terhadap algoritma kripografi Suite B sesuai RFC 4869. GW1 bertindak sebagai initiator dan GW2 sebagai responder. Gambar 4.11 Skema Pengujian Algoritma Suite B Pada skenario ini, empat macam cryptographic user interface suites UI Suites akan diuji yaitu Suite-B-GCM-128 , Suite-B-GCM-256 , Suite-B-GMAC-128 , dan Suite-B-GMAC-256 .

4.2.2.2 Skenario Pengujian Repeated Authentication

Pengujian Repeated Authentication bertujuan untuk menguji kemampuan autentikasi ulang dalam satu kurun waktu yang telah ditentukan sesuai dengan RFC 4478. GW1 bertindak sebagai initiator dan GW2 sebagai responder. .1 GW1 GW2 .2 192.168.0.024 Tunnel VPN 66 Gambar 4.12 Skema Pengujian Repeated Authentication RFC4478 menetapkan waktu autentikasi ulang yang reasonable yaitu dalam rentang 300 detik5 menit sampai dengan 86400 detik24 jam. Akan tetapi, demi kepentingan pengujian semata, kami mengatur skenario dimana initiator GW2 menetapkan lifetime IKE sebesar 60 menit dan responder GW1 menetapkan lifetime IKE sebesar 30 detik. Proses re-autentikasi akan dilakukan sesuai dengan ketetapan waktu yang lebih kecil yaitu 30 detik.

4.2.2.3 Skenario Pengujian NAT Traversal

Pengujian NAT Traversal bertujuan untuk menguji kemampuan NAT Traversal antara suatu host remote dibelakang NAT dengan suatu gatewayserver IPsec dibelakang NAT pula. Gambar 4.13 Skema Pengujian NAT Traversal Ini merupakan skenario kasus yang umum dimana host remote dibelakang NAT ingin berkomunikasi secara aman dengan satu gateway IPsec. Akan tetapi .1 GW1 GW2 .2 192.168.0.024 Tunnel VPN 10.1.0.024 .1 10.2.0.024 .10 .1 GW1 GW2 .2 .1 192.168.0.024 A B NAT VPN LAN 1 LAN 2 Tunnel VPN NAT .10 67 berbeda dengan kondisi umum dimana server memiliki IP publik, gatewayserver IPsec justru juga berada dibelakang NAT. Dengan demikian kedua endpoint IPsec yang akan membangun tunnel berada dibelakang NAT situasi double NAT. Mekanisme source NAT diterapkan pada host IPsec A sedangkan mekanisme destination NAT diterapkan pada Server IPsec B.

4.2.2.4 Skenario Pengujian Virtual IP

Pengujian Virtual IP bertujuan untuk menguji kemampuan membangun suatu komunikasi VPN berbasis IPsec antara pengguna yang bersifat remote atau roadwarrior yang berada dibelakang subnet yang berbeda tetapi beralamat IP yang sama, dengan sebuah gatewayserver IPsec. Gambar 4.14 Skema Pengujian Virtual IP Skenario jaringan ini akan digunakan untuk menguji masalah alamat klien IPsec yang overlapping pada NAT Traversal mode operasi tunnel. Host IPsec A dan Z akan membangun tunnel IPsec kepada Server IPsec GW2. NAT-Traversal enkapsulasi UDP akan digunakan dalam proses pembangunan tunnel IPsec. Virtual IP melalui configuration payload akan digunakan untuk mengatasi 10.1.0.024 .1 10.2.0.024 .10 .1 GW1 GW2 .2 .1 192.168.0.024 A B NAT VPN server LAN 1 LAN 2 Tunnel VPN Z .10 Tunnel VPN LAN 3 GW3 NAT .1 .3 .10 10.1.0.024 68 masalah alamat klien IPsec yang overlapping. Mekanisme source NAT diterapkan pada host IPsec A dan Z.

4.2.2.5 Skenario Dua Roadwarrior Tunnel Mode

Pengujian Dua Roadwarrior Same NAT Tunnel Mode bertujuan untuk menguji kemampuan membangun suatu komunikasi VPN berbasis IPsec antara dua pengguna yang bersifat remote atau roadwarrior yang berada dibelakang sebuah NAT dengan sebuah gatewayserver IPsec. Tunnel IPsec yang akan dibangun disetting untuk berjalan pada mode operasi tunnel. Gambar 4.15 Skema Pengujian Dua Roadwarrior Tunnel Mode Skenario jaringan ini akan digunakan untuk menguji masalah konflik pada NAT Traversal mode operasi transport. Host IPsec A dan B akan membangun tunnel IPsec kepada Server IPsec GW2. NAT-Traversal enkapsulasi UDP akan digunakan dalam proses pembangunan tunnel IPsec. Mode operasi tunnel akan digunakan sebagai setting konfigurasi default. Mekanisme source NAT diterapkan pada host IPsec A dan B. 10.1.0.024 .1 .10 GW1 GW2 .2 .1 192.168.0.024 A NAT VPN server LAN 1 Tunnel VPN B .20 Tunnel VPN 69

4.2.2.6 Skenario Pengujian MOBIKE

Pengujian MOBIKE bertujuan untuk menguji kemampuan MOBIKE antara satu pengguna yang bersifat remote atau disebut juga roadwarrior yang bersifat multihomed terhubung ke beberapa jaringan. Gambar 4.16 Skema Pengujian MOBIKE Dalam skenario ini, pertama-tama, Host A akan membangun tunnel IPsec dengan GW2 dengan interface IP 192.168.0.100. Kemudian, beberapa saat kemudian interface IP tersebut down sehingga klien A hanya terhubung ke jaringan ke LAN1 dengan interface IP 10.1.0.10. Sesuai dengan protokol MOBIKE, suatu pesan notifikasi akan dikirimkan ke Server GW2 melalui route path yang ada untuk memperbaharui alamat IP Security Association. Koneksi IPsec yang telah dibangun dapat tetap dipertahankan dan tak perlu membuat ulang tunnel IPsecIKE SA baru.

4.3 Fase Simulation Prototyping

Fase ini merupakan fase ketiga dalam proses penelitian skripsi ini. Pada fase ini, langkah yang kami lakukan adalah membuat simulasi jaringan komputer, menerapkan perangkat lunak, pengujian sistem, dan evaluasi. A 10.1.0.024 10.2.0.024 .1 GW1 GW2 .2 .1 192.168.0.024 B NAT VPN server LAN 1 LAN 2 Tunnel VPN .10 .1 .100 .1 70

4.3.1 Pembuatan Simulasi Jaringan Internet

Pada bagian ini akan dilakukan pembuatan simulasi sistem jaringan komputer yang merepresentasikan jaringan Internet yang terdiri dari beberapa komputer dengan menggunakan tool virtualisasi VMware Workstation.

4.3.1.1 Instalasi VMware Workstation

VMware Workstation adalah suatu software virtualisasi yang memungkinan penjalanan beberapa sistem operasi pada saat bersamaan diatas suatu komputer berbasis arsitektur Intel x86. VMware Workstation diinstal pada sistem operasi dasar yang disebut Host OS dan kemudian beberapa sistem operasi lain disebut Guest OS dapat diinstal diatas Host OS tersebut. Pada skripsi ini VMware diinstal pada sistem operasi dasar Ms. Windows XP SP2 dan kemudian beberapa sistem operasi Fedora 9 diinstal diatas OS Windows itu dengan menggunakan virtualisasi VMware Workstation. Proses Instalasi VMware Workstation untuk Windows cukup mudah, cukup jalankan file installer dan ikuti petunjuk instalasi. Gambar 4.17 Instalasi VMware Workstation Berikut adalah tampilan interface dari VMware Workstation. 71 Gambar 4.18 Tampilan VMware Workstation

4.3.1.2 Simulasi Jaringan Internet Dengan VMware VMnet

VMware mampu mengakomodasi pembangunan suatu jaringan virtual dengan tools Virtual Network Editor yang bisa diakses melalui EditVirtual Network Settings. Gambar 4.19 Virtual Network Editor Suatu Virtual Network atau jaringan virtual disediakan oleh VMware melalui fitur VMnet. Setiap VMnet merepresentasikan satu jaringan virtual. Host OS dapat mengakses sebuah VMnet melalui Host Virtual Adapter yang disediakan VMware. Sedangkan Guest OS mendapat akses ke VMnet melalui setting adapter pada virtual machine. 72 Gambar 4.20 Desain Simulasi Jaringan Internet dengan VMware Guest OS yang akan diinstal dengan VMware akan menjalankan sistem operasi Fedora 9 berkernel Linux 2.6.24. Ada OS yang berperan sebagai Router GatewayGW1 dan GW2 dengan fungsi NAT dan ada OS yang berperan sebagai Host LANA dan B. Terdapat tiga jaringan IP yaitu LAN110.1.0.024 yang direpresentasikan dengan VMnet1, jaringan Internet192.168.0.024 yang direpresentasikan dengan VMnet2, dan jaringan LAN210.2.0.024 yang direpresentasikan dengan VMnet3.

4.3.1.3 Pembuatan Virtual Machine

Untuk membuat virtual machine gunakan tool New Virtual Machine, selanjutnya pilih opsi “Custom”, 10.1.0.024 Internet .2 10.2.0.024 .10 .1 GW1 GW2 .3 .1 202.0.0.024 A B NAT NAT LAN 1 LAN 2 HOST OS GUEST OS GUEST OS GUEST OS GUEST OS A GW1 GW2 B VMNET1 Host Virtual Adapter VMNET3 VMNET2 = Host ethernet adapter = Guest ethernet adapter 73 Gambar 4.21 Pemilihan Guest OS Beri nama untuk host tersebut “A”. Gunakan setidaknya memori sebesar 128 MB yang mencukupi untuk instalasi Linux sebagai router dengan text-mode dan kemudian pada pilihan Network Connection pilih “Use host-only networking”. Gambar 4.22 Tipe Koneksi Jaringan untuk Virtual Machine Setelah selesai membuat sebuah virtual machine, ulangi langkah tersebut diatas hingga semua kebutuhan empat Guest OS terpenuhi yaitu A, B, GW1, dan GW2. 74 Gambar 4.23 Tampilan Virtual Machine Langkah pembuatan virtual machine diatas diulangi terus untuk membuat setiap komputer yang dibutuhkan dalam proses pengujian.

4.3.1.4 Konfigurasi Jaringan Virtual

Setelah pembuatan virtual machine selesai, langkah selanjutnya adalah konfigurasi jaringan virtual. Gunakan “edit virtual machine settings” untuk melakukan penyesuaian adapter Ethernet pada virtual machine. Ubah setting Ethernet menjadi “Custom” dan sesuaikan dengan kebutuhan jaringan virtual. Gambar 4.24 Setting Jaringan pada Virtual Machine Seperti terlihat pada gambar, GW1 dan GW2 memiliki dua adapter Ethernet. Untuk membuat adapter Ethernet baru bagi GW1 dan GW2 gunakan “Add Hardware Wizard” dan pilih Ethernet Adapter. GW1 GW2 A B A eth1: VMnet1 B eth1 : VMnet3 GW1 eth0 : VMnet2 eth1 : VMnet1 GW1 eth0 : VMnet2 eth1 : VMnet3 VMNET1 VMNET2 VMNET3 75

4.3.2 Penerapan Perangkat Lunak

Pada bagian ini, perangkat lunak openSSL dan strongSwan akan diterapkan pada sistem Linux. Perangkat lunak openSSL digunakan dalam membangun sistem Public Key Certificate X.509 berbasis signature ECDSA. Sedangkan perangkat lunak strongSwan berperan sebagai penyedia layanan protokol IKEv2.

4.3.2.1 Pembuatan X.509 Certificate berbasis Signature ECDSA

Untuk membuat sistem PKI Public Key Infrastructure X.509, digunakan toolkit OpenSSL. OpenSSL merupakan perangkat lunak open source dan free yang mengimplementasikan protokol SSLv2v3Secure Socket Layer version2version3 dan TLSv1Transport Layer Security version 1 serta standar kriptografi yang berkaitan dengan protokol tersebut. OpenSSL dapat diperoleh melalui situs http:www.openssl.org. OpenSSL yang dipakai disini adalah versi 1.0.0. Untuk menginstal OpenSSL dari sourceformat tar.gz, pertama-tama paket yang berbentuk archive terkompresi harus diekstrak ke suatu direktori tertentu seperti home. mv openssl-1.0.0.tar.gz home cd home tar –xzvf strongswan-4.2.5.tar.gz Kemudian lakukan kompilasi pada paket yang telah diekstrak. cd home openssl-1.0.0 .config make make test make install 76 OpenSSL akan diinstall pada default direktori usrssl. Lakukan pengecekan apakah OpenSSL telah terinstal dengan benar atau tidak dengan perintah berikut. openssl version Konfigurasi terhadap OpenSSL dilakukan melalui file usrsslopenssl.cnf.

4.3.2.2 Pembuatan Sertifikat CA

Untuk membuat sertifikat CA X.509 berbasis signature ECDSA Elliptic Curve Digital Signature Algorithm, terlebih dahulu kita membuat private key berbasis Elliptic Curve berukuran 521bit baru kemudian membuat sertifikat X.509 CA dari key tersebut. openssl ecparam -genkey -name secp521r1 -out cakey.pem openssl req –x509 –new –key cakey.pem -days 3650 -out cacert.pem Isi data untuk sertifikat x509 CA. Data tersebut adalah “Country Name”, “State or Province Name”, “Locality”, “Organization Name”, “Common Name”, dan “Email Address”. Akan ada dua file hasil dari pembuatan CA yaitu cakey.pem yang merupakan private key dan cacert.pem yang merupakan sertifikat dari CA beserta public key.

4.3.2.3 Pembuatan Sertifikat untuk End Entity

Setelah membuat self-signed certificate CA maka tugas selanjutnya adalah membuat sertifikat x509 untuk setiap komputer end entity certificate yang akan membuat koneksi IPsec. Pertama kita membuat private key elliptic curve berukuran 384bit untuk peer IPsec, setelah itu dari private key itu dibuat certificate request untuk setiap peer IPsec , dan certificate request itu kemudian di-sign oleh CA certificate yang sebelumnya telah dibuat. Berikut adalah perintahnya di konsol linux. 77 openssl ecparam -genkey -name secp384r1 -out xxxkey.pem openssl req –new –key xxxkey.pem -out xxxreq.pem Nama xxx diganti dengan nama host komputer dimana sertifikat itu diperuntukkan. Misalnya, untuk pembuatan key dan certificate request untuk host A, maka xxxkey.pem diganti menjadi akey.pem dan xxxreq.pem diganti menjadi areq.pem. Begitu pula pembuatan untuk host lainnya B, Z, GW1, GW2, GW3 sehingga didapatkan file private key akey.pem, bkey.pem, zkey.pem, gw1key.pem, gw2key.pem, gw3key.pem, dan file certificate request areq.pem, breq.pem, zreq.pem, gw1req.pem, gw2req.pem, gw3req.pem, Format isian certificate request pada dasarnya sama seperti membuat CA, tetapi kali ini data isian disesuaikan untuk host IPsec. Kemudian request sertifikat yang telah dibuat harus disign oleh sertifikat CA yang sebelumnya telah dibuat. openssl x509 –req –in xxxreq.pem –CA cacert.pem -CAkey cakey.pem -days 365 –extfile openssl.cnf –extension usr_cert -CAcreateserial -out xxxcert.pem Ganti xxx dengan nama host komputer dimana sertifikat itu diperuntukkan. Misalnya, untuk penandatanganan certificate request untuk host A, maka xxxreq.pem diganti menjadi areq.pem. xxxcert.pem diganti menjadi acert.pem dan Begitu pula penandatanganan untuk host lainnya B, Z, GW1, GW2, GW3 sehingga didapatkan file sertifikat publik x.509 acert.pem, bcert.pem, zcert.pem, gw1cert.pem, gw2cert.pem, gw3cert.pem.

4.3.2.4 Instalasi Certificate

Untuk skema pendistribusian file sertifikat X.509 dapat dilihat pada lampiran 1 Skema Jaringan Komputer dan Sertifikat X.509. Pada setiap komputer atau host IPsec yang terlibat dalam pembuatan tunnel IPsec, tempatkan file sertifikat dan private key di direktori etcipsec.d dengan aturan sebagai berikut. 78 • Direktori etcipsec.dprivate sebagai tempat untuk private key host IPsec yang sesuai. Contohnya hanya host A yang memiliki akey.pem dan host B memiliki bkey.pem, dan seterusnya. • Direktori etcipsec.dcerts sebagai tempat untuk end entity atau public certificate. Berisi seluruh file end entity certificate X.509 yaitu acert.pem, bcert.pem, zcert.pem, gw1cert.pem, gw2cert.pem, gw3cert.pem. • Direktori etcipsec.d cacerts sebagai tempat untuk CA certificate yang mengeluarkan dan men-sign end entity certificate. Berisi file cacert.pem.

4.3.2.5 Instalasi Perangkat Lunak IKEv2 strongSwan

StrongSwan merupakan solusi perangkat lunak IPsec open source untuk lingkungan sistem operasi berbasis kernel Linux. Aplikasi Strongswan yang dipakai dalam skripsi ini adalah versi 4.4.0 yang menggunakan daemon charon sebagai penyedia fungsi IKEv2. Strongswan bersifat open source berlisensi GPLv2 GNU GENERAL PUBLIC LICENSE dan dapat didownload gratis di situs resminya http:www.strongswan.org . Untuk menginstal Strongswan dari sourceformat tar.gz, pertama-tama paket yang berbentuk archive terkompresi harus diekstrak ke suatu direktori tertentu seperti home. mv strongswan-4.4.0.tar.gz home cd home tar –xzvf strongswan-4.4.0.tar.gz Kemudian lakukan kompilasi pada paket yang telah diekstrak. cd homestrongswan-4.4.0 .configure make make install 79 StrongSwan akan diinstall pada default direktori usrlocal. Lakukan pengecekan apakah strongSwan telah terinstal dengan benar atau tidak dengan perintah berikut. Dan jika tidak ada error yang muncul maka strongSwan sudah bisa digunakan. ipsec version Konfigurasi terhadap strongSwan terutama dilakukan melalui file etcipsec.conf, file secret key etcipsec.secrets. File ipsec.conf digunakan sebagai konfigurasi koneksi tunnel VPN IPsec Security Association Database dan konfigurasi policy pengamanan traffic Security Policy Database. File ipsec.secrets berisi data rahasia data credential private key yang nantinya digunakan dalam proses autentikasi peer IPsec. Proses autentikasi yang digunakan adalah sertifikat x.509 berbasis signature ECDSA.

4.3.3 Pengujian Sistem

Pengujian sistem dilakukan terhadap setiap skenario pengujian yang telah dibuat pada tahapan desain. Konfigurasi sistem IPsec adalah berbeda pada setiap skenario pengujian. Ada pengujian yang membutuhkan konfigurasi routing, dan atau juga firewall NAT. Untuk kode konfigurasi sistem remote access IPsec berbasis perangkat lunak IKEv2 strongswan dapat dilihat pada Lampiran 2. Kode Konfigurasi IKEv2 strongSwan. 4.3.3.1 Pengujian Algoritma Suite B Gateway GW1 akan membangun suatu tunnel IPsec kepada Gateway GW2. Gambar 4.25 Pengujian Algoritma Kriptografi .1 GW1 GW2 .2 192.168.0.024 80 Pembangunan dan pengujian tunnel IPsec dilakukan dengan perintah di konsol linux sebagai berikut. Untuk membangun tunnel IPsec dengan algoritma Suite B GCM-256 digunakan perintah berikut. gw1 ipsec up suite-b-gcm-256 Untuk memverifikasi apakah tunnel IPsec berhasil dibangun digunakan perintah ipsec statusall pada GW1. gw1 ipsec statusall | less Gambar 4.26 Hasil output konsol uji Algoritma Suite B pada GW1 Baris pada security association SA ”...ESTABLISHED 74 seconds ago...” menunjukkan bahwa SA IKE antara peer IKE GW1 dan GW2 berhasil dibangun. Baris ”...IKE proposal: AES_CBC_256HMAC_SHA2_384_192 PRF_HMAC_SHA2_384ECP_384...” menunjukkan bahwa untuk SA IKE, algoritma yang digunakan adalah enkripsi AES-CBC-256, algoritma HMAC- SHA-384-192, dan elliptic curve 384 bit. Baris ”...INSTALLED, TUNNEL, ESP...” menunjukkan bahwa SA untuk tunnel ESP berhasil dibuat dengan ”ESP SPI=ca09414a” untuk inbound dan”ESP SPI=c407a17b” untuk outbound. Baris ”...AES_GCM_16_256...” menunjukkan bahwa enkripsi ESP menggunakan AES- GCM-256. 4.3.3.2 Pengujian Repeated Authentication Gateway GW1 akan membangun suatu tunnel IPsec kepada Gateway GW2 dengan pengulangan autentikasi setiap 30 detik. 81 Gambar 4.27 Pengujian Repeated Authentication Pembangunan dan pengujian tunnel IPsec dilakukan dengan perintah di konsol linux sebagai berikut. gw1 ipsec up repeat-auth Untuk memverifikasi apakah tunnel IPsec berhasil dibangun digunakan perintah ipsec statusall pada GW1. gw1 ipsec statusall | less Gambar 4.28 Hasil output konsol uji Repeated Authentication pada GW1 Baris ”...scheduling reauthentication in 30s...” SA menunjukkan bahwa akan dilakukan pengulangan autentikasi secara otomatis dalam 30 detik antara peer IKE GW1 dan GW2. 4.3.3.3 Pengujian NAT Traversal A, yang berada dibelakang router NAT GW1 akan membangun suatu tunnel IPsec mode tunnel kepada B yang ada dibelakang NAT GW2. GW1 akan menerapkan fungsi Source NAT terhadap paket IPsec dari A 10.1.0.024. Sedangkan GW2 akan menerapkan fungsi Destination NAT ke B sehingga seluruh lalu-lintas paket IKE dan ESP yang ditujukan ke router GW2 akan diteruskan ke B. A bertindak sebagai klien sedangkan B bertindak sebagai server IPsec bagi .1 GW1 GW2 .2 192.168.0.024 82 subnet 10.2.0.024. NAT-Traversal enkapsulasi UDP digunakan untuk melewatkan traffic IPsec melalui NAT. Gambar 4.29 Pengujian NAT Traversal Untuk membuat aturan source NAT pada GW1 terhadap subnet 10.1.0.024 ke alamat source GW1, sehingga paket IPsec yang terenkapsulasi UDPNAT Traversal dapat lewat, digunakan perintah iptables berikut. gw1 echo 1 procsysnetipv4ip_forward gw1 iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.024 -p udp -j SNAT --to- source 192.168.0.1:2000-2100 Untuk membuat aturan destination NAT pada GW2 terhadap paket IPsec ke alamat IP B, digunakan perintah iptables berikut. gw2 echo 1 procsysnetipv4ip_forward gw2 iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.1 -p udp -j DNAT --to- destination 10.2.0.10 gw2 ip route add 10.1.0.024 via 10.2.0.10 Pembangunan dan pengujian tunnel IPsec dilakukan dengan perintah di konsol linux sebagai berikut. a ipsec up nat-traversal Untuk memverifikasi apakah tunnel IPsec berhasil dibangun digunakan perintah ipsec statusall pada host A. a ipsec statusall | less 10.1.0.024 .1 10.2.0.024 .10 .1 GW1 GW2 .2 .1 192.168.0.024 A B NAT VPN NAT .10 83 Gambar 4.30 Hasil output konsol uji NAT Traversal pada Host A Baris pada security association SA ”...ESTABLISHED 71 seconds ago...” menunjukkan bahwa SA IKE antara peer IKE A dan B berhasil dibangun. Baris ”...INSTALLED, TUNNEL, ESP in UDP...” menunjukkan bahwa SA untuk tunnel ESP berhasil dibuat dalam mode NAT Traversal yaitu dengan mekanisme enkapsulasi UDP yang berarti bahwa host IPsec berada dibelakang NAT dengan ”ESP SPI=cf03cf23” untuk inbound dan”ESP SPI=c7f05510” untuk outbound. Baris ”...AES_CBC_128HMAC_SHA1_96...” menunjukkan bahwa tunnel ESP dilindungi dengan enkripsi AES-CBC-128. 4.3.3.4 Pengujian Virtual IP A dan Z berperan sebagai roadwarrior remote client yang masing- masing berada di belakang Router NAT GW1 dan GW3. Suatu tunnel IPsec mode tunnel akan dibangun antara A - GW2 dan Z - GW2. A dan Z akan memiliki alamat IP address private yang sama yaitu 10.0.1.1024. Masing-masing roadwarrior tersebut meminta sebuah virtual IP melalui configuration payload IKEv2. Gatewayserver IPsec GW2 kemudian memberikan alamat virtual IP yang unik. 84 Gambar 4.31 Pengujian Virtual IP Untuk membuat aturan source NAT pada GW1 dan GW3 terhadap subnet masing-masing, sehingga paket IPsec yang terenkapsulasi UDPNAT Traversal dapat lewat, digunakan perintah iptables berikut. gw1 echo 1 procsysnetipv4ip_forward gw1 iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.024 -p udp -j SNAT --to- source 192.168.0.1:2000-2100 gw3 echo 1 procsysnetipv4ip_forward gw3 iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.024 -p udp -j SNAT --to- source 192.168.0.3:2000-2100 Pembangunan dan pengujian tunnel IPsec dilakukan dengan perintah di konsol linux sebagai berikut. a ipsec up virtual-ip z ipsec up virtual-ip Untuk memverifikasi apakah tunnel IPsec berhasil dibangun digunakan perintah ipsec statusall pada A dan Z. a ipsec statusall | less z ipsec statusall | less Gambar 4.32 Hasil output konsol uji Virtual IP pada A Baris pada security association SA ”...ESTABLISHED 2 minutes ago...” menunjukkan bahwa SA IKE antara peer IKE A dan GW2 berhasil dibangun. 10.1.0.024 .1 10.2.0.024 .10 .1 GW1 GW2 .2 .1 192.168.0.024 A B NAT VPN server Z .10 GW3 NAT .1 .3 .10 10.1.0.024 85 Baris ”...INSTALLED, TUNNEL, ESP in UDP...” menunjukkan bahwa SA untuk tunnel ESP berhasil dibuat dalam mode NAT Traversal yaitu dengan mekanisme enkapsulasi UDP yang berarti bahwa host IPsec A berada dibelakang NAT dengan ”ESP SPI=ce51c3a8” untuk inbound dan”ESP SPI=c90d7e99” untuk outbound. Baris ”...AES_CBC_128HMAC_SHA1_96...” menunjukkan bahwa tunnel ESP dilindungi dengan enkripsi AES-CBC-128. Baris ”...virtual-ip2 : 10.10.0.132 == 10.2.0.024...” menunjukkan bahwa Host A mendapatkan virtual IP 10.10.0.1, dan trafic selector dibuat antara alamat virtual A 10.10.0.132 dengan subnet 10.2.0.024. Gambar 4.33 Hasil output konsol uji Virtual IP pada Host Z Baris pada security association SA ”...ESTABLISHED 10 minutes ago...” menunjukkan bahwa SA IKE antara peer IKE Z dan GW2 berhasil dibangun. Baris ”...INSTALLED, TUNNEL, ESP in UDP...” menunjukkan bahwa SA untuk tunnel ESP berhasil dibuat dalam mode NAT Traversal yaitu dengan mekanisme enkapsulasi UDP yang berarti bahwa host IPsec Z berada dibelakang NAT dengan ”ESP SPI=c9518939” untuk inbound dan”ESP SPI=ce5b481e” untuk outbound. Baris ”...AES_CBC_128HMAC_SHA1_96...” menunjukkan bahwa tunnel ESP dilindungi dengan enkripsi AES-CBC-128. Baris ”...virtual- ip2 : 10.10.0.232 == 10.2.0.024...” menunjukkan bahwa Host Z mendapatkan virtual IP 10.10.0.2, dan trafic selector dibuat antara alamat virtual Z 10.10.0.132 dengan subnet 10.2.0.024. 86 4.3.3.5 Pengujian Dua Roadwarrior Tunnel Mode A dan B berperan sebagai roadwarrior remote user yang berada di belakang Router NAT GW1. Suatu tunnel IPsec akan dibangun antara A - GW2 dan B - GW2. GW2 akan bertindak sebagai gatewayserver IPsec. NAT-Traversal enkapsulasi UDP digunakan untuk melewatkan traffic IPsec melalui NAT. Gambar 4.34 Pengujian Dua Roadwarrior Tunnel Mode Untuk membuat aturan source NAT pada GW1 terhadap subnet 10.1.0.024 ke alamat source GW1, sehingga paket IPsec yang terenkapsulasi UDPNAT Traversal dapat lewat, digunakan perintah iptables berikut. gw1 echo 1 procsysnetipv4ip_forward gw1 iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.024 -p udp -j SNAT --to- source 202.0.0.1:2000-2100 Policy atau kebijakan mode tunnel dibuat dengan melakukan konfigurasi “mode=tunnel” pada perangkat lunak IKEv2 strongSwan seperti bisa dilihat pada Lampiran 2. Kode Konfigurasi IKEv2 strongSwan pada nomor 5.Pengujian Dua Roadwarrior Tunnel Mode. Pembangunan dan pengujian tunnel IPsec dilakukan dengan perintah di konsol linux sebagai berikut. a ipsec up duarw-samenat b ipsec up duarw-samenat Untuk memverifikasi apakah tunnel IPsec berhasil dibangun digunakan perintah ipsec statusall pada A dan B. a ipsec statusall | less b ipsec statusall | less 10.1.0.024 .1 .10 GW1 GW2 .2 .1 192.168.0.024 A NAT VPN server B .20 87 Gambar 4.35 Hasil output konsol uji Dua Roadwarrior Tunnel Mode A Baris”...ESTABLISHED 21 seconds ago...” menunjukkan bahwa SA IKE antara peer IKE A dan GW2 berhasil dibangun. Baris ”...INSTALLED, TUNNEL, ESP in UDP...” menunjukkan bahwa SA untuk tunnel ESP berhasil dibuat dalam mode NAT Traversal yaitu dengan mekanisme enkapsulasi UDP yang berarti bahwa host IPsec A berada dibelakang NAT dengan ”ESP SPI=c313c374” untuk inbound dan”ESP SPI=cdc95cc2” untuk outbound. Baris ”...AES_CBC_128HMAC_SHA1_96...” menunjukkan bahwa tunnel ESP dilindungi dengan enkripsi AES-CBC-128. Gambar 4.36 Hasil output konsol uji Dua Roadwarrior Tunnel Mode B Baris pada security association SA ”...ESTABLISHED 36 seconds ago...” menunjukkan bahwa SA IKE antara peer IKE B dan GW2 berhasil dibangun. Baris ”...INSTALLED, TUNNEL, ESP in UDP...” menunjukkan bahwa SA untuk tunnel ESP berhasil dibuat dalam mode NAT Traversal yaitu dengan 88 mekanisme enkapsulasi UDP yang berarti bahwa host IPsec B berada dibelakang NAT dengan ”ESP SPI=c1931ce5” untuk inbound dan”ESP SPI=ca01271f” untuk outbound. Baris ”...AES_CBC_128HMAC_SHA1_96...” menunjukkan bahwa tunnel ESP dilindungi dengan enkripsi AES-CBC-128. 4.3.3.6 Pengujian MOBIKE A berperan sebagai roadwarrior remote user yang terhubung pada jaringan 192.168.0.024 dan jaringan 10.1.0.024. Suatu tunnel IPsec mode tunnel host-to-network akan dibangun antara A - GW2 melalui IP 192.168.0.100. Interface dengan alamat IP 192.168.0.100 itu kemudian down sehingga A hanya terhubung pada jaringan 10.1.0.024 dengan alamat IP 10.1.0.10. A kemudian akan mengirimkan pesan notifikasi IKE kepada server GW2 untuk memberitahukan perubahan alamat IP SA sehingga SA yang lama tetap dapat dipertahankan tanpa adanya pembuatan ulang tunnel. Gambar 4.37 Pengujian MOBIKE Untuk membuat aturan source NAT pada GW1 terhadap subnet dibelakangnya, sehingga paket IPsec yang terenkapsulasi UDPNAT Traversal dapat lewat, digunakan perintah iptables berikut. gw1 echo 1 procsysnetipv4ip_forward gw1 iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.024 -p udp -j SNAT --to- source 202.0.0.1:2000-2100 Pembangunan dan pengujian tunnel IPsec dilakukan dengan perintah di konsol linux sebagai berikut. a ipsec up mobike .100 10.2.0.024 .1 GW2 .2 .10 192.168.0.024 A B VPN server GW1 NAT .1 .1 .10 10.1.0.024 89 Gambar 4.38 Output awal pada A dengan IP 192.169.0.100 Baris pada security association SA ”...IKE_SA mobike4 established between 192.168.0.100...” menunjukkan bahwa SA IKE antara A dan GW2 berhasil dibangun antara alamat IP 192.168.0.100ates.co.id... 192.168.0.2gw2tes.co.id. Untuk membuat interface 192.168.0.100 mati dan untuk memverifikasi jika tunnel IPsec masih tetap ada dapat digunakan perintah berikut pada A. interface jaringan 192.168.0.100 disimulasikan mati a ifconfig eth1 192.168.0.10024 down a ipsec statusall | less Gambar 4.39 Output pada A setelah interface 192.169.0.100 down. Baris pada security association SA ”...ESTABLISHED 103 seconds ago, 10.1.0.10ates.co.id...” menunjukkan bahwa SA IKE antara peer IKE A dan GW2 masih tetap ada. Perubahan terjadi pada data alamat SA IKE dimana sebelumnya yaitu antara alamat IP 192.168.0.100 ates.co.id dengan 90 192.168.0.2 gw2tes.co.id, menjadi alamat IP 10.1.0.10 ates.co.id dengan 192.168.0.2 gw2tes.co.id.

4.3.4 Evaluasi

Hasil dari pengujian simulasi sistem Remote Access IPsec berbasis perangkat lunak IKEv2 strongSwan dapat dilihat melalui tabel berikut. Tabel 4.7 Hasil Pengujian Sistem No Solusi Hasil Pengujian 1 Algoritma Suite B Suite-B-gcm-128 Berhasil Suite-B-gcm-256 Berhasil Suite-B-gmac-128 Tidak Berhasil Suite-B-gmac-256 Tidak Berhasil 2 Repeated Authentication Berhasil 3 NAT Traversal Berhasil 4 Virtual IP Berhasil 5 Dua Roadwarrior Tunnel Mode Berhasil 6 MOBIKE Berhasil

4.3.4.1 Pengujian Algoritma Suite B

Hasil dari pengujian Suite B menunjukkan bahwa algoritma kriptografi Galouis-Counter Mode GCM berhasil dijalankan, akan tetapi mode GMAC tidak berjalan. Algoritma kriptografi GCM menyediakan standar layanan enkripsi yang kuat sesuai dengan spesifikasi suite B sehingga walaupun pengujian GMAC tidak berhasil, mode GCM pun sudah cukup untuk memenuhi kebutuhan pengamanan data.

4.3.4.2 Pengujian Repeated Authentication

Mekanisme Repeated Authentication pada strongSwan dapat berjalan dengan lancar sesuai dengan hasil pengujian. Dengan demikian, kebutuhan pengulangan autentikasi bagi pengguna VPN khususnya remote access berbasis IPsec dapat dipenuhi. 91

4.3.4.3 Pengujian NAT Traversal

Protokol IKEv2 secara default sudah mendukung NAT Traversal dengan mekanisme enkapsulasi UDP. Fungsi NAT Traversal IKEv2 pada perangkat lunak strongSwan dapat berjalan baik sesuai dengan hasil pengujian. Dengan demikian, pengguna remote access VPN berbasis IPsec khususnya pengguna yang berada dibelakang NAT dapat membangun suatu tunnel IPsec.

4.3.4.4 Pengujian Virtual IP

Mekanisme Virtual IP merupakan mekanisme dalam protokol IKEv2 yang mampu mengatasi permasalahan konflik overlapping internal IP address pada komunikasi IPsec Mode NAT Traversal. Perangkat lunak IKEv2 strongSwan terbukti dapat menjalankan fungsi Virtual IP dengan baik.

4.3.4.5 Pengujian NAT Traversal Tunnel Mode

Pengujian NAT Traversal mode tunnel pada IKEv2 strongSwan dapat berjalan dengan baik. IKEv2 pada StrongSwan mendukung NAT Traversal mode tunnel secara default sehingga permasalahan konflik NAT Traversal mode transport tidak akan muncul. Selain itu, strongSwan IKEv2 tidak mendukung NAT Traversal mode transport secara default dikarenakan pertimbangan keamanan sesuai dengan dokumentasi resminya yang didapat melalui halaman situsnya yaitu http:www.strongswan.orgFAQ.

4.3.4.6 Pengujian MOBIKE

Fitur MOBIKE berjalan lancar pada Strongswan dilihat dari hasil pengujian yang menunjukkan keberhasilan. Dengan demikian, kebutuhan peer IPsec yang mobile dan multihoming dapat dipenuhi. 92 BAB V KESIMPULAN DAN SARAN

5.1 Kesimpulan

Berikut adalah hasil kesimpulan yang penulis dapatkan dalam proses penelitian skripsi ini : 1. Terdapat masalah-masalah yang berhasil ditemukan untuk penerapan Remote Access VPN berbasis IPsec seperti masalah kebutuhan algoritma kriptografi yang kuat, kebutuhan pengulangan autentikasi, masalah ketidakcocokan Network Address Translator NAT dan IPsec, masalah konflik alamat klien IPsec yang overlapping, masalah NAT Traversal mode transport, masalah kebutuhan peer IPsec yang mobile dan multihoming. Hal tersebut dapat dilihat pada fase analysis bagian penentuan masalah. 2. Sistem Remote Access IPsec berbasis perangkat lunak IKEv2 strongSwan menawarkan alternatif sistem yang open source, berbiaya murah, dan mampu memberikan solusi terhadap permasalahan Remote Access VPN berbasis IPsec. Solusi untuk masalah Remote Access IPsec yang diberikan oleh perangkat lunak IKEv2 strongSwan dapat dilihat pada tabel 4.7. 3. Tool virtualisasi VMware dapat digunakan untuk membuat simulasi jaringan komputer sesuai dengan desain skenario pengujian yang dibuat pada bagian 4.2.2 Perancangan Skenario Pengujian. 4. Hasil pengujian sistem menunjukkan bahwa sistem Remote Access IPsec berbasis perangkat lunak IKEv2 strongSwan umumnya mampu berjalan pada setiap skenario pengujian. Hasil pengujian skenario suite B algorithm dapat dilihat pada gambar 4.26, skenario repeated authentication dapat dilihat pada 93 gambar 4.28, skenario NAT Traversal dapat dilihat pada gambar 4.30, skenario virtual IP dapat dilihat pada gambar 4.32 dan gambar 4.33, skenario Dua roadwarrior tunnel mode dapat dilihat pada gambar 4.35 dan gambar 4.36, skenario MOBIKE dapat dilihat pada gambar 4.38 dan gambar 4.39.

5.2 Saran