IP klien VPN di Kubernetes: pertahankan atau SNAT?

Di suatu titik antara tunnel dan backend, alamat klien entah bertahan atau diganti, dan kedua hasil bisa dipertahankan. Pilihan itu milik pemilik layanan penerima, bukan pemilik yang memasang CNI. Ketika otorisasi per klien, kuota, atau catatan audit penting, alamat harus bertahan di setiap lompatan. Ketika atribusi bersama dapat diterima, NAT sumber menghapus masalah perutean yang jika tidak akan Anda pelihara selamanya.

Di mana alamat klien sebenarnya menghilang

Paket klien jarak jauh tiba di pod VPN dengan sumber internal di dalam rentang tunnel, misalnya 10.90.0.42. Ketika pod meneruskan paket itu menuju ClusterIP atau IP pod, tiga mekanisme berbeda dapat menulis ulang sumbernya. Aturan masquerade CNI pada node mencakup lalu lintas yang dikirim pod ke luar CIDR klaster. Entri conntrack kube-proxy pada node tujuan mencakup lompatan ke Service itu sendiri. Proxy yang mengakhiri koneksi tidak meneruskan paket sama sekali, jadi sumber yang akhirnya Anda lihat milik proxy itu.

Masing-masing hidup di lapisan berbeda, karena itu satu bidang Service hampir tidak pernah memperbaiki seluruh jalur.

externalTrafficPolicy pada Service publik VPN hanya memutuskan apa yang terjadi pada koneksi luar: Local mempertahankan alamat jarak jauh di node yang menerimanya, sedangkan Cluster membiarkan kube-proxy menyerahkan paket ke node lain dan melakukan masquerade di sana. Pengaturan itu mengatur listener yang dihubungi klien Anda. Ia tidak mengatakan apa pun tentang paket terdekripsi yang proses VPN Anda arahkan ke klaster setelahnya.

Tiga syarat yang menyelesaikan perdebatan

Saya mengajukan tiga pertanyaan yang sama dalam urutan yang sama setiap kali hal ini muncul, karena yang pertama biasanya mengakhiri diskusi. Jawablah untuk beban kerja tertentu, bukan untuk klaster secara keseluruhan. Dua klaster dalam satu perusahaan bisa sampai pada jawaban berbeda dan keduanya benar.

Jika backend menjawab ya pada pertanyaan pertama dan tidak pada yang kedua, Anda punya pekerjaan jaringan, bukan manifest untuk diedit. Jika baris ketiga mengatakan proxy, alamat itu tidak akan pernah bertahan, dan berpura-pura sebaliknya memakan waktu seminggu penangkapan paket.

Apa yang dituntut mode preserve dari jaringan

Mempertahankan sumber berarti node tujuan harus mengembalikan lalu lintas ke 10.90.0.42 melalui gateway VPN yang aktif. Kumpulan VPN bukan CIDR klaster, jadi tidak ada CNI yang merutekannya untuk Anda secara bawaan. Anda menambahkan rutenya sendiri, lalu memastikan titik akhir gateway yang dituju bertahan dari penjadwalan ulang.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Lompatan berikutnya adalah alamat pod, dan alamat pod berpindah. Arahkan rute ke VIP Service atau alamat node yang tetap di tempatnya, atau terima bahwa Anda akan mengejar gateway setelah setiap pengusiran. Penyaringan jalur balik adalah jebakan lainnya: mode ketat membuang paket yang jalur baliknya tidak cocok dengan antarmuka tempat paket itu masuk, dan itulah persis bentuk aliran VPN yang dipertahankan.

Validasi longgar sering menjadi pembeda antara jalur balik yang berfungsi dan jawaban yang menghilang setelah meninggalkan backend. Aturan masquerade pada node VPN juga harus mengecualikan rentang tunnel, jika tidak paket yang diteruskan keluar dengan alamat pod, apa pun rute yang Anda bangun. Lebih baik nyatakan pengecualian itu dalam konfigurasi CNI itu sendiri daripada mengedit iptables dengan tangan, karena agen menulis ulang rantainya saat mulai ulang dan aturan tulisan tangan Anda bertahan tepat sampai peningkatan berikutnya.

NetworkPolicy adalah kontrol akses, bukan perutean. Memperketat kebijakan tidak akan pernah memulihkan alamat yang sudah diganti masquerade.

Berapa biaya SNAT, dan bagaimana menuliskannya

NAT sumber menuju klaster adalah rancangan yang lebih murah, dan itu bukan kesalahan. Backend melihat alamat pod atau node VPN, log saling cocok, dan tidak perlu ada rute balik. Yang Anda kehilangan adalah kemampuan membedakan dua klien di lapisan jaringan, jadi kuota, larangan, dan jejak audit harus datang dari tempat lain.

Biasanya tempat lain itu adalah aplikasi: token sesi, header bertanda tangan, atau baris protokol PROXY yang ditulis proxy yang Anda kendalikan. Semua itu memberi penerima identitas yang hanya bisa dipercaya ketika proxy berada di jalur dan header tidak dapat diatur dari sisi klien. Bersikaplah eksplisit di runbook tentang mana yang berlaku, karena insinyur berikutnya akan menganggap alamat di log adalah klien. Bukan, dan satu insiden cukup untuk membuat anggapan itu mahal.

Pertukaran itu tetap jujur selama dituliskan.

Pemeriksaan yang memisahkan jalur yang berfungsi dari yang beruntung

Ujilah dengan koneksi baru, bukan yang di-cache, dan uji di kedua arah. Beberapa kegagalan tampak berselang hanya karena aliran baru menempuh jalur yang ditulis ulang.

Tangkap tuple di tiga titik selama satu permintaan resmi: tepat setelah dekapsulasi, pada antarmuka keluar pod VPN, dan pada backend. Jika sumber berubah antara tangkapan kedua dan ketiga, penyebabnya ada di hilir pod. Jika berubah sebelum yang kedua, pod itu sendiri yang menerjemahkan.

Lalu hapus pod VPN dan ulangi pengujian sementara pod dijadwalkan ulang. Jalur yang dipertahankan tetapi rusak saat pengusiran belum selesai, begitu pula aturan NAT yang dipasang pada alamat yang tidak ada lagi. Terakhir, kirim satu permintaan dari sumber yang Anda harapkan ditolak dan pastikan penolakan itu datang dari kebijakan, bukan dari rute yang hilang.