EC2 merentas zon ketersediaan: semak penghalaan sebelum VPN

Sebelum memasang perisian VPN antara dua instans EC2, jawab satu soalan: adakah kedua-duanya dalam VPC yang sama? Jika ya, laluan peribadi sudah wujud dan penempatan merentas zon tidak mengubahnya. Sebahagian besar kerja dalam keadaan ini ialah mengesahkan jadual laluan mana yang sebenarnya digunakan oleh setiap subnet, kemudian mengetahui sama ada kegagalan itu memang masalah penghalaan. Terowong biasanya jawapan yang salah untuk soalan khusus ini.

Pemeriksaan 1: VPC yang sama atau VPC berbeza

VPC bersifat serantau dan merangkumi zon ketersediaan, manakala setiap subnet tergolong dalam tepat satu zon. Dua instans dalam zon berbeza bagi satu VPC masih berada dalam domain penghalaan peribadi yang sama.

VPC yang berbeza tidak pernah memperoleh laluan peribadi semata-mata kerana berkongsi wilayah atau label zon. Kes itu memerlukan sambungan yang disokong serta kerja laluan dan kebenaran tersendiri, yang merupakan keputusan berasingan.

Pemeriksaan 2: apa kata jadual laluan subnet

Tulis susun atur dengan nilai sebenar. Satu VPC pada 10.60.0.0/16 dengan subnet 10.60.1.0/24 dan 10.60.2.0/24 memberikan instans 10.60.1.10 dan 10.60.2.20 laluan melalui laluan setempat VPC.

Kemudian periksa jadual yang berkaitan dengan kedua-dua subnet, bukan hanya yang anda temui dahulu. Laluan pemeriksaan atau perkakas yang lebih khusus boleh mengatasi laluan asas, dan sasaran laluan setempat itu sendiri boleh diganti dalam konfigurasi yang lebih baharu. Laluan setempat yang kelihatan di suatu tempat dalam konsol tidak membuktikan kedua-dua beban kerja menggunakannya.

Gunakan alamat dan nama peribadi yang benar-benar diberikan oleh VPC. Alamat peribadi tidak perlu bermula dengan 10, dan mencipta satu daripada ingatan ialah cara persekitaran yang berfungsi salah didiagnosis.

Pemeriksaan 3: penghalaan atau kebenaran

Penghalaan hanya membawa paket ke antara muka rangkaian sasaran. Kumpulan keselamatan sasaran masih perlu menerima sumber dan perkhidmatan, peraturan keluar sumber mesti membenarkan permintaan, dan mana-mana ACL rangkaian mesti membenarkan kedua-dua arah kerana ACL tidak menyimpan keadaan.

Di sebaliknya terletak firewall tetamu, pengikatan pendengar dan identiti aplikasi itu sendiri. Mana-mana daripadanya boleh menolak permintaan yang dihantar dengan sempurna oleh penghalaan.

Penerimaan mesti merupakan operasi aplikasi yang sebenar. Ping yang berjaya tidak memberi akses aplikasi atau membuktikan nama TLS dan kelayakan adalah betul, dan ping yang disekat tidak membuktikan setiap perkhidmatan peribadi terhenti.

Pemeriksaan 4: adakah sambungan berasingan benar-benar diperlukan

VPN masih boleh menjadi sebahagian daripada reka bentuk, tetapi atas sebab yang dinyatakan: menyambungkan VPC ini ke pejabat, menerima komputer riba atau memenuhi keperluan lapisan tindihan. Sebab itu berbeza daripada komunikasi biasa dalam VPC yang sama.

Ingat juga apa yang bukan VPC. Ia bukan lanjutan segmen Ethernet rumah. Aplikasi yang bergantung pada penemuan siaran mempunyai keperluan berasingan untuk dinilai. Itu jurang reka bentuk, bukan pepijat penghalaan.

Pemeriksaan 5: persoalan penyulitan

Alamat peribadi dan peraturan kebenaran tidak mengatakan apa-apa tentang perlindungan kriptografi pada lapisan aplikasi. Jika data memerlukan perlindungan hujung ke hujung, ia datang daripada protokol dan model identiti yang benar-benar disokong oleh perkhidmatan.

Asingkan dakwaan lapisan rangkaian dan lapisan aplikasi dalam nota reka bentuk, kerana menggabungkannya ialah cara semakan akhirnya mendakwa perlindungan yang tiada siapa melaksanakannya.

Apa yang perlu direkodkan

Rekod kedua-dua ID subnet, jadual laluan yang berkaitan dengan setiap satu, rujukan kumpulan keselamatan dan operasi aplikasi yang anda uji. Itu empat fakta, dan ia menyelesaikan sebahagian besar perdebatan masa depan tentang laluan ini.

Penempatan zon sahaja tidak pernah memberitahu anda untuk menambah VPN, dan ia tidak pernah menjelaskan mengapa permintaan peribadi gagal.