IP klien VPN dalam Kubernetes: kekalkan atau SNAT?

Di suatu tempat antara terowong dan backend, alamat klien sama ada kekal atau diganti, dan kedua-dua hasil boleh dipertahankan. Pilihan itu milik pemilik perkhidmatan penerima, bukan pemilik yang memasang CNI. Apabila kebenaran bagi setiap klien, kuota atau rekod audit penting, alamat mesti bertahan setiap hop. Apabila atribusi bersama boleh diterima, NAT sumber menghapuskan masalah penghalaan yang jika tidak akan anda selenggara selama-lamanya.

Di mana alamat klien sebenarnya hilang

Paket klien jauh tiba di pod VPN dengan sumber dalaman dalam julat terowong, katakan 10.90.0.42. Apabila pod memajukan paket itu ke arah ClusterIP atau IP pod, tiga mekanisme berbeza boleh menulis semula sumbernya. Peraturan masquerade CNI pada nod meliputi trafik yang dihantar pod ke luar CIDR kluster. Entri conntrack kube-proxy pada nod destinasi meliputi hop ke Service itu sendiri. Proksi yang menamatkan sambungan tidak memajukan paket langsung, jadi sumber yang akhirnya anda lihat milik proksi itu.

Setiap satu hidup dalam lapisan berbeza, sebab itu satu medan Service hampir tidak pernah membaiki seluruh laluan.

externalTrafficPolicy pada Service awam VPN hanya memutuskan apa yang berlaku pada sambungan luar: Local mengekalkan alamat jauh pada nod yang menerimanya, manakala Cluster membenarkan kube-proxy menyerahkan paket kepada nod lain dan melakukan masquerade di sana. Tetapan itu mengawal listener yang dihubungi klien anda. Ia tidak mengatakan apa-apa tentang paket yang dinyahsulit yang diproses VPN anda ke dalam kluster selepas itu.

Tiga syarat yang menyelesaikan perdebatan

Saya bertanya tiga soalan yang sama dalam urutan yang sama setiap kali perkara ini timbul, kerana yang pertama biasanya menamatkan perbincangan. Jawablah untuk beban kerja tertentu, bukan untuk seluruh kluster. Dua kluster dalam satu syarikat boleh sampai kepada jawapan berbeza dan kedua-duanya betul.

Jika backend menjawab ya pada soalan pertama dan tidak pada yang kedua, anda mempunyai kerja rangkaian, bukan manifest untuk diedit. Jika baris ketiga berkata proksi, alamat itu tidak akan pernah bertahan, dan berpura-pura sebaliknya menelan masa seminggu menangkap paket.

Apa yang dituntut mod preserve daripada rangkaian

Mengekalkan sumber bermakna nod destinasi mesti memulangkan trafik ke 10.90.0.42 melalui gateway VPN yang aktif. Kolam VPN bukan CIDR kluster, jadi tiada CNI menghalakannya untuk anda secara lalai. Anda menambah laluan itu sendiri, kemudian memastikan titik akhir gateway yang ditujunya bertahan daripada penjadualan semula.

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

Hop seterusnya ialah alamat pod, dan alamat pod bergerak. Halakan laluan ke VIP Service atau alamat nod yang kekal di tempatnya, atau terima bahawa anda akan mengejar gateway selepas setiap pengusiran. Penapisan laluan balik ialah perangkap yang lain: mod ketat menggugurkan paket yang laluan baliknya tidak sepadan dengan antara muka tempat ia masuk, dan itulah tepat bentuk aliran VPN yang dikekalkan.

Pengesahan longgar selalunya menjadi perbezaan antara laluan balik yang berfungsi dan jawapan yang hilang selepas meninggalkan backend. Peraturan masquerade pada nod VPN juga mesti mengecualikan julat terowong, jika tidak paket yang dimajukan keluar dengan alamat pod, tidak kira laluan yang anda bina. Lebih baik nyatakan pengecualian itu dalam konfigurasi CNI itu sendiri daripada menyunting iptables dengan tangan, kerana ejen menulis semula rantaiannya semasa mula semula dan peraturan tulisan tangan anda bertahan tepat sehingga peningkatan seterusnya.

NetworkPolicy ialah kawalan akses, bukan penghalaan. Memperketat dasar tidak akan pernah memulihkan alamat yang sudah diganti masquerade.

Berapa kos SNAT, dan bagaimana mencatatnya

NAT sumber ke arah kluster ialah reka bentuk yang lebih murah, dan itu bukan kesilapan. Backend melihat alamat pod atau nod VPN, log saling sepadan, dan tiada laluan balik perlu wujud. Apa yang anda hilang ialah keupayaan membezakan dua klien pada lapisan rangkaian, jadi kuota, larangan dan jejak audit mesti datang dari tempat lain.

Biasanya tempat lain itu ialah aplikasi: token sesi, pengepala bertandatangan, atau baris protokol PROXY yang ditulis proksi yang anda kawal. Semua ini memberi penerima identiti yang hanya boleh dipercayai apabila proksi berada di laluan dan pengepala tidak boleh ditetapkan dari sisi klien. Jelaskan dalam runbook yang mana terpakai, kerana jurutera seterusnya akan menganggap alamat dalam log ialah klien. Bukan, dan satu insiden cukup untuk menjadikan andaian itu mahal.

Pertukaran itu kekal jujur selagi ia dicatat.

Semakan yang memisahkan laluan berfungsi daripada laluan bertuah

Uji dengan sambungan baharu, bukan yang di-cache, dan uji dalam kedua-dua arah. Beberapa kegagalan kelihatan berselang-seli hanya kerana aliran baharu mengambil laluan yang ditulis semula.

Tangkap tuple di tiga titik semasa satu permintaan dibenarkan: sejurus selepas penyahsulitan, pada antara muka keluar pod VPN, dan pada backend. Jika sumber berubah antara tangkapan kedua dan ketiga, puncanya di hilir pod. Jika berubah sebelum yang kedua, pod itu sendiri yang menterjemah.

Kemudian hapuskan pod VPN dan ulangi ujian semasa ia dijadualkan semula. Laluan yang dikekalkan tetapi rosak semasa pengusiran belum siap, begitu juga peraturan NAT yang dipasak pada alamat yang tidak wujud lagi. Akhir sekali, hantar satu permintaan daripada sumber yang anda jangkakan ditolak dan sahkan penolakan itu datang daripada dasar, bukan daripada laluan yang hilang.