Tunnel penuh Access Server di EC2: mengapa satu kotak centang tidak cukup

Menonaktifkan pemeriksaan sumber dan tujuan pada instans EC2 adalah jawaban yang paling sering diulang untuk pertanyaan tentang jalur keluar internet Access Server, dan dengan sendirinya tidak melakukan apa pun bagi klien Anda. Pemeriksaan itu adalah batasan penerusan AWS: ia membuat instans menerima paket yang sumber atau tujuannya bukan alamatnya sendiri. Ia tidak menyuruh klien Access Server mengirim lalu lintas internet melalui tunnel, tidak membuat rute ke hulu, dan tidak menambahkan NAT. Mitosnya adalah kotak centang itu sendiri adalah fiturnya.

Apa yang sebenarnya dikendalikan pemeriksaan itu

Setiap antarmuka jaringan EC2 membuang lalu lintas yang tidak dialamatkan kepadanya, kecuali instans berperan sebagai router, perangkat NAT, atau gateway VPN dan Anda menonaktifkan pemeriksaan tersebut. Menonaktifkannya memberi izin untuk meneruskan. Izin bukan konfigurasi: instans masih memerlukan rute ke gateway internet atau perangkat NAT, tabel rute VPC masih memerlukan entri yang cocok, grup keamanan masih harus mengizinkan aliran, dan server masih harus menerjemahkan atau merutekan lalu lintas balasan.

Periksa nilai saat ini dengan aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck sebelum mengubah apa pun. Jika Anda mengubahnya di konsol, ubahlah karena instans meneruskan untuk pihak lain, bukan karena klien tidak dapat mencapai internet.

Access Server pemilik kebijakan perutean klien

Di Access Server 3, buka Access Controls dan temukan bagian Internet Access and DNS. Pilihan Internet Gateway menawarkan tunnel penuh atau tunnel terpisah; tunnel penuh menyuruh klien merutekan lalu lintas bawaannya ke dalam VPN, tunnel terpisah membiarkan lalu lintas internet pada jalur lokal klien. Simpan dan terapkan melalui alur kerja produk, lalu sambungkan ulang klien uji, karena kebijakan dikirim pada saat koneksi.

Rilis lama memakai menu berbeda dan beberapa build Community OpenVPN tidak memiliki kontrol yang setara. Periksa versi utama yang terpasang sebelum mencari layar yang tidak ada. Lalu pastikan apa yang diterima klien: profil tunnel penuh seharusnya memasang rute bawaan melalui tunnel, dan profil tunnel terpisah seharusnya tidak.

Telusuri paket setelah tunnel

Setelah klien mengirim lalu lintas internet ke tunnel, server harus meneruskannya dan biasanya menerjemahkannya. Access Server mengelola aturan NAT dan peruteannya sendiri, jadi bacalah konfigurasi efektif alih-alih menambahkan aturan Community OpenVPN ke berkas yang dihasilkan; aturan yang tidak terkelola akan ditimpa atau bentrok pada pembaruan produk berikutnya. sudo iptables -t nat -L -n -v atau padanan nftables menunjukkan apa yang benar-benar diterjemahkan.

Sisi AWS adalah jalur terpisah. Instans di subnet publik mencapai gateway internet secara langsung dan mempertahankan alamat publik atau IP elastisnya. Instans di subnet privat memerlukan rute ke gateway NAT atau instans NAT, dan perangkat NAT memerlukan rutenya sendiri ke gateway internet. Melampirkan gateway internet ke VPC tidak dengan sendirinya memberi sumber privat alamat balik publik, itulah sebabnya penyiapan Access Server yang sama berfungsi di satu subnet dan gagal diam-diam di subnet lain.

Periksa tabel rute yang terkait dengan subnet instans, bukan hanya tabel utama VPC. Asosiasi subnet mengalahkan tabel utama, dan asosiasi yang basi adalah penyebab umum konfigurasi yang berfungsi berhenti setelah pembangunan ulang.

Pisahkan jalur keluar IP dan DNS

Uji literal alamat lebih dulu, lalu nama, dari aplikasi klien yang sama. Jika curl -4 https://checkip.amazonaws.com mengembalikan alamat publik tetapi nama host gagal, tunnel dan jalur NAT berfungsi dan masalahnya ada di DNS: resolver yang dikirim, status resolver klien, atau grup keamanan yang memblokir resolver. Pengaturan DNS Access Server berada di area Internet Access yang sama, tetapi menempuh jalur kode berbeda.

Bandingkan alamat yang dikembalikan dengan jalur keluar yang Anda maksudkan. Jika itu alamat publik instans, lalu lintas diterjemahkan oleh instans; jika itu alamat gateway NAT, jalur subnet privat yang dipakai. Keduanya bisa benar. Yang tidak dapat Anda simpulkan adalah bahwa peramban di server membuktikan penerusan klien.

Jangan biarkan satu kotak centang menutup penyelidikan

IPv6 adalah keputusan terpisah. Kebijakan tunnel penuh untuk IPv4 tidak mengatakan apa pun tentang apakah IPv6 dibawa, diblokir, atau bocor, dan klien tumpukan ganda dapat terus memakai jalur IPv6 lokalnya sementara IPv4 berada di tunnel. Uji keluarga alamat yang benar-benar Anda pedulikan, dan putuskan secara eksplisit apakah yang lain harus dinonaktifkan.

Terakhir, uji keadaan terputus. Pilihan tunnel penuh menggambarkan kebijakan perutean saat terhubung, bukan apa yang terjadi ketika tunnel putus. Jika persyaratannya adalah tidak ada lalu lintas yang lolos ke luar VPN, itu pertanyaan kill-switch dan firewall, dan perlu pengujiannya sendiri alih-alih kesimpulan dari tabel rute.