Akses terputus-putus di AWS Client VPN: audit setiap subnet yang terasosiasi

Seorang pengguna terhubung, membuka aplikasi internal, dan mendapat jawaban; rekan di endpoint yang sama mendapat timeout dari laptop identik di Wi-Fi yang sama. Pola itu adalah ciri endpoint client VPN dengan lebih dari satu subnet terasosiasi, tempat jalurnya tidak setara. Saya menelusuri ini dari konsol ke luar, karena dua tab menentukan apakah sisa penyelidikan layak dilakukan. Tidak ada apa pun di konfigurasi klien yang menjelaskannya.

Mulai dari endpoint dan daftar asosiasinya

Di konsol VPC, buka Client VPN endpoints, pilih endpoint, dan baca tab Associations. Setiap asosiasi adalah subnet di zona ketersediaan, dan klien mendarat di subnet yang dipilih layanan saat koneksi dibangun. Catat ID subnet dan tabel rute yang benar-benar dipakai masing-masing, karena kedua daftar itulah perbandingan yang akan Anda buat.

Jika endpoint hanya menunjukkan satu asosiasi, teori ini salah dan klien adalah tersangka yang lebih baik.

Bandingkan tabel rute endpoint dengan setiap asosiasi

Buka tab Route table pada endpoint yang sama. Setiap CIDR tujuan di sana punya target, dan pada client VPN targetnya adalah asosiasi, bukan gateway. AWS mewajibkan entri tujuan untuk setiap subnet terasosiasi, jadi rute yang hanya menargetkan salah satunya membuat akses bergantung pada tempat sesi mendarat. Periksa tujuan yang benar-benar Anda pedulikan, lalu periksa aturan otorisasinya, karena rute menyediakan jalur dan aturan menentukan siapa yang boleh memakainya.

Setelah Anda mentabulasi kedua lapisan, kegagalannya sulit terlewat.

Baris kedua adalah seluruh bug di sebagian besar tiket. Rute endpoint ada, jadi tidak ada yang melihat lebih jauh, dan paket mati satu hop kemudian di dalam VPC.

Telusuri setiap subnet ke tabel rute efektifnya

Subnet tanpa asosiasi tabel rute eksplisit mewarisi tabel utama VPC. Baca tabel yang benar-benar berlaku, bukan yang namanya terlihat benar, dan bandingkan tujuan dan target alih-alih label pada baris.

Panduan AWS tentang akses terputus-putus membingkainya sebagai cakupan rute di seluruh asosiasi, yang merupakan model yang tepat. Endpoint mengantar paket ke sebuah subnet, dan tabel subnet itu tetap harus tahu di mana jaringan aplikasi berada.

Perbaiki baris yang hilang di tabel yang memilikinya. Menyalin seluruh tabel rute dari subnet yang berfungsi juga menyalin pilihan internet, perangkat, dan isolasi yang tidak pernah dimaksudkan untuk subnet ini, dan pertukaran itu biasanya lebih buruk daripada gangguan yang Anda mulai.

Periksa aturan otorisasi, lalu jalur kembali

Aturan otorisasi bersifat per tujuan dan per grup, serta dievaluasi terpisah dari rute. Tujuan yang punya rute di mana-mana tetapi tidak punya aturan untuk grup pengguna berperilaku seperti lubang hitam dengan tabel rute yang tampak sehat.

Jalur kembali juga layak mendapat perhatian yang sama. Koneksi peering membutuhkan rute di VPC aplikasi yang menunjuk kembali ke CIDR klien, aturan grup keamanan yang mengizinkan lalu lintas di kedua ujung, dan ACL jaringan yang tidak menjatuhkannya. Keterjangkauan satu arah, saat ping bekerja dan jabat tangan TCP tidak, biasanya menunjuk ke ACL atau grup keamanan, bukan ke VPN.

Grup keamanan endpoint itu sendiri berada pada antarmuka jaringan elastis asosiasi, jadi aturan yang mengizinkan port aplikasi dari CIDR klien harus dilampirkan ke asosiasi, bukan hanya ke instans.

Verifikasi dengan menyambung ulang, bukan dengan satu permintaan yang beruntung

Dengan split tunnel, rute endpoint dikirim saat koneksi dibangun, jadi kumpulan rute yang berubah tidak pernah sampai ke klien yang tetap terhubung. Putuskan dan sambungkan kembali melalui klien yang didukung, lalu pastikan rute baru ada di mesin.

Terakhir, korelasikan log koneksi dengan alamat yang diterima klien, dan ulangi pengujian cukup sering untuk mengenai lebih dari satu asosiasi. Satu permintaan yang berhasil setelah perbaikan membuktikan satu jalur bekerja, dan tiketnya tentang jalur yang lain.