Akses berselang-seli dalam AWS Client VPN: audit setiap subnet berkaitan
Sesetengah sesi AWS Client VPN sampai ke VPC aplikasi sementara yang lain tamat masa. Bandingkan dahulu laluan titik akhir dengan jadual laluan VPC setiap persatuan.
Seorang pengguna menyambung, membuka aplikasi dalaman dan mendapat jawapan; rakan sekerja pada titik akhir yang sama menerima tamat masa daripada komputer riba yang serupa pada Wi-Fi yang sama. Corak itu ialah tanda titik akhir client VPN dengan lebih daripada satu subnet berkaitan, di mana laluannya tidak setara. Saya menelusuri ini dari konsol ke luar, kerana dua tab menentukan sama ada baki siasatan itu berbaloi. Tiada apa-apa dalam konfigurasi klien yang menjelaskannya.
Mulakan pada titik akhir dan senaraikan persatuan
Dalam konsol VPC, buka Client VPN endpoints, pilih titik akhir dan baca tab Associations. Setiap persatuan ialah subnet dalam zon ketersediaan, dan klien mendarat pada subnet yang dipilih perkhidmatan apabila sambungan dibina. Catat ID subnet dan jadual laluan yang benar-benar digunakan setiap satu, kerana kedua-dua senarai itulah perbandingan yang akan anda buat.
Jika titik akhir menunjukkan hanya satu persatuan, teori ini salah dan klien ialah suspek yang lebih baik.
Bandingkan jadual laluan titik akhir dengan setiap persatuan
Buka tab Route table pada titik akhir yang sama. Setiap CIDR destinasi di sana mempunyai sasaran, dan bagi client VPN sasaran ialah persatuan dan bukan gateway. AWS memerlukan entri destinasi bagi setiap subnet berkaitan, jadi laluan yang menyasarkan hanya satu daripadanya menjadikan akses bergantung pada tempat sesi mendarat. Semak destinasi yang benar-benar anda pedulikan, kemudian semak peraturan kebenarannya, kerana laluan menyediakan jalan dan peraturan menentukan siapa boleh menggunakannya.
Sebaik sahaja anda menjadualkan kedua-dua lapisan, kegagalan itu sukar terlepas pandang.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
Baris kedua ialah keseluruhan pepijat dalam kebanyakan tiket. Laluan titik akhir ada, jadi tiada siapa melihat lebih jauh, dan paket mati satu hop kemudian di dalam VPC.
Ikuti setiap subnet ke jadual laluan efektifnya
Subnet tanpa persatuan jadual laluan yang jelas mewarisi jadual utama VPC. Baca jadual yang benar-benar berkuat kuasa, bukan yang namanya kelihatan betul, dan bandingkan destinasi dan sasaran dan bukan label pada baris.
Panduan AWS tentang akses berselang-seli merangkumkannya sebagai liputan laluan merentas persatuan, iaitu model yang betul. Titik akhir membawa paket ke subnet, dan jadual subnet itu masih perlu tahu di mana rangkaian aplikasi berada.
Betulkan baris yang hilang dalam jadual yang memilikinya. Menyalin seluruh jadual laluan daripada subnet yang berfungsi turut menyalin pilihan internet, perkakas dan pengasingan yang tidak pernah dimaksudkan untuk subnet ini, dan pertukaran itu biasanya lebih buruk daripada gangguan yang anda mulakan.
Semak peraturan kebenaran, kemudian laluan balik
Peraturan kebenaran adalah mengikut destinasi dan mengikut kumpulan, dan dinilai berasingan daripada laluan. Destinasi yang mempunyai laluan di mana-mana tetapi tiada peraturan untuk kumpulan pengguna berkelakuan seperti lubang hitam dengan jadual laluan yang kelihatan sihat.
Laluan balik juga wajar mendapat perhatian yang sama. Sambungan peering memerlukan laluan dalam VPC aplikasi yang menunjuk balik ke CIDR klien, peraturan kumpulan keselamatan yang membenarkan trafik di kedua-dua hujung, dan ACL rangkaian yang tidak menggugurkannya. Kebolehlaksanaan sehala, di mana ping berfungsi dan jabat tangan TCP tidak, biasanya menunjuk kepada ACL atau kumpulan keselamatan dan bukan VPN.
Kumpulan keselamatan titik akhir itu sendiri terletak pada antara muka rangkaian elastik persatuan, jadi peraturan yang membenarkan port aplikasi daripada CIDR klien mesti dilampirkan pada persatuan, bukan hanya pada instans.
Sahkan dengan sambungan semula, bukan dengan satu permintaan bertuah
Dengan split tunnel, laluan titik akhir dihantar apabila sambungan diwujudkan, jadi set laluan yang berubah tidak pernah sampai kepada klien yang kekal bersambung. Putuskan dan sambung semula melalui klien yang disokong, kemudian pastikan laluan baharu ada pada mesin.
Akhir sekali, kaitkan log sambungan dengan alamat yang diterima klien, dan ulangi ujian dengan cukup kerap untuk menemui lebih daripada satu persatuan. Satu permintaan berjaya selepas pembetulan membuktikan satu laluan berfungsi, dan tiket itu mengenai laluan yang lain.