Tunnel penuh Access Server pada EC2: mengapa satu kotak semak tidak mencukupi

Mematikan semakan sumber dan destinasi pada instans EC2 ialah jawapan yang paling kerap diulang bagi soalan tentang keluar internet Access Server, dan ia sendiri tidak melakukan apa-apa untuk pelanggan anda. Semakan itu ialah kekangan penghantaran AWS: ia membuatkan instans menerima paket yang sumber atau destinasinya bukan alamatnya sendiri. Ia tidak menyuruh pelanggan Access Server menghantar trafik internet melalui tunnel, tidak mencipta laluan ke atas dan tidak menambah NAT. Mitosnya ialah kotak semak itu sendiri adalah ciri tersebut.

Apa yang sebenarnya dikawal oleh semakan

Setiap antara muka rangkaian EC2 membuang trafik yang tidak dialamatkan kepadanya, kecuali instans bertindak sebagai penghala, peranti NAT atau get laluan VPN dan anda mematikan semakan itu. Mematikannya memberi kebenaran untuk menghantar. Kebenaran bukan konfigurasi: instans masih memerlukan laluan ke get laluan internet atau peranti NAT, jadual laluan VPC masih memerlukan entri yang sepadan, kumpulan keselamatan masih perlu membenarkan aliran, dan pelayan masih perlu menterjemah atau menghalakan trafik balasan.

Semak nilai semasa dengan aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck sebelum mengubah apa-apa. Jika anda mengubahnya dalam konsol, ubahlah kerana instans menghantar bagi pihak lain, bukan kerana pelanggan tidak dapat mencapai internet.

Dasar penghalaan pelanggan milik Access Server

Dalam Access Server 3, buka Access Controls dan cari bahagian Internet Access and DNS. Pilihan Internet Gateway menawarkan tunnel penuh atau tunnel berpecah; tunnel penuh menyuruh pelanggan menghalakan trafik lalainya ke dalam VPN, tunnel berpecah membiarkan trafik internet pada laluan setempat pelanggan. Simpan dan gunakan melalui aliran kerja produk, kemudian sambung semula pelanggan ujian, kerana dasar itu dihantar pada masa sambungan.

Keluaran lama menggunakan menu berbeza dan sesetengah binaan Community OpenVPN tiada kawalan setara. Semak versi utama yang dipasang sebelum mencari skrin yang tidak wujud. Kemudian sahkan apa yang diterima pelanggan: profil tunnel penuh sepatutnya memasang laluan lalai melalui tunnel, dan profil tunnel berpecah tidak sepatutnya berbuat demikian.

Jejaki paket selepas tunnel

Sebaik pelanggan menghantar trafik internet ke dalam tunnel, pelayan mesti menghantarnya dan biasanya menterjemahnya. Access Server mengurus peraturan NAT dan penghalaannya sendiri, jadi baca konfigurasi berkesan dan bukannya menambah peraturan Community OpenVPN pada fail yang dijana; peraturan yang tidak diurus akan ditulis ganti atau bercanggah pada kemas kini produk seterusnya. sudo iptables -t nat -L -n -v atau setara nftables menunjukkan apa yang sebenarnya diterjemah.

Bahagian AWS ialah laluan berasingan. Instans dalam subnet awam mencapai get laluan internet secara langsung dan mengekalkan alamat awam atau IP elastiknya. Instans dalam subnet peribadi memerlukan laluan ke get laluan NAT atau instans NAT, dan peranti NAT memerlukan laluannya sendiri ke get laluan internet. Melampirkan get laluan internet pada VPC tidak dengan sendirinya memberi mana-mana sumber peribadi alamat balasan awam, sebab itulah persediaan Access Server yang sama berfungsi dalam satu subnet dan gagal secara senyap dalam subnet yang lain.

Semak jadual laluan yang berkaitan dengan subnet instans, bukan hanya jadual utama VPC. Persatuan subnet mengatasi jadual utama, dan persatuan lapuk ialah punca biasa konfigurasi yang berfungsi berhenti selepas pembinaan semula.

Asingkan keluar IP dan DNS

Uji literal alamat dahulu, kemudian nama, daripada aplikasi pelanggan yang sama. Jika curl -4 https://checkip.amazonaws.com memulangkan alamat awam tetapi nama hos gagal, tunnel dan laluan NAT berfungsi dan masalahnya ialah DNS: penyelesai yang dihantar, keadaan penyelesai pelanggan, atau kumpulan keselamatan yang menyekat penyelesai. Tetapan DNS Access Server berada dalam kawasan Internet Access yang sama, tetapi ia melalui laluan kod yang berbeza.

Bandingkan alamat yang dipulangkan dengan keluar yang anda maksudkan. Jika ia alamat awam instans, trafik diterjemah oleh instans; jika ia alamat get laluan NAT, laluan subnet peribadi digunakan. Kedua-duanya boleh betul. Apa yang anda tidak boleh simpulkan ialah pelayar pada pelayan membuktikan penghantaran pelanggan.

Jangan biarkan satu kotak semak menutup siasatan

IPv6 ialah keputusan berasingan. Dasar tunnel penuh untuk IPv4 tidak mengatakan apa-apa tentang sama ada IPv6 dibawa, disekat atau bocor, dan pelanggan dua tindanan boleh terus menggunakan laluan IPv6 setempatnya semasa IPv4 berada dalam tunnel. Uji keluarga alamat yang benar-benar anda pentingkan, dan putuskan secara jelas sama ada yang lain patut dimatikan.

Akhir sekali, uji keadaan terputus. Pilihan tunnel penuh menerangkan dasar penghalaan semasa bersambung, bukan apa yang berlaku apabila tunnel jatuh. Jika keperluannya ialah tiada trafik terlepas ke luar VPN, itu soalan kill-switch dan tembok api, dan ia memerlukan ujiannya sendiri dan bukannya kesimpulan daripada jadual laluan.