Pelacakan koneksi (“conntrack”) adalah fitur inti dari tumpukan jaringan kernel Linux. Hal ini memungkinkan kernel untuk melacak semua koneksi atau aliran jaringan logis dan dengan demikian mengidentifikasi semua paket yang membentuk setiap aliran sehingga mereka dapat diproses bersama secara berurutan.
Conntrack adalah fitur kernel penting yang digunakan dalam beberapa kasus dasar:
- NAT mengandalkan informasi dari conntrack sehingga dapat memperlakukan semua paket dari aliran yang sama secara setara. Misalnya, ketika sebuah pod mengakses layanan Kubernetes, penyeimbang beban kube-proxy menggunakan NAT untuk mengarahkan lalu lintas ke pod tertentu di dalam cluster. Conntrack mencatat bahwa untuk koneksi tertentu, semua paket ke layanan IP harus dikirim ke pod yang sama, dan paket yang dikembalikan oleh pod backend harus di-NAT kembali ke pod tempat permintaan datang.
- Firewall stateful seperti Calico mengandalkan informasi dari jalur koneksi ke lalu lintas “respons” yang masuk daftar putih. Hal ini memungkinkan Anda untuk menulis kebijakan jaringan yang menyatakan "izinkan pod saya terhubung ke alamat IP jarak jauh mana pun" tanpa harus menulis kebijakan yang secara eksplisit mengizinkan lalu lintas respons. (Tanpa ini, Anda harus menambahkan aturan "izinkan paket ke pod saya dari IP mana pun" yang jauh lebih tidak aman.)
Selain itu, conntrack biasanya meningkatkan kinerja sistem (dengan mengurangi konsumsi CPU dan latensi paket) karena hanya paket pertama dalam suatu aliran
harus menelusuri seluruh tumpukan jaringan untuk menentukan apa yang harus dilakukan dengannya. Lihat postingannya"" untuk melihat contoh cara kerjanya.
Namun, contrack memiliki keterbatasan...
Jadi di mana letak kesalahannya?
Tabel conntrack memiliki ukuran maksimum yang dapat dikonfigurasi, dan jika penuh, koneksi biasanya mulai ditolak atau terputus. Ada cukup ruang kosong di tabel untuk menangani lalu lintas sebagian besar aplikasi, dan ini tidak akan menjadi masalah. Namun, ada beberapa skenario yang mungkin ingin Anda pertimbangkan untuk menggunakan tabel conntrack:
- Kasus yang paling jelas adalah jika server Anda menangani koneksi aktif bersamaan dalam jumlah yang sangat besar. Misalnya, jika tabel conntrack Anda dikonfigurasi untuk 128k entri, tetapi Anda memiliki >128k koneksi bersamaan, Anda pasti akan mengalami masalah!
- Kasus yang kurang jelas: jika server Anda memproses koneksi dalam jumlah yang sangat besar per detik. Sekalipun koneksinya berumur pendek, koneksi tersebut terus dipantau oleh Linux untuk jangka waktu tertentu (120 detik secara default). Misalnya, jika tabel conntrack Anda dikonfigurasi untuk 128k entri dan Anda mencoba menangani 1100 koneksi per detik, mereka akan melebihi ukuran tabel conntrack, bahkan jika koneksi berumur sangat pendek (128k/120s = 1092 koneksi/ S).
Ada beberapa jenis aplikasi khusus yang termasuk dalam kategori ini. Selain itu, jika Anda memiliki banyak pelaku jahat, mengisi tabel koneksi server Anda dengan banyak koneksi setengah terbuka dapat digunakan sebagai bagian dari serangan penolakan layanan (DOS). Dalam kedua kasus tersebut, koneksi dapat menjadi hambatan yang membatasi sistem Anda. Dalam beberapa kasus, menyesuaikan parameter tabel conntrack mungkin cukup untuk memenuhi kebutuhan Anda - dengan meningkatkan ukuran atau mengurangi batas waktu conntrack (tetapi jika Anda salah melakukannya, Anda akan mengalami banyak masalah). Untuk kasus lain, perlu melewati jalur koneksi untuk lalu lintas yang agresif.
Contoh nyata
Mari kita berikan contoh spesifik: salah satu penyedia SaaS besar yang bekerja sama dengan kami memiliki sejumlah server memcache di host (bukan mesin virtual), yang masing-masing memproses 50 ribu+ koneksi jangka pendek per detik.
Mereka bereksperimen dengan konfigurasi conntrack, meningkatkan ukuran tabel dan mengurangi waktu pelacakan, namun konfigurasi tersebut tidak dapat diandalkan, konsumsi RAM meningkat secara signifikan, yang merupakan masalah (dalam urutan GBytes!), dan koneksi sangat pendek sehingga conntrack tidak melakukannya. menciptakan manfaat kinerja seperti biasanya (pengurangan konsumsi CPU atau latensi paket).
Mereka beralih ke Calico sebagai alternatif. Kebijakan jaringan Calico memungkinkan Anda untuk tidak menggunakan conntrack untuk jenis lalu lintas tertentu (menggunakan opsi kebijakan doNotTrack). Hal ini memberi mereka tingkat kinerja yang mereka perlukan, ditambah tingkat keamanan tambahan yang disediakan oleh Calico.
Berapa jarak yang harus Anda tempuh untuk melewati jalur penghubung?
- Kebijakan jaringan jangan lacak umumnya harus simetris. Dalam kasus penyedia SaaS: aplikasi mereka berjalan di dalam zona terlindungi dan oleh karena itu, dengan menggunakan kebijakan jaringan, mereka dapat memasukkan lalu lintas ke daftar putih dari aplikasi spesifik lain yang diizinkan mengakses memcached.
- Kebijakan jangan lacak tidak memperhitungkan arah koneksi. Jadi, jika server memcached diretas, secara teoritis Anda dapat mencoba menyambung ke salah satu klien memcached, asalkan menggunakan port sumber yang benar. Namun, jika Anda telah menentukan dengan benar kebijakan jaringan untuk klien memcache Anda, maka upaya koneksi ini akan tetap ditolak di sisi klien.
- Kebijakan jangan lacak diterapkan pada setiap paket, berbeda dengan kebijakan normal, yang hanya diterapkan pada paket pertama dalam suatu aliran. Hal ini dapat meningkatkan konsumsi CPU per paket karena kebijakan harus diterapkan untuk setiap paket. Namun untuk sambungan berumur pendek, biaya ini diimbangi dengan pengurangan konsumsi sumber daya untuk pemrosesan sambungan. Misalnya, dalam kasus penyedia SaaS, jumlah paket untuk setiap koneksi sangat kecil, sehingga konsumsi CPU tambahan saat menerapkan kebijakan pada setiap paket dapat dibenarkan.
Mari kita mulai pengujian
Kami menjalankan pengujian pada satu pod dengan server memcached dan beberapa pod klien memcached yang berjalan pada node jarak jauh sehingga kami dapat menjalankan koneksi dalam jumlah yang sangat besar per detik. Server dengan pod server memcached memiliki 8 core dan 512k entri di tabel conntrack (ukuran tabel standar yang dikonfigurasi untuk host).
Kami mengukur perbedaan kinerja antara: tidak ada kebijakan jaringan; dengan kebijakan Calico reguler; dan kebijakan jangan lacak Calico.
Untuk pengujian pertama, kami menetapkan jumlah koneksi menjadi 4.000 per detik, sehingga kami dapat fokus pada perbedaan konsumsi CPU. Tidak ada perbedaan yang signifikan antara tanpa kebijakan dan kebijakan reguler, namun jangan lacak peningkatan konsumsi CPU sekitar 20%:
Pada pengujian kedua, kami meluncurkan koneksi sebanyak yang dapat dihasilkan klien kami dan mengukur jumlah maksimum koneksi per detik yang dapat ditangani oleh server memcached kami. Seperti yang diharapkan, kasus “tanpa kebijakan” dan “kebijakan reguler” keduanya mencapai batas koneksi lebih dari 4,000 koneksi per detik (512k / 120d = 4,369 koneksi/dtk). Dengan kebijakan jangan lacak, klien kami mengirimkan 60,000 koneksi per detik tanpa masalah. Kami yakin kami dapat meningkatkan jumlah ini dengan menambahkan lebih banyak klien, namun kami merasa jumlah ini sudah cukup untuk menggambarkan inti artikel ini!
Kesimpulan
Conntrack adalah fitur kernel yang penting. Dia melakukan pekerjaannya dengan sempurna. Ini sering digunakan oleh komponen sistem utama. Namun, dalam beberapa skenario tertentu, kemacetan akibat sambungan melebihi manfaat normal yang diberikannya. Dalam skenario ini, kebijakan jaringan Calico dapat digunakan untuk menonaktifkan penggunaan conntrack secara selektif sekaligus meningkatkan keamanan jaringan. Untuk semua lalu lintas lainnya, conntrack terus menjadi teman Anda!
Baca juga artikel lainnya di blog kami:
Sumber: www.habr.com