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