AWS Client VPN disambung tetapi tiada internet: semakan laluan

Anda disambung ke titik akhir AWS Client VPN, subnet peribadi menjawab, tetapi setiap halaman awam masih tamat masa. Gabungan itu menyempitkan masalah kepada salah satu daripada tiga objek di bahagian terurus: laluan yang dipasang oleh klien, laluan titik akhir bersama peraturan kebenarannya, atau lompatan seterusnya subnet berkaitan. Saya menyemaknya dalam susunan itu kerana setiap kegagalan kelihatan berbeza dari sisi klien. Panduan ini merangkumi titik akhir terurus yang berkaitan dengan VPC, bukan pelayan OpenVPN pada instans EC2 dan bukan lampiran Cloud WAN atau Transit Gateway.

Mulakan dengan apa yang sebenarnya dilalui oleh klien

Keadaan bersambung membuktikan sesi TLS dan peruntukan CIDR kepada klien, tidak lebih. Tanya sistem pengoperasian ke mana alamat awam akan pergi semasa terowong aktif. Pada Linux, ip route get 1.1.1.1 sepatutnya menamakan antara muka terowong; pada macOS, netstat -rn -f inet | head -5 menunjukkan entri lalai; pada Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 mencetak antara muka yang dipilih dan lompatan seterusnya.

Kemudian baca bendera split-tunnel, kerana ia menentukan sama ada laluan yang diterbitkan oleh titik akhir ialah satu-satunya destinasi yang dihantar oleh klien ke dalam terowong:

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

Apabila SplitTunnel ialah true, destinasi awam menggunakan terowong hanya apabila titik akhir menerbitkan laluan yang meliputinya, jadi 0.0.0.0/0 yang tiada membiarkan trafik itu pada antara muka setempat. Apabila ia false, klien menangkap trafik itu, tetapi titik akhir masih perlu melalui dan membenarkannya; jika tidak, paket masuk ke terowong dan berhenti di situ. Sambung semula klien selepas menukar mana-mana satu tetapan, kerana laluan dan pelayan DNS dihantar pada masa sambungan dan klien yang berjalan boleh menyimpan set lamanya.

Baca laluan titik akhir dan peraturan kebenaran secara berasingan

Kedua-duanya objek berasingan, dan mencipta satu tidak mencipta yang lain. Senaraikan laluan titik akhir dan cari laluan lalai yang sasarannya ialah subnet berkaitan:

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

Setiap laluan mempunyai tepat satu subnet sasaran, jadi tiga perkaitan memerlukan laluan lalai yang sepadan bagi setiap satu. AWS mendokumenkan keperluan liputan ini, dan gejala praktikal jurang ialah pengguna yang bekerja dari satu subnet dan tersekat dari subnet lain, yang dibaca sebagai gangguan berkala dan bukannya laluan yang hilang. Dokumentasi senario Client VPN rasmi menerangkan susunan subnet awam tempat laluan ini berada.

Kebenaran ialah objek kedua. Apabila tiada peraturan meliputi destinasi awam, terowong membawa paket itu dan perkhidmatan membuangnya, jadi sumber peribadi terus berfungsi sementara internet tidak:

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

Peraturan untuk CIDR VPC tidak menyatakan apa-apa tentang 0.0.0.0/0. Menambah bahagian yang hilang untuk terowong penuh bermakna satu laluan bagi setiap subnet berkaitan serta peraturan kebenaran yang boleh anda audit kemudian:

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 destinasi itu kepada setiap klien titik akhir, jadi kekalkan hanya selagi terowong sepatutnya penuh; peraturan yang terikat pada kumpulan direktori lebih baik apabila anda mempunyai kumpulan untuk diikat.

Ikuti paket keluar dari subnet berkaitan

Laluan titik akhir menentukan bahawa AWS menyerahkan paket itu kepada subnet tersebut. Ia tidak menentukan lompatan seterusnya selepas itu, yang tinggal dalam jadual laluan 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`]'

Laluan lalai yang boleh digunakan menunjuk ke gateway internet untuk subnet awam, atau ke gateway NAT untuk subnet peribadi, dan status blackhole bermaksud sasaran telah dipadam dan laluan kini mati secara senyap. Ini jadual berbeza daripada senarai laluan titik akhir, dan membaiki satu tidak membaiki yang lain.

Terdapat dua penapis pada lompatan ini. Kumpulan keselamatan yang digunakan pada perkaitan rangkaian sasaran mesti membenarkan trafik keluar ke arah destinasi awam, dan mana-mana ACL rangkaian yang berkenaan mesti membenarkan permintaan serta trafik balasan pada port efemeral. Kumpulan keselamatan perkaitan yang terhad ialah punca biasa akses peribadi berfungsi tetapi akses awam tidak.

Pilih lapisan pertama berdasarkan gejala dan bukan menukar ketiga-tiganya sekali gus:

Pisahkan kegagalan DNS daripada laluan mati

Penyelesaian nama gagal secara berbeza daripada penghantaran, dan terowong penuh menjadikan perbezaan itu penting kerana penyelesai yang ditolak kini dicapai melalui terowong. Jika titik akhir menentukan pelayan DNS VPC, alamatnya memerlukan liputan laluan dan kebenaran seperti mana-mana destinasi lain. Tanya penyelesai secara terus untuk melihat kegagalan mana yang anda hadapi: dig +short example.com @10.0.0.2, atau nslookup example.com 10.0.0.2 pada Windows.

Apabila URL berangka menjawab dan URL bernama tidak, berhenti menyunting laluan lalai dan kerjakan DNS. Permintaan ke alamat IP tidak membuktikan apa-apa tentang hos maya bernama dan sijilnya, jadi kekalkan satu ujian bernama dalam semakan akhir.

Masa membantu. Sambungan TCP yang tidak menerima jawapan dalam beberapa saat menunjuk kepada penghalaan atau penapis, manakala permintaan yang tergantung dalam carian nama menunjuk kepada penyelesai. Menukar laluan lalai semasa penyelesai tidak dapat dicapai cenderung menjadikan satu kegagalan kepada dua.

Gulung balik dengan bersih, kemudian sahkan laluan keluar

Kedua-dua objek bersifat tambahan, jadi penggulungan balik ialah pemadaman dan bukan pembaikan:

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

Sambung semula, kemudian sahkan laluan mana yang digunakan trafik untuk keluar. Bandingkan alamat awam yang diperhatikan dengan alamat IP elastik gateway NAT, atau dengan gateway internet yang anda ingin gunakan, dan semak sama ada sumber peribadi masih menjawab dalam sesi yang sama.

Akhiri dengan senarai pendek, dan anggap item terakhir sebagai bahagian perubahan dan bukan dokumentasi:

• Satu 0.0.0.0/0 laluan titik akhir bagi setiap subnet berkaitan.
• Peraturan kebenaran yang meliputi 0.0.0.0/0 untuk klien yang ingin anda layani.
• Laluan lalai VPC yang bukan blackhole pada setiap subnet berkaitan.
• Keluar kumpulan keselamatan perkaitan, serta trafik balasan ACL.
• Alamat penyelesai dilalui dan dibenarkan, disahkan dengan permintaan bernama.
• Penggulungan balik direkodkan untuk laluan dan peraturan itu.

Satu nota skop: ini laluan IPv4. Klien dwi-stack mengekalkan konektiviti IPv6 yang sudah dimilikinya, jadi laluan lalai IPv6 ialah keputusan berasingan dengan kebenarannya sendiri dan bukan kesan sampingan daripada yang ini.