AWS Client VPN atau VPN di EC2: buku kerja operasional

Kedua opsi memberi tim Anda VPN akses jarak jauh, jadi pertanyaan yang menarik bukanlah mana yang ada, melainkan mana yang dapat Anda operasikan. Perbedaannya adalah siapa yang memiliki endpoint pada pukul 3 dini hari dan kontrol mana yang dapat Anda jangkau saat ada yang rusak. Jalankan lima langkah di bawah ini secara berurutan, karena masing-masing dapat mengakhiri perbandingan lebih awal. Melewati langkah inventaris adalah cara tim berakhir dengan migrasi dua kali.

Langkah 1: tulis persyaratannya sebelum tagihannya

Anda perlu lima fakta dalam satu halaman: siapa yang mengautentikasi dan terhadap apa, platform klien mana yang harus berfungsi, tujuan privat mana yang dapat dijangkau, ketersediaan apa yang Anda janjikan, dan bagaimana lalu lintas sebenarnya. Tanpa itu, setiap perbandingan berikutnya berubah menjadi debat daftar fitur.

Bersikaplah konkret soal tujuan. «Akses ke VPC» biasanya berarti tiga hal berbeda: CIDR VPC, jaringan yang di-peer, dan rentang on-premises di balik Transit Gateway. Endpoint terkelola dapat menjangkau ketiganya, tetapi masing-masing memerlukan rute dan aturan otorisasi, dan masing-masing adalah baris terpisah dalam persyaratan Anda.

Langkah 2: daftar apa yang sudah berjalan

Sebelum merancang apa pun, daftar endpoint yang ada dan setiap server yang dihosting di EC2 beserta grup keamanannya. Panggilan ini hanya-baca dan aman dijalankan dari akun dengan izin describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Baca outputnya sebagai peta atas apa yang sudah dapat dijangkau klien. Aturan otorisasi yang hilang menjelaskan kegagalan yang tampak seperti masalah perutean, dan endpoint yang terkait dengan satu subnet menjelaskan mengapa kegagalan zona menjatuhkan seluruh layanan.

Catat juga grup keamanan yang terpasang pada setiap instans yang dihosting sendiri. Aturan itu adalah bagian dari model akses, dan itulah hal pertama yang diam-diam rusak ketika seseorang membangun ulang instans dari templat.

Langkah 3: bagi tanggung jawabnya

Layanan terkelola memiliki armada endpoint, patch-nya, dan ketersediaannya di dalam region. Anda memiliki pendaftaran identitas, aturan otorisasi, jalur jaringan di balik endpoint, konfigurasi log, dan keputusan berapa banyak subnet yang akan diasosiasikan.

Hosting sendiri membalik itu. Anda memiliki sistem operasi tamu, daemon VPN dan konfigurasinya, sertifikat dan kunci, cadangan, pemantauan, dan pemulihan. Model keamanan EC2 menaruh keamanan tamu dan aplikasi pada pelanggan, dan server VPN adalah tamu seperti tamu lainnya.

Tuliskan pembagiannya sebagai tabel dengan nama di kolom kanan. Jika tidak ada nama yang muncul di samping perpanjangan sertifikat, itulah temuannya, dan itu lebih penting daripada selisih biaya per jam.

Langkah 4: bandingkan dengan beban kerja yang dapat Anda jelaskan

Biaya mengikuti bentuk, bukan ukuran. Untuk opsi terkelola, hitung jam asosiasi endpoint, jam koneksi klien, transfer, serta layanan identitas dan log yang Anda aktifkan. Untuk hosting sendiri, hitung komputasi, penyimpanan, jaringan, lisensi, dan waktu rekayasa yang menjaga server tetap di-patch. Taruh kedua kumpulan angka di satu lembar dengan horizon waktu yang sama. Perbandingan tiga tahun yang mengabaikan jam patch akan selalu memihak server yang sudah Anda miliki.

Perbandingan kinerja memerlukan disiplin yang sama. Satu sesi desktop interaktif, satu transfer besar, dan lima puluh permintaan kecil bersamaan membebani bagian berbeda dari jalur: CPU untuk enkripsi, kemampuan jaringan instans, tumpukan milik klien, dan tujuan. Uji dengan klien yang representatif dan tugas yang sama pada kedua desain.

Instans yang lebih besar bukan bukti bahwa transfer akan lebih cepat, dan satu sesi yang berhasil bukan rencana kapasitas. Perlakukan cerita warisan apa pun tentang keluarga instans sebagai hipotesis untuk diuji, bukan aturan pembelian.

Langkah 5: cutover dengan rollback yang sudah Anda jalankan

Jalankan kedua endpoint secara paralel untuk periode yang ditentukan, bagikan profil klien baru ke kelompok kecil terlebih dahulu, dan biarkan aturan otorisasi endpoint lama tidak tersentuh sampai kelompok tersebut memakai yang baru untuk pekerjaan nyata. Rollback adalah pergantian profil, bukan pembangunan ulang, jadi putuskan sekarang di mana profil lama berada.

Verifikasi dalam urutan ini: autentikasi berhasil, klien menerima rute yang diharapkan, tujuan yang diotorisasi menjawab dan tujuan yang tidak diotorisasi gagal, dan log menunjukkan kedua peristiwa. Jika ada langkah yang gagal, berhenti dan perbaiki langkah itu alih-alih beralih ke kelompok klien berikutnya. Catat hasil setiap pemeriksaan, karena cutover yang hanya diingat sebagai «berhasil» tidak dapat di-debug sebulan kemudian.

Setelah cutover, jadwalkan pemeriksaan yang membosankan: kedaluwarsa sertifikat, jumlah asosiasi, aturan otorisasi yang tidak lagi cocok dengan grup, dan jumlah koneksi terhadap ekspektasi Anda. Panduan administrasi Client VPN adalah referensi untuk bagian endpoint, autentikasi, dan perutean yang Anda konfigurasi.