AWS Client VPN tersambung tetapi tidak ada internet: pemeriksaan rute

AWS Client VPN tersambung tanpa akses internet? Periksa rute klien, otorisasi endpoint, egress subnet, dan DNS dalam urutan itu.

Anda tersambung ke endpoint AWS Client VPN, subnet privat menjawab, tetapi setiap halaman publik tetap habis waktu. Kombinasi itu menyempitkan masalah ke salah satu dari tiga objek di sisi terkelola: rute yang dipasang klien, rute endpoint beserta aturan otorisasinya, atau lompatan berikutnya dari subnet terkait. Saya memeriksanya dalam urutan itu karena setiap kegagalan tampak berbeda dari sisi klien. Panduan ini mencakup endpoint terkelola yang terkait VPC, bukan server OpenVPN pada instans EC2 dan bukan lampiran Cloud WAN atau Transit Gateway.

Mulailah dari apa yang sebenarnya dirutekan klien

Status tersambung membuktikan sesi TLS dan penetapan CIDR ke klien, tidak lebih. Tanyakan ke sistem operasi ke mana alamat publik akan pergi selama terowongan aktif. Di Linux, ip route get 1.1.1.1 seharusnya menyebut antarmuka terowongan; di macOS, netstat -rn -f inet | head -5 menampilkan entri default; di Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 mencetak antarmuka yang dipilih dan lompatan berikutnya.

Lalu baca flag split-tunnel, karena flag itu menentukan apakah rute yang dipublikasikan endpoint adalah satu-satunya tujuan yang dikirim klien ke terowongan:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Saat SplitTunnel bernilai true, tujuan publik memakai terowongan hanya jika endpoint mempublikasikan rute yang mencakupnya, sehingga 0.0.0.0/0 yang tidak ada membiarkan lalu lintas itu di antarmuka lokal. Saat false, klien menangkap lalu lintasnya, tetapi endpoint tetap harus merutekan dan mengotorisasinya; jika tidak, paket masuk ke terowongan dan berhenti di sana. Sambungkan ulang klien setelah mengubah salah satu dari dua pengaturan, karena rute dan server DNS dikirim saat koneksi dan klien yang berjalan dapat mempertahankan set lamanya.

Baca rute endpoint dan aturan otorisasi secara terpisah

Keduanya dua objek, dan membuat yang satu tidak membuat yang lain. Daftarkan rute endpoint dan cari rute default yang tujuannya subnet terkait:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Setiap rute punya tepat satu subnet tujuan, jadi tiga asosiasi memerlukan rute default yang sesuai untuk masing-masing. AWS mendokumentasikan syarat cakupan ini, dan gejala praktis dari celah adalah pengguna yang bekerja dari satu subnet dan macet dari subnet lain, yang terbaca sebagai gangguan berkala alih-alih rute yang hilang. Dokumentasi skenario Client VPN resmi menjelaskan susunan subnet publik tempat rute ini berada.

Otorisasi adalah objek kedua. Saat tidak ada aturan yang mencakup tujuan publik, terowongan membawa paket dan layanan membuangnya, sehingga sumber daya privat tetap berfungsi sementara internet tidak:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Aturan untuk CIDR VPC tidak mengatakan apa pun tentang 0.0.0.0/0. Menambahkan bagian yang hilang untuk terowongan penuh berarti satu rute per subnet terkait plus aturan otorisasi yang bisa Anda audit nanti:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all memberikan tujuan itu ke setiap klien endpoint, jadi pertahankan hanya selama terowongan dimaksudkan penuh; aturan yang terikat ke grup direktori lebih baik bila Anda punya grup untuk diikat.

Ikuti paket keluar dari subnet terkait

Rute endpoint memutuskan bahwa AWS menyerahkan paket ke subnet itu. Rute itu tidak memutuskan lompatan berikutnya setelahnya, yang hidup di tabel rute VPC subnet itu sendiri:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Rute default yang bisa dipakai mengarah ke internet gateway untuk subnet publik, atau ke NAT gateway untuk subnet privat, dan status blackhole berarti targetnya dihapus dan jalurnya kini mati diam-diam. Ini tabel yang berbeda dari daftar rute endpoint, dan memperbaiki yang satu tidak memperbaiki yang lain.

Ada dua filter di lompatan ini. Grup keamanan yang diterapkan pada asosiasi jaringan tujuan harus mengizinkan lalu lintas keluar menuju tujuan publik, dan ACL jaringan yang berlaku harus mengizinkan permintaan serta lalu lintas balasan pada port efemeral. Grup keamanan asosiasi yang ketat adalah penyebab umum akses privat berfungsi sementara akses publik tidak.

Pilih lapisan pertama berdasarkan gejalanya alih-alih mengubah ketiganya sekaligus:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

Pisahkan kegagalan DNS dari rute mati

Resolusi nama gagal berbeda dari penerusan, dan terowongan penuh membuat perbedaan itu penting karena resolver yang didorong kini dicapai melalui terowongan. Jika endpoint menentukan server DNS VPC, alamatnya perlu cakupan rute dan otorisasi seperti tujuan lain. Tanyakan langsung ke resolver untuk melihat kegagalan mana yang Anda hadapi: dig +short example.com @10.0.0.2, atau nslookup example.com 10.0.0.2 di Windows.

Saat URL numerik menjawab dan URL bernama tidak, berhenti menyunting rute default dan kerjakan DNS. Permintaan ke alamat IP tidak membuktikan apa pun tentang host virtual bernama dan sertifikatnya, jadi pertahankan satu uji bernama di pemeriksaan akhir.

Waktu membantu. Koneksi TCP yang tidak mendapat jawaban dalam beberapa detik menunjuk ke perutean atau filter, sedangkan permintaan yang menggantung di dalam pencarian nama menunjuk ke resolver. Mengubah rute default saat resolver tidak terjangkau biasanya mengubah satu kegagalan menjadi dua.

Kembalikan dengan bersih, lalu verifikasi jalur keluar

Kedua objek bersifat penambahan, jadi pengembaliannya adalah penghapusan, bukan perbaikan:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Sambungkan ulang, lalu pastikan jalur mana yang dipakai lalu lintas untuk keluar. Bandingkan alamat publik yang teramati dengan alamat IP elastis NAT gateway, atau dengan internet gateway yang hendak Anda pakai, dan periksa apakah sumber daya privat masih menjawab di sesi yang sama.

Akhiri dengan daftar singkat, dan perlakukan butir terakhir sebagai bagian dari perubahan, bukan sebagai dokumentasi:

  • Satu 0.0.0.0/0 rute endpoint untuk setiap subnet terkait.
  • Aturan otorisasi yang mencakup 0.0.0.0/0 untuk klien yang ingin Anda layani.
  • Rute default VPC yang tidak berstatus blackhole pada setiap subnet terkait.
  • Egress grup keamanan asosiasi, plus lalu lintas balasan ACL.
  • Alamat resolver dirutekan dan diotorisasi, diverifikasi dengan permintaan bernama.
  • Pengembalian tercatat untuk rute dan aturannya.

Satu catatan cakupan: ini jalur IPv4. Klien dual-stack mempertahankan konektivitas IPv6 yang sudah dimilikinya, jadi rute default IPv6 adalah keputusan terpisah dengan otorisasinya sendiri, bukan efek samping dari yang ini.

Artikel terkait