Mengapa EC2 tidak dapat menjangkau laptop AWS Client VPN Anda
Client VPN menerjemahkan sumber IPv4 klien ke antarmuka endpoint. Itulah sebabnya balasan berhasil dan koneksi baru dari EC2 tidak.
Laptop yang terhubung melalui AWS Client VPN menjangkau aplikasi EC2 tanpa masalah. Lalu Anda mencoba sebaliknya, dari EC2 ke alamat yang diberikan kepada klien, dan koneksi menggantung atau ditolak. Asimetri itu jarang berupa aturan grup keamanan yang hilang. Pada endpoint Client VPN yang terhubung dengan subnet VPC, AWS menerjemahkan sumber IPv4 klien ke antarmuka jaringan endpoint, sehingga tidak ada alamat VPC masuk yang mewakili laptop Anda.
Mulai dari apa yang ditunjukkan rekaman
Ambil rekaman di host EC2 saat klien terhubung, lalu baca alamat sumber yang benar-benar dilihat aplikasi. Jika itu antarmuka endpoint di sisi VPC dan bukan alamat dari kumpulan klien, penerjemahan sudah terkonfirmasi sebelum Anda mengubah satu aturan pun.
Kumpulan klien adalah rentang alokasi, bukan subnet dengan rute balik. Di situlah sebagian besar penyelidikan semacam ini salah arah.
Penerjemahan yang menjelaskan asimetri
Tiga alur saling tertukar, dan hanya satu di antaranya yang diuji orang.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Deskripsi komponen Client VPN menyatakan bahwa sumber IPv4 klien diterjemahkan ke antarmuka endpoint, yang cukup untuk melihat mengapa baris tengah tidak punya apa pun untuk dicocokkan.
Koneksi baru membutuhkan rute, langkah resolusi alamat, dan keputusan otorisasi. Status penerjemahan dari sesi orang lain tidak menyediakan satu pun dari ketiganya.
Mengapa balasan bukan koneksi baru
Balasan TCP dicocokkan dengan entri yang sudah ada, karena itu jalur balik bekerja tanpa aturan masuk sama sekali. SYN baru dari host EC2 tidak punya entri untuk dicocokkan, jadi ia menjadi upaya keluar biasa ke tujuan yang tidak diketahui VPC cara mencapainya.
Karena itu pula menggambarkannya sebagai lalu lintas yang hanya satu arah menyesatkan. Lalu lintas balik mengalir terus-menerus dalam sesi ini. Bagian yang tanpa jalur adalah inisiasinya.
Apa yang masih merusak sesi yang seharusnya berhasil
Grup keamanan, ACL jaringan, dan firewall laptop itu sendiri semuanya penting bagi koneksi yang seharusnya berhasil. Ping yang gagal paling sedikit memberi tahu, karena kebijakan ICMP sering terpisah dari kebijakan TCP yang Anda pedulikan.
Tulis aturan tersebut terhadap sumber yang diterjemahkan, bukan alamat klien. Aturan yang dikunci pada alamat yang tidak pernah muncul di jaringan adalah kegagalan yang ditimbulkan sendiri paling umum dalam desain ini.
Saat VPC memang harus memulai percakapan
Jika sebuah layanan harus memberi tahu stasiun kerja, balikkan arahnya dan biarkan klien memegang kanal keluar yang persisten yang dibalas layanan. Jika seluruh jaringan jarak jauh harus dapat dijangkau dari VPC, pilih arsitektur yang memublikasikan prefiks dan kebijakan aksesnya alih-alih menganggap Client VPN sudah melakukannya. Akses klien ke klien adalah kasus ketiga yang lebih sempit dengan objek rute dan otorisasi sendiri. Tidak satu pun dari ini sekadar kotak centang pada endpoint yang ada.
Jaga juga cakupan penjelasan IPv4 tetap jujur. Dokumentasi AWS saat ini memisahkan IPv6, tempat penerjemahan itu tidak diterapkan, dan model pemasangan lain yang merutekan secara berbeda.
Uji dalam tiga langkah berlabel: klien membuka sesi yang diizinkan, layanan VPC menjawab sesi itu, dan host VPC membuka sesi baru menuju klien. Berhasilnya dua langkah pertama sementara yang ketiga gagal adalah bentuk yang diharapkan dari desain ini, bukan cacat yang harus dikejar dengan aturan firewall.