Pelacak sambungan ("conntrack") mangrupikeun fitur inti tina tumpukan jaringan kernel Linux. Hal ieu ngamungkinkeun kernel pikeun ngalacak sadaya sambungan jaringan atanapi aliran logis sareng ku kituna ngaidentipikasi sadaya pakét anu ngawangun unggal aliran supados tiasa diolah babarengan sacara berurutan.
Conntrack mangrupikeun fitur kernel penting anu dianggo dina sababaraha kasus dasar:
- NAT ngandelkeun inpormasi ti conntrack supados tiasa ngubaran sadaya pakét ti aliran anu sami. Contona, nalika pod ngakses layanan Kubernetes, kube-proxy load balancer ngagunakeun NAT pikeun ngarahkeun lalulintas ka pod husus dina kluster. Conntrack ngarekam yén pikeun sambungan dibikeun, sadaya pakét ka layanan IP kudu dikirim ka pod sarua, na yén pakét balik ku pod backend kudu NATed deui pod ti mana pamundut teh datang.
- firewalls stateful kayaning Calico ngandelkeun informasi ti connecttrack kana whitelist "réspon" lalulintas. Ieu ngidinan Anjeun pikeun nulis kawijakan jaringan nu nyebutkeun "ngidinan pod abdi nyambung ka sagala alamat IP jauh" tanpa kudu nulis kawijakan pikeun eksplisit ngidinan lalulintas respon. (Tanpa ieu, anjeun kedah nambihan aturan "ngidinan pakét kana pod kuring tina IP mana waé" anu langkung aman.)
Salaku tambahan, conntrack biasana ningkatkeun kinerja sistem (ku ngirangan konsumsi CPU sareng latency pakét) sabab ngan ukur pakét munggaran dina aliran.
kudu ngaliwatan sakabéh tumpukan jaringan pikeun nangtukeun naon nu kudu jeung eta. Tingali tulisanna""Pikeun ningali conto kumaha jalanna.
Sanajan kitu, conntrack boga watesan na ...
Janten dimana sadayana lepat?
Méja conntrack ngabogaan ukuran maksimum configurable, sarta lamun meunang pinuh, sambungan biasana mimiti ditolak atawa turun. Aya cukup rohangan bébas dina tabel pikeun nanganan lalu lintas kalolobaan aplikasi, sareng ieu moal janten masalah. Sanajan kitu, aya sababaraha skenario nu Anjeun meureun hoyong mertimbangkeun ngagunakeun tabel conntrack:
- Kasus anu paling atra nyaéta upami server anjeun ngadamel sajumlah ageung sambungan anu aktip sacara serentak. Contona, upami tabel conntrack anjeun ngonpigurasi pikeun 128k éntri, tapi anjeun gaduh> 128k sambungan babarengan, anjeun pasti bakal ngajalankeun kana masalah!
- Kasus anu rada teu jelas: upami server anjeun ngolah sajumlah ageung sambungan per detik. Sanaos sambunganna pondok, aranjeunna terus diawaskeun ku Linux pikeun sababaraha waktos (sacara standar 120an). Contona, upami tabel conntrack anjeun ngonpigurasi pikeun 128k éntri jeung anjeun nyobian pikeun nanganan 1100 sambungan per detik, aranjeunna bakal ngaleuwihan ukuran dina tabel conntrack, sanajan sambungan pisan pondok-cicing (128k / 120s = 1092 sambungan / s).
Aya sababaraha jinis aplikasi anu digolongkeun kana kategori ieu. Salaku tambahan, upami anjeun gaduh seueur aktor anu goréng, ngeusian méja conntrack server anjeun sareng seueur sambungan satengah kabuka tiasa dianggo salaku bagian tina serangan panolakan jasa (DOS). Dina duanana kasus, conntrack tiasa janten bottleneck ngawatesan dina sistem anjeun. Dina sababaraha kasus, nyaluyukeun parameter tabel conntrack bisa jadi cukup pikeun minuhan kabutuhan Anjeun - ku cara ningkatkeun ukuran atawa ngurangan conntrack timeouts (tapi lamun ngalakukeun eta salah, anjeun bakal ngajalankeun kana loba gangguan). Pikeun kasus séjén bakal diperlukeun pikeun bypass conntrack pikeun lalulintas agrésif.
conto nyata
Hayu urang masihan conto husus: salah sahiji panyadia SaaS badag kami gawé bareng miboga sajumlah server memcached on host (sanes mesin virtual), nu masing-masing ngolah 50K + sambungan jangka pondok per detik.
Aranjeunna experimented kalawan konfigurasi conntrack, ngaronjatna ukuran tabel sarta ngurangan waktu tracking, tapi konfigurasi éta teu bisa dipercaya, konsumsi RAM ngaronjat sacara signifikan, nu masalah (dina urutan GBytes!), Jeung sambungan anu jadi pondok nu conntrack henteu. nyiptakeun kauntungan kinerja anu biasa (pangurangan konsumsi CPU atanapi pakét latency).
Aranjeunna tos ka Calico salaku alternatif. Kawijakan jaringan Calico ngamungkinkeun anjeun henteu nganggo conntrack pikeun sababaraha jinis lalu lintas (nganggo pilihan kawijakan doNotTrack). Ieu masihan aranjeunna tingkat kinerja anu diperyogikeun, ditambah tingkat kaamanan tambahan anu disayogikeun ku Calico.
Sabaraha panjang anu anjeun kedah angkat pikeun ngalangkungan conntrack?
- Kawijakan jaringan Do-not-track kedah umumna simetris. Dina kasus panyadia SaaS: aplikasi maranéhanana ngajalankeun jero zona ditangtayungan sahingga, ngagunakeun kawijakan jaringan, aranjeunna bisa whitelist lalulintas tina aplikasi husus sejenna nu diwenangkeun aksés ka memcached.
- Kawijakan do-not-track henteu nganggap arah sambungan. Ku kituna, lamun server memcached ieu hacked, Anjeun sacara téoritis bisa nyoba nyambung ka salah sahiji klien memcached, salami eta ngagunakeun port sumber bener. Nanging, upami anjeun leres-leres netepkeun kabijakan jaringan pikeun klien memcached anjeun, usaha sambungan ieu masih bakal ditolak di sisi klien.
- Kawijakan do-not-track diterapkeun ka unggal pakét, sabalikna tina kawijakan normal, anu diterapkeun ngan kana pakét munggaran dina aliran. Ieu bisa ningkatkeun konsumsi CPU per pakét sabab kawijakan kudu dilarapkeun pikeun tiap pakét. Tapi pikeun sambungan pondok-cicing, expense ieu saimbang ku ngurangan di konsumsi sumberdaya pikeun ngolah conntrack. Contona, dina kasus panyadia SaaS, jumlah pakét pikeun tiap sambungan éta leutik pisan, jadi konsumsi CPU tambahan nalika nerapkeun kawijakan pikeun tiap pakét ieu diyakinkeun.
Hayu urang mimitian nguji
Urang ngajalankeun tés dina pod tunggal kalawan server memcached sarta sababaraha pods klien memcached ngajalankeun on titik jauh ku kituna urang bisa ngajalankeun jumlah anu kacida gedéna tina sambungan per detik. The server kalawan pod server memcached miboga 8 cores na 512k éntri dina tabel conntrack (ukuran tabel ngonpigurasi baku pikeun host teh).
Urang ngukur bédana kinerja antara: euweuh kawijakan jaringan; kalawan kawijakan Calico biasa; jeung kawijakan Calico do-not-track.
Pikeun tés kahiji, urang nyetel jumlah sambungan kana 4.000 per detik, sangkan bisa difokuskeun bédana dina konsumsi CPU. Henteu aya béda anu signifikan antara henteu aya kawijakan sareng kabijakan biasa, tapi henteu ngalacak paningkatan konsumsi CPU sakitar 20%:
Dina tés kadua, kami dibuka saloba sambungan sakumaha klien kami bisa ngahasilkeun sarta diukur jumlah maksimum sambungan per detik nu server memcached kami bisa nanganan. Saperti nu diharapkeun, kasus "euweuh kawijakan" jeung "kabijakan biasa" duanana ngahontal wates conntrack leuwih 4,000 sambungan per detik (512k / 120s = 4,369 sambungan / s). Kalayan kawijakan do-not-track, klien kami ngirim 60,000 sambungan per detik tanpa masalah. Kami yakin yén urang tiasa ningkatkeun jumlah ieu ku nambihan langkung seueur klien, tapi urang ngarasa yén nomer ieu parantos cekap pikeun ngagambarkeun titik tina tulisan ieu!
kacindekan
Conntrack mangrupikeun fitur kernel anu penting. Anjeunna ngalaksanakeun tugasna sampurna. Hal ieu sering dianggo ku komponén sistem konci. Sanajan kitu, dina sababaraha skenario husus, kamacetan alatan conntrack outweighs kauntungan normal eta nyadiakeun. Dina skenario ieu, kawijakan jaringan Calico bisa dipaké pikeun selektif nganonaktipkeun pamakéan conntrack bari ngaronjatkeun kaamanan jaringan. Pikeun sakabéh lalulintas séjén, conntrack terus jadi sobat anjeun!
Baca ogé artikel séjén dina blog urang:
sumber: www.habr.com