Mengapa GRE dan ESP gagal melalui gateway NAT AWS

Tunnel gagal, grup keamanan sudah mengizinkan semua lalu lintas, dan kesimpulannya adalah AWS memblokir VPN. AWS tidak memblokir apa pun. Gateway NAT terkelola meneruskan sekumpulan protokol luar yang terdokumentasi, dan GRE asli atau ESP asli tidak termasuk di dalamnya, jadi tidak ada aturan yang Anda tambahkan dapat membuat gateway membawanya. Aturan izin dan kemampuan transportasi adalah dua hal berbeda, dan hanya satu di antaranya yang dapat Anda ubah.

Kumpulan aturan bukan kumpulan protokol

Grup keamanan memutuskan lalu lintas mana yang diizinkan meninggalkan instans. Gateway NAT memutuskan apa yang dapat diterjemahkan dan diteruskannya. Ketika batas kedua berlaku, aturan permisif menghasilkan persis gejala yang salah dibaca orang sebagai masalah firewall: paket meninggalkan instans, pertukaran kontrol bahkan dapat selesai, dan tidak ada yang tiba di peer.

Spesifikasi protokol gateway NAT dari AWS mencantumkan TCP, UDP, dan ICMP untuk layanan terkelola. Itulah seluruh kumpulan yang didukung. Aturan izin untuk protokol IP lain tidak dapat memperluasnya, karena aturan dievaluasi jauh sebelum jalur penerusan gateway tercapai.

Perbedaan ini penting karena kedua kegagalan tampak identik dari sisi klien dan memiliki perbaikan yang sama sekali berbeda.

PPTP menunjukkan mengapa uji port berbohong

PPTP adalah contoh lama paling jelas dari pemeriksaan port yang tidak membuktikan apa pun. Ia membuka koneksi kontrol TCP pada port 1723 lalu membawa data tunnel melalui GRE, yaitu protokol IP 47. Protokol 47 bukan port TCP 47, dan kedua angka itu tidak ada hubungannya satu sama lain selain berbagi digit.

Operator yang menguji konektivitas ke 1723 dan melihat jabat tangan selesai menyimpulkan jalur berfungsi. Lalu kanal data tidak pernah melewatkan satu paket pun, karena gateway tidak memiliki dukungan GRE untuk ditawarkan. Itu adalah tafsiran atas persyaratan protokol lama, bukan saran untuk menerapkan PPTP, yang sudah usang selama bertahun-tahun.

Penalaran yang sama berlaku untuk protokol apa pun yang kanal kontrolnya TCP atau UDP sementara jalur datanya bukan.

IPsec hanya bertahan sebagai UDP

IPsec adalah kasus di mana jawabannya bersyarat, bukan tidak mutlak. AWS mendokumentasikan NAT traversal sebagai pengaturan yang didukung untuk IPsec melalui gateway NAT. Dengan NAT-T yang dinegosiasikan, ESP dienkapsulasi di dalam UDP dan gateway melihat UDP biasa alih-alih protokol 50.

Mengizinkan UDP 4500 tidak membuat titik akhir menggunakan NAT traversal. Itu hanya mengizinkan paket jika sudah berbentuk demikian. Konfirmasikan dari keluaran negosiasi klien sendiri enkapsulasi mana yang dipilih, dan konfirmasikan di sisi penerima bahwa peer menerimanya. Dua titik akhir yang dikonfigurasi untuk ESP asli akan terus mengirim ESP asli, apa pun kata kumpulan aturan.

VPN berbasis TCP atau UDP cocok dengan kumpulan transportasi yang terdokumentasi dan tetap dapat gagal karena alasan perutean, penyaringan, atau autentikasi. Cocok dengan kumpulan itu perlu, bukan cukup.

Periksa jalur sebelum memperluas kebijakan

Verifikasi rute sebenarnya subnet beban kerja dan identitas hop berikutnya lebih dahulu. Jalur publik langsung, instans NAT, gateway NAT terkelola, dan jalur privat melalui gateway transit adalah empat desain berbeda, dan hanya satu di antaranya adalah layanan terkelola yang dijelaskan di sini.

Lalu catat titik akhir yang dicoba, keluarga alamat, protokol luar, dan port jika protokol memiliki port. Gunakan diagnostik klien dan pengamatan aliran pemilik jaringan alih-alih permintaan peramban yang berhasil, yang hanya membuktikan TCP dan UDP berfungsi. Setelah itu, tinjau grup keamanan, ACL subnet, firewall tamu, dan kebijakan layanan untuk kedua arah aliran.

Jangan membuka semua lalu lintas untuk mengimbangi transportasi yang tidak dapat dibawa layanan. Perubahan aturan tidak akan memperbaikinya, dan itu akan bertahan melewati insiden.

Ketika transportasi tidak cocok

Jika protokol luar berada di luar kumpulan yang didukung, perbaikannya bersifat arsitektural: pilih transportasi yang dapat dibawa jalur, atau pindahkan egress ke sesuatu yang membawa yang Anda butuhkan. OpenVPN melalui UDP, WireGuard melalui UDP, dan tunnel berbasis TLS semuanya cocok dengan kumpulan terdokumentasi. Instans NAT yang dikelola pelanggan adalah pilihan ketika protokol tertentu harus lewat dan biaya operasional menjalankannya dapat diterima.

Meng-hosting server VPN masuk adalah masalah terpisah dengan jawaban terpisah. Gateway NAT menyediakan terjemahan keluar dan tidak menyediakan penerusan port masuk umum, jadi server di belakangnya memerlukan entri publiknya yang disetujui yang dirancang menurut ketentuannya sendiri.

Urutan kerja: sebutkan protokol luar, konfirmasikan hop berikutnya, bandingkan dengan kumpulan terdokumentasi, lalu ubah arsitektur atau transportasi. Nomor port yang berbeda tidak dapat mengubah GRE menjadi TCP, dan satu aturan permisif lagi tidak dapat mengubah pertukaran kontrol yang selesai menjadi kanal data yang berfungsi.