Mengapa GRE dan ESP gagal melalui gerbang NAT AWS
Gerbang NAT terurus hanya memajukan TCP, UDP dan ICMP. Lihat mengapa peraturan kebenaran tidak dapat membawa GRE atau ESP asli, dan apa yang perlu ditukar.
Terowong gagal, kumpulan keselamatan sudah membenarkan semua trafik, dan kesimpulannya ialah AWS menyekat VPN. Ia tidak menyekat apa-apa. Gerbang NAT terurus memajukan satu set protokol luar yang didokumenkan, dan GRE asli atau ESP asli tiada di dalamnya, jadi tiada peraturan yang anda tambah akan membuatkan gerbang membawanya. Peraturan kebenaran dan keupayaan pengangkutan ialah dua perkara berbeza, dan hanya satu daripadanya boleh anda ubah.
Set peraturan bukan set protokol
Kumpulan keselamatan menentukan trafik mana yang dibenarkan meninggalkan instans. Gerbang NAT menentukan apa yang mampu diterjemah dan dimajukan. Apabila had kedua terpakai, peraturan permisif menghasilkan tepat gejala yang orang salah baca sebagai masalah tembok api: paket meninggalkan instans, pertukaran kawalan mungkin juga selesai, dan tiada apa-apa sampai kepada rakan.
Spesifikasi protokol gerbang NAT AWS menyenaraikan TCP, UDP dan ICMP untuk perkhidmatan terurus. Itulah keseluruhan set yang disokong. Peraturan kebenaran untuk protokol IP lain tidak boleh meluaskannya, kerana peraturan dinilai jauh sebelum laluan pemajuan gerbang dicapai.
Perbezaan ini penting kerana kedua-dua kegagalan kelihatan sama dari sisi klien dan mempunyai pembetulan yang sama sekali berbeza.
PPTP menunjukkan mengapa ujian port berbohong
PPTP ialah contoh lama paling jelas bagi pemeriksaan port yang tidak membuktikan apa-apa. Ia membuka sambungan kawalan TCP pada port 1723 dan kemudian membawa data terowong melalui GRE, iaitu protokol IP 47. Protokol 47 bukan port TCP 47, dan kedua-dua nombor itu tiada kaitan antara satu sama lain selain berkongsi digit.
Pengendali yang menguji ketersambungan ke 1723 dan melihat jabat tangan selesai membuat kesimpulan bahawa laluan berfungsi. Kemudian saluran data tidak pernah melepasi satu paket pun, kerana gerbang tiada sokongan GRE untuk ditawarkan. Itu tafsiran keperluan protokol lama, bukan nasihat untuk menggunakan PPTP, yang sudah usang selama bertahun-tahun.
Penaakulan yang sama terpakai kepada mana-mana protokol yang saluran kawalannya TCP atau UDP manakala laluan datanya bukan.
IPsec hanya bertahan sebagai UDP
IPsec ialah kes di mana jawapannya bersyarat dan bukan tidak yang rata. AWS mendokumenkan NAT traversal sebagai susunan yang disokong untuk IPsec melalui gerbang NAT. Dengan NAT-T dirunding, ESP dikapsulkan dalam UDP dan gerbang melihat UDP biasa dan bukan protokol 50.
Membenarkan UDP 4500 tidak membuat titik akhir menggunakan NAT traversal. Ia hanya membenarkan paket jika ia sudah terbentuk begitu. Sahkan daripada output rundingan klien sendiri kapsulasi mana yang dipilih, dan sahkan di sisi penerima bahawa rakan telah menerimanya. Dua titik akhir yang dikonfigurasikan untuk ESP asli akan terus menghantar ESP asli, apa pun yang dikatakan set peraturan.
VPN berasaskan TCP atau UDP sesuai dengan set pengangkutan yang didokumenkan dan masih boleh gagal atas sebab penghalaan, penapisan atau pengesahan. Sesuai dengan set itu perlu, bukan mencukupi.
Semak laluan sebelum meluaskan dasar
Sahkan laluan sebenar subrangkaian beban kerja dan identiti hop seterusnya terlebih dahulu. Laluan awam langsung, instans NAT, gerbang NAT terurus dan laluan peribadi melalui gerbang transit ialah empat reka bentuk berbeza, dan hanya satu daripadanya ialah perkhidmatan terurus yang diterangkan di sini.
Kemudian rekod titik akhir yang dicuba, keluarga alamat, protokol luar dan port jika protokol mempunyai satu. Gunakan diagnostik klien dan pemerhatian aliran pemilik rangkaian dan bukannya permintaan pelayar yang berjaya, yang hanya membuktikan TCP dan UDP berfungsi. Selepas itu, semak kumpulan keselamatan, ACL subrangkaian, tembok api tetamu dan dasar perkhidmatan untuk kedua-dua arah aliran.
Jangan buka semua trafik untuk mengimbangi pengangkutan yang perkhidmatan tidak dapat bawa. Perubahan peraturan tidak akan membetulkannya, dan ia akan bertahan selepas insiden.
Apabila pengangkutan tidak sesuai
Jika protokol luar berada di luar set yang disokong, pembetulannya bersifat seni bina: pilih pengangkutan yang laluan boleh bawa, atau pindahkan egress ke sesuatu yang membawa yang anda perlukan. OpenVPN melalui UDP, WireGuard melalui UDP dan terowong berasaskan TLS semuanya sesuai dengan set yang didokumenkan. Instans NAT yang diuruskan pelanggan ialah pilihan apabila protokol tertentu mesti melalui dan kos operasi untuk menjalankannya boleh diterima.
Mengehos pelayan VPN masuk ialah masalah berasingan dengan jawapan berasingan. Gerbang NAT menyediakan terjemahan keluar dan tiada pemajuan port masuk umum, jadi pelayan di belakangnya memerlukan pintu masuk awamnya yang diluluskan yang direka mengikut termanya sendiri.
Urutan kerja: namakan protokol luar, sahkan hop seterusnya, bandingkan dengan set yang didokumenkan, kemudian ubah seni bina atau pengangkutan. Nombor port yang berbeza tidak boleh menjadikan GRE sebagai TCP, dan satu lagi peraturan permisif tidak boleh menjadikan pertukaran kawalan yang selesai sebagai saluran data yang berfungsi.