Lalu lintas klien VPN dan status firewall: aliran luar dan dalam

Jabat tangan VPN selesai, klien mendapat alamat, dan layanan di balik gateway tetap menolak koneksi. Firewall sering melakukan persis apa yang diperintahkan. Ia mengizinkan aliran terowongan luar, yang merupakan paket berbeda dari koneksi aplikasi yang didekapsulasi. Dua keputusan menyusul: aliran mana yang Anda izinkan, dan apakah batas itu melacak status sama sekali.

Sampai Anda memisahkan keduanya, setiap perubahan aturan adalah tebakan.

Firewall melihat dua paket berbeda

Sebelum dekapsulasi, firewall melihat lalu lintas yang dialamatkan ke titik akhir VPN: aliran UDP luar ke pendengar. Setelah dekapsulasi, paket yang diteruskan membawa alamat dalam klien dan tujuan layanan.

Izin untuk aliran luar tidak mengesahkan koneksi TCP yang diteruskan. Keduanya dapat dievaluasi dalam rantai berbeda, terhadap antarmuka berbeda, dan dengan alamat berbeda setelah terjemahan.

Bandingkan tangkapan dari posisi setara di kedua sisi. Tangkapan di tepi terowongan dan tangkapan di server menunjukkan tuple berbeda untuk sesi yang sama.

Keputusan pertama: mengizinkan terowongan atau layanan

Jika klien hanya membutuhkan titik akhir VPN itu sendiri, izin luar mungkin cukup. Jika klien membutuhkan layanan di balik gateway, Anda perlu izin penerusan untuk tujuan dan port itu. Aturan terowongan yang juga mengizinkan layanan adalah pilihan desain yang sebaiknya Anda namai, bukan kecelakaan.

Jaga rentang klien dan cakupan layanan tetap sempit. Izin dari subnet terowongan ke seluruh LAN adalah keputusan untuk memercayai setiap host, bukan jalan pintas untuk satu aplikasi.

Tuliskan kedua aturan secara terpisah. Aturan terowongan dan aturan layanan gagal dengan cara berbeda dan di-debug dengan bukti berbeda. Saat salah satunya gagal, Anda tahu lapisan mana yang harus diperiksa lebih dulu.

Keputusan kedua: berstatus atau tanpa status di setiap batas

Aturan aliran mapan dapat menerima balasan untuk pertukaran yang diizinkan, tetapi perilakunya bergantung pada produk. Grup keamanan cloud biasanya melacak status; daftar kontrol subnet sering tidak melacak status dan memerlukan penanganan eksplisit di kedua arah. Jangan berasumsi setiap batas di jalur memperlakukan status dengan cara sama. Daftar setiap batas dan tandai berstatus atau tanpa status sebelum Anda merancang aturannya.

Jika aturan berubah, aliran terlacak yang ada dapat terus berfungsi sementara yang baru gagal, atau sebaliknya. Perbedaan itu petunjuk berguna, bukan alasan untuk mengosongkan seluruh status koneksi pada gateway yang aktif.

Uji dengan permintaan baru yang terkendali dan periksa penghitung yang relevan. Uji yang bersih lebih baik daripada reset yang mengganggu. Catat nama penghitung di catatan perubahan agar uji berikutnya memakai bukti yang sama.

Verifikasi jalur balik di bawah kebijakan yang sama

Kirim permintaan baru dari klien ke layanan, lalu periksa penghitung maju dan balik di setiap batas. Pastikan balasan memakai jalur yang Anda harapkan, terutama jika ada terjemahan.

Jaga rentang klien yang dimaksud dan cakupan layanan tetap sempit, dan verifikasi jalur balik di bawah kumpulan aturan yang sama yang mengizinkan permintaan. Aturan yang hanya berfungsi karena aliran lama masih terbuka bukanlah aturan yang berfungsi.