Pelacakan sambungan ("conntrack") minangka fitur inti saka tumpukan jaringan kernel Linux. Ngidini kernel kanggo nglacak kabeh sambungan utawa aliran jaringan logis lan kanthi mangkono ngenali kabeh paket sing nggawe saben aliran supaya bisa diproses bebarengan kanthi urutan.
Conntrack minangka fitur kernel penting sing digunakake ing sawetara kasus dhasar:
- NAT gumantung ing informasi saka conntrack supaya bisa nambani kabeh paket saka stream padha merata. Contone, nalika pod ngakses layanan Kubernetes, kube-proxy load balancer nggunakake NAT kanggo ngarahake lalu lintas menyang pod tartamtu ing kluster. Conntrack nyathet yen kanggo sambungan sing diwenehake, kabeh paket menyang layanan IP kudu dikirim menyang polong sing padha, lan paket sing bali saka polong mburi kudu NATed bali menyang polong saka ngendi panjaluk kasebut teka.
- Firewall stateful kayata Calico gumantung ing informasi saka connecttrack kanggo whitelist "respon" lalu lintas. Iki ngidini sampeyan nulis kabijakan jaringan sing ujar "ngidini podku nyambung menyang alamat IP remot" tanpa kudu nulis kabijakan kanggo ngidini lalu lintas respon kanthi jelas. (Tanpa iki, sampeyan kudu nambah aturan "ngidini paket menyang pod saka IP apa wae" sing luwih aman.)
Kajaba iku, conntrack biasane nambah kinerja sistem (kanthi nyuda konsumsi CPU lan latensi paket) amarga mung paket pisanan ing stream.
kudu ngliwati kabeh tumpukan jaringan kanggo nemtokake apa sing kudu ditindakake. Deleng postingane""Kanggo ndeleng conto cara kerjane.
Nanging, conntrack duwe watesan ...
Dadi ing ngendi kabeh iku salah?
Tabel conntrack wis ukuran maksimum configurable, lan yen nemu lengkap, sambungan biasane miwiti ditolak utawa dropped. Ana cukup ruang kosong ing meja kanggo nangani lalu lintas paling akeh aplikasi, lan iki ora bakal dadi masalah. Nanging, ana sawetara skenario sing sampeyan pengin nimbang nggunakake tabel conntrack:
- Kasus sing paling jelas yaiku yen server sampeyan nangani akeh banget sambungan aktif bebarengan. Contone, yen tabel conntrack wis diatur kanggo 128k entri, nanging sampeyan duwe> 128k sambungan bebarengan, sampeyan mesthi bakal nemu masalah!
- Kasus sing rada kurang jelas: yen server sampeyan ngolah akeh banget sambungan per detik. Sanajan sambungan kasebut ora suwe, dheweke terus dipantau dening Linux kanggo sawetara wektu (120s minangka standar). Contone, yen tabel conntrack wis diatur kanggo 128k entri lan sampeyan nyoba kanggo nangani 1100 sambungan per detik, padha bakal ngluwihi ukuran meja conntrack, malah yen sambungan banget short-urip (128k / 120s = 1092 sambungan / s).
Ana sawetara jinis niche app sing kalebu ing kategori kasebut. Kajaba iku, yen sampeyan duwe akeh aktor ala, ngisi tabel conntrack server sampeyan kanthi akeh sambungan setengah mbukak bisa digunakake minangka bagean saka serangan penolakan layanan (DOS). Ing kasus loro, conntrack bisa dadi bottleneck watesan ing sistem sampeyan. Ing sawetara kasus, nyetel paramèter tabel conntrack bisa uga cukup kanggo nyukupi kabutuhan sampeyan - kanthi nambah ukuran utawa nyuda wektu entek conntrack (nanging yen sampeyan salah, sampeyan bakal ngalami masalah). Kanggo kasus liyane, sampeyan kudu ngliwati conntrack kanggo lalu lintas agresif.
Tuladha nyata
Ayo menehi conto tartamtu: siji panyedhiya SaaS gedhe kita kerjo karo wis sawetara server memcached ing sarwa dumadi (dudu mesin virtual), saben kang diproses 50K + sambungan short-term per detik.
Padha experimented karo konfigurasi conntrack, nambah ukuran meja lan ngurangi wektu nelusuri, nanging konfigurasi ora bisa dipercaya, konsumsi RAM mundhak Ngartekno, kang ana masalah (ing urutan GBytes!), Lan sambungan padha cendhak supaya conntrack ora. nggawe keuntungan kinerja biasanipun (suda CPU konsumsi utawa latensi paket).
Padha nguripake Calico minangka alternatif. Kawicaksanan jaringan Calico ngidini sampeyan ora nggunakake conntrack kanggo jinis lalu lintas tartamtu (nggunakake pilihan kabijakan doNotTrack). Iki menehi tingkat kinerja sing dibutuhake, ditambah karo tingkat keamanan tambahan sing diwenehake dening Calico.
Apa dawa sing kudu sampeyan lakoni kanggo ngliwati conntrack?
- Kawicaksanan jaringan Do-not-track umume kudu simetris. Ing kasus panyedhiya SaaS: aplikasi kasebut mlaku ing zona sing dilindhungi lan mulane, kanthi nggunakake kabijakan jaringan, dheweke bisa nampilake lalu lintas putih saka aplikasi tartamtu liyane sing diidini akses menyang memcached.
- Kabijakan do-not-track ora njupuk menyang akun arah sambungan. Mangkono, yen server memcached disusupi, sampeyan bisa kanthi teoritis nyoba nyambung menyang klien memcached, anggere nggunakake port sumber sing bener. Nanging, yen sampeyan wis netepake kabijakan jaringan kanthi bener kanggo klien memcached sampeyan, mula upaya sambungan kasebut isih bakal ditolak ing sisih klien.
- Kabijakan do-not-track ditrapake kanggo saben paket, minangka lawan saka kabijakan normal, sing mung ditrapake kanggo paket pisanan ing aliran. Iki bisa nambah konsumsi CPU saben paket amarga kabijakan kudu ditrapake kanggo saben paket. Nanging kanggo sambungan short-urip, beyo iki imbang dening abang ing konsumsi sumber daya kanggo Processing conntrack. Contone, ing kasus panyedhiya SaaS, jumlah paket kanggo saben sambungan cilik banget, saΓ©ngga konsumsi CPU tambahan nalika ngetrapake kabijakan kanggo saben paket dibenerake.
Ayo dadi miwiti tes
We mbukak test ing polong siji karo server memcached lan sawetara polong klien memcached mlaku ing kelenjar remot supaya kita bisa mbukak nomer akeh banget sambungan per detik. Server karo polong server memcached wis 8 intine lan 512k entri ing meja conntrack (ukuran meja diatur standar kanggo inang).
Kita ngukur prabΓ©dan kinerja antarane: ora ana kabijakan jaringan; karo kabijakan Calico biasa; lan kebijakan Calico do-not-track.
Kanggo tes pisanan, kita nyetel jumlah sambungan dadi 4.000 per detik, supaya kita bisa fokus ing prabΓ©dan ing konsumsi CPU. Ora ana bedane sing signifikan antarane ora ana kabijakan lan kabijakan reguler, nanging aja-aja nglacak konsumsi CPU kira-kira 20%:
Ing tes kapindho, kita ngluncurake akeh sambungan sing bisa ditindakake klien lan ngukur jumlah maksimum sambungan per detik sing bisa ditangani server memcached. Kaya sing dikarepake, kasus "ora ana kabijakan" lan "kabijakan biasa" loro-lorone tekan watesan conntrack luwih saka 4,000 sambungan per detik (512k / 120s = 4,369 sambungan / s). Kanthi kabijakan do-not-track, klien kita ngirim 60,000 sambungan per detik tanpa masalah. Kita yakin bisa nambah jumlah iki kanthi nambahake luwih akeh klien, nanging kita rumangsa nomer kasebut wis cukup kanggo nggambarake titik artikel iki!
kesimpulan
Conntrack minangka fitur kernel penting. Dheweke nindakake pakaryan kanthi sampurna. Asring digunakake dening komponen sistem kunci. Nanging, ing sawetara skenario tartamtu, kemacetan amarga conntrack luwih gedhe tinimbang keuntungan normal sing diwenehake. Ing skenario iki, kawicaksanan jaringan Calico bisa digunakake kanggo selektif mateni panggunaan conntrack nalika nambah keamanan jaringan. Kanggo kabeh lalu lintas liyane, conntrack terus dadi kanca!
Uga maca artikel liyane ing blog kita:
Source: www.habr.com