AWS Client VPN atau bastion untuk mencapai VPC yang di-peer

Satu endpoint Client VPN boleh mencapai VPC yang di-peer dengan VPC berkaitannya, dan anda tidak memerlukan bastion untuk menjadikannya sah. Pilihan yang berbaloi dibuat ialah di mana trafik bertukar tangan: laluan endpoint yang mendarat di subnet persatuan dan melintasi sambungan peering, atau hos dalam VPC yang di-peer yang menamatkan sesi. Kedua-dua laluan berfungsi dan gagal di tempat berbeza, jadi keputusannya tentang pemilikan dan audit, bukan tentang apa yang dibenarkan AWS. Berikut cara saya memilih antara keduanya, dan empat entri yang menjadikan laluan yang dihalakan berfungsi.

Dua laluan, satu endpoint, pemilik berbeza

Pada laluan yang dihalakan, trafik klien sampai ke endpoint, diterjemah ke alamat antara muka rangkaian Client VPN dalam subnet persatuan, dan meninggalkan subnet itu melalui sambungan peering dari A ke B. VPC B tidak menamatkan sebarang sesi VPN; ia melihat trafik biasa dari VPC A, sebab itu laluan pulangnya menunjuk ke VPC A, bukan ke kumpulan klien.

Pada laluan bastion, klien sampai ke hos dahulu. Bastion di A masih membiarkan hop terakhir melintasi sambungan peering, jadi anda mengekalkan kerja peering dan menambah sesi. Bastion di B juga memerlukan laluan dari klien, dan apabila laluan itu ialah laluan endpoint yang sama, anda mempunyai reka bentuk yang dihalakan tambah satu hop. Bastion hanya mengurangkan kerja apabila ia sudah wujud, sudah diluluskan, dan perkara di belakangnya memerlukan sempadan sesi bukan sempadan rangkaian.

Empat entri menjadikan laluan yang dihalakan berfungsi

AWS mendokumenkan senario ini di halaman Client VPN how-it-works, dan dalam amalan ia turun kepada empat entri yang dimiliki dua atau tiga pasukan. Julat adalah ilustratif; julat peering mesti unik dan julat pulang mesti sepadan dengan pelan anda.

Laluan dan kebenaran ialah kawalan berasingan. Laluan endpoint yang betul tanpa peraturan kebenaran yang sepadan tidak memberi klien apa-apa; peraturan kebenaran untuk destinasi yang endpoint tidak boleh halakan memberinya lubang hitam. Kedua-duanya mesti menyebut julat yang sama.

Laluan endpoint menunjuk ke subnet dalam VPC endpoint itu sendiri, tidak pernah ke sambungan peering. Jadual laluan VPC menunjuk ke sambungan peering, tidak pernah ke instans atau antara muka. Menyalin nilai antara keduanya disimpan tanpa aduan dan tidak menghalakan apa-apa.

Kerana subnet persatuan menterjemah sumber klien, B mesti menghalakan balik ke VPC A, bukan ke kumpulan klien. Menghantar julat klien merentasi sambungan peering kelihatan simetri, lulus semakan dan gagal secara senyap kerana B tidak pernah melihat paket dengan sumber klien.

Kumpulan keselamatan dan meter terakhir kebenaran

Penghalakan membawa paket ke B; B masih memutuskan. Untuk sambungan peering aktif di wilayah yang sama, kumpulan keselamatan di B boleh merujuk kumpulan yang digunakan pada persatuan Client VPN, yang mengekalkan peraturan sempit dan bertahan terhadap perubahan alamat. Di mana rujukan kumpulan tidak dapat dilaksanakan, benarkan julat subnet persatuan secara eksplisit dan bukannya meluaskan ke 0.0.0.0/0, yang menukar kesilapan penghalakan menjadi tamat masa tanpa penjelasan.

Kemudian semak apa yang tidak pernah disentuh oleh penghalakan: ACL rangkaian pada kedua-dua subnet, senarai benaran atau khalayak token aplikasi, dan DNS. Peering tidak menyalin zon dihoskan peribadi, jadi komputer riba boleh memegang laluan berfungsi ke alamat yang tidak dapat diselesaikannya, dan sambungan peering tidak menambah kepercayaan pada sijil. Halakan endpoint ke penyelesai yang menjawab untuk B, kemudian sahkan bahawa nama peribadi dan sijil sepadan.

Bila bastion ialah jawapan yang jujur

Saya menyimpan tiga pencetus untuk memilih bastion secara sengaja. VPC yang di-peer milik pasukan yang tidak akan menambah laluan pulang untuk julat anda atau tidak akan menerima rujukan kumpulan. Akses mesti diluluskan atau direkodkan setiap sesi dan aplikasi tidak boleh memikulnya sendiri. Atau hop terakhir mesti kekal di dalam B kerana perkhidmatan hanya diselesaikan di situ dan identiti TLS-nya dipinkan pada nama dalaman.

Tiada satu pun daripada itu merupakan jalan pintas daripada fakta bahawa peering tidak transitif. Ketidaktertransitifan mengehadkan apa yang boleh dilakukan oleh sumber di B: mereka tidak boleh menggunakan A sebagai transit ke VPC ketiga yang di-peer dengan A. Ia tidak pernah bermaksud pengguna VPN tidak boleh mencapai VPC yang di-peer secara langsung, dan bastion yang dibina untuk mengelak salah bacaan itu ialah hos yang ditampal tanpa sebab.

Kesilapan sebaliknya lebih mahal dari semasa ke semasa: salurkan setiap pasukan melalui satu-satunya bastion yang sudah wujud, kemudian temui bahawa kumpulan keselamatan, jadual laluan dan tetingkap tampalnya ialah kebergantungan pengeluaran. Catat pencetus mana yang dilayani oleh hos, dan persarakan ia apabila pencetus hilang.

Transit Gateway dan beberapa persatuan mengubah aritmetik

Jika endpoint dipasang terus ke Transit Gateway dan bukannya ke subnet, model berubah: klien tidak lagi diterjemah ke alamat antara muka dalam subnet persatuan, dan jadual laluan gateway mesti membawa julat klien serta lampiran yang menuju ke VPC yang di-peer. Ia lebih bersih pada skala, tetapi kerja berpindah daripada empat entri ke jadual laluan gateway.

Beberapa persatuan menggandakan semakan. Laluan endpoint milik endpoint, namun setiap subnet persatuan memerlukan jadual laluan dengan hop seterusnya peering sebenar. Sesi boleh berjaya melalui satu persatuan sementara yang lain tiada laluan pulang, jadi uji setiap satu.

Urutan pengesahan yang menemui kerosakan dengan cepat

Jalankan ini mengikut urutan; setiap langkah boleh lulus sementara yang berikutnya gagal, dan tamat masa klien hampir tidak pernah memberitahu yang mana rosak.

1. Selesaikan nama aplikasi daripada klien dan semak alamat berada dalam julat peering.
2. Sambung, kemudian baca log sambungan endpoint untuk persatuan yang menamatkan sesi.
3. Pada subnet persatuan itu, sahkan jadual laluan menghalakan julat peering ke sambungan peering aktif.
4. Pada subnet sumber di B, sahkan entri pulang untuk julat antara muka dan peraturan kumpulan yang sepadan.
5. Uji satu operasi yang dibenarkan dan satu sumber yang mesti kekal tidak dapat dicapai; yang kedua menangkap sisa nyahpepijat.
6. Sambung semula selepas sebarang perubahan laluan split-tunnel, kerana terowong yang berjalan tidak akan mengambil set laluan baharu.

Dua gejala wajar dihafal. SYN yang sampai ke B tanpa balasan hampir selalu laluan pulang yang hilang. Sambungan yang selesai dan kemudian ditetapkan semula biasanya kumpulan, ACL atau aplikasi. Kedua-duanya tidak muncul dalam log endpoint sebagai punca, jadi simpan empat entri dengan pemilik di sebelah setiap satu.

Jika tiada satu pun daripada tiga pencetus terpakai, selesaikan laluan yang dihalakan dan rekod empat entri itu. Jika satu terpakai, kekalkan bastion hanya untuk sempadan itu dan biarkan laluan endpoint untuk perkhidmatan yang tidak memerlukan sesi di hadapannya.