EC2 di seluruh zona ketersediaan: periksa perutean sebelum VPN

Sebelum memasang perangkat lunak VPN antara dua instans EC2, jawab satu pertanyaan: apakah keduanya berada di VPC yang sama? Jika ya, jalur privat sudah ada dan penempatan lintas zona tidak mengubahnya. Sebagian besar pekerjaan dalam situasi ini adalah memastikan tabel rute mana yang benar-benar digunakan setiap subnet, lalu mencari tahu apakah kegagalan itu memang masalah perutean. Terowongan biasanya jawaban yang salah untuk pertanyaan khusus ini.

Pemeriksaan 1: VPC yang sama atau VPC berbeda

VPC bersifat regional dan mencakup zona ketersediaan, sedangkan setiap subnet termasuk tepat satu zona. Dua instans di zona berbeda dari satu VPC tetap berada di dalam domain perutean privat yang sama.

VPC yang berbeda tidak pernah memperoleh rute privat hanya karena berbagi wilayah atau label zona. Kasus itu memerlukan koneksi yang didukung dan pekerjaan rute serta izin tersendiri, yang merupakan keputusan terpisah.

Pemeriksaan 2: apa kata tabel rute subnet

Tuliskan tata letaknya dengan nilai nyata. Sebuah VPC di 10.60.0.0/16 dengan subnet 10.60.1.0/24 dan 10.60.2.0/24 memberi instans 10.60.1.10 dan 10.60.2.20 jalur melalui rute lokal VPC.

Lalu periksa tabel yang terkait dengan kedua subnet, bukan hanya yang pertama Anda temukan. Rute inspeksi atau perangkat yang lebih spesifik dapat mengalahkan rute dasar, dan target rute lokal itu sendiri dapat diganti pada konfigurasi yang lebih baru. Rute lokal yang terlihat di suatu tempat di konsol tidak membuktikan bahwa kedua beban kerja memakainya.

Gunakan alamat dan nama privat yang benar-benar diberikan VPC. Alamat privat tidak harus dimulai dengan 10, dan mengarangnya dari ingatan adalah cara sebuah lingkungan yang berfungsi salah didiagnosis.

Pemeriksaan 3: perutean atau otorisasi

Perutean hanya mengantar paket ke antarmuka jaringan target. Grup keamanan target masih harus mengizinkan sumber dan layanan, aturan keluar sumber harus mengizinkan permintaan, dan ACL jaringan apa pun harus mengizinkan kedua arah karena ACL tidak menyimpan status.

Di balik itu ada firewall tamu, pengikatan pendengar, dan identitas aplikasi itu sendiri. Masing-masing dapat menolak permintaan yang telah diantar perutean dengan sempurna.

Penerimaan harus berupa operasi aplikasi yang sebenarnya. Ping yang berhasil tidak memberi akses aplikasi atau membuktikan bahwa nama TLS dan kredensial benar, dan ping yang diblokir tidak membuktikan bahwa setiap layanan privat mati.

Pemeriksaan 4: apakah koneksi terpisah benar-benar diperlukan

VPN masih bisa menjadi bagian dari desain, tetapi karena alasan yang dinyatakan: menghubungkan VPC ini ke kantor, mengizinkan laptop, atau memenuhi kebutuhan overlay. Alasan itu berbeda dari komunikasi biasa di dalam VPC yang sama.

Ingat juga apa yang bukan VPC. VPC bukan perpanjangan segmen Ethernet rumah. Aplikasi yang bergantung pada penemuan siaran memiliki kebutuhan terpisah untuk dievaluasi. Itu celah desain, bukan bug perutean.

Pemeriksaan 5: pertanyaan enkripsi

Alamat privat dan aturan izin tidak mengatakan apa pun tentang perlindungan kriptografis di lapisan aplikasi. Jika data memerlukan perlindungan ujung ke ujung, itu berasal dari protokol dan model identitas yang benar-benar didukung layanan.

Pisahkan klaim lapisan jaringan dan lapisan aplikasi dalam catatan desain, karena menggabungkannya adalah cara sebuah tinjauan akhirnya menegaskan perlindungan yang tidak pernah diterapkan siapa pun.

Apa yang perlu dicatat

Catat kedua ID subnet, tabel rute yang terkait dengan masing-masing, referensi grup keamanan, dan operasi aplikasi yang Anda uji. Itu empat fakta, dan keempatnya menyelesaikan sebagian besar perdebatan di masa depan tentang jalur ini.

Penempatan zona saja tidak pernah memberi tahu Anda untuk menambahkan VPN, dan tidak pernah menjelaskan mengapa permintaan privat gagal.