Ang pagsubaybay sa koneksyon ("conntrack") ay isang pangunahing tampok ng Linux kernel networking stack. Pinapayagan nito ang kernel na subaybayan ang lahat ng lohikal na koneksyon o daloy ng network at sa gayon ay matukoy ang lahat ng packet na bumubuo sa bawat daloy upang maproseso ang mga ito nang magkakasunod.
Ang Conntrack ay isang mahalagang tampok na kernel na ginagamit sa ilang mga pangunahing kaso:
- Ang NAT ay umaasa sa impormasyon mula sa conntrack upang matrato nito ang lahat ng mga packet mula sa parehong stream nang pantay. Halimbawa, kapag nag-access ang isang pod sa isang serbisyo ng Kubernetes, ginagamit ng kube-proxy load balancer ang NAT para idirekta ang trapiko sa isang partikular na pod sa loob ng cluster. Itinatala ng Conntrack na para sa isang naibigay na koneksyon, ang lahat ng mga packet sa serbisyo ng IP ay dapat ipadala sa parehong pod, at ang mga packet na ibinalik ng backend pod ay dapat na NATed pabalik sa pod kung saan nagmula ang kahilingan.
- Ang mga stateful na firewall gaya ng Calico ay umaasa sa impormasyon mula sa connecttrack hanggang sa whitelist na "tugon" na trapiko. Nagbibigay-daan ito sa iyong magsulat ng patakaran sa network na nagsasabing "payagan ang aking pod na kumonekta sa anumang malayong IP address" nang hindi kinakailangang sumulat ng patakaran upang tahasang payagan ang trapiko ng pagtugon. (Kung wala ito, kailangan mong idagdag ang hindi gaanong secure na "payagan ang mga packet sa aking pod mula sa anumang IP" na panuntunan.)
Bukod pa rito, karaniwang pinapabuti ng conntrack ang performance ng system (sa pamamagitan ng pagbabawas ng pagkonsumo ng CPU at packet latency) dahil ang unang packet lang sa isang stream
dapat dumaan sa buong stack ng network upang matukoy kung ano ang gagawin dito. Tingnan ang post""upang makita ang isang halimbawa kung paano ito gumagana.
Gayunpaman, ang conntrack ay may mga limitasyon...
Kaya saan nagkamali ang lahat?
Ang talahanayan ng conntrack ay may maaaring i-configure na maximum na laki, at kung ito ay mapuno, ang mga koneksyon ay karaniwang nagsisimulang tanggihan o i-drop. Mayroong sapat na libreng espasyo sa talahanayan upang mahawakan ang trapiko ng karamihan sa mga application, at hinding-hindi ito magiging problema. Gayunpaman, may ilang mga sitwasyon kung saan maaari mong isaalang-alang ang paggamit ng conntrack table:
- Ang pinaka-halatang kaso ay kung pinangangasiwaan ng iyong server ang napakaraming bilang ng magkakasabay na aktibong koneksyon. Halimbawa, kung ang iyong conntrack table ay na-configure para sa 128k entries, ngunit mayroon kang >128k concurrent connections, tiyak na magkakaroon ka ng problema!
- Isang medyo hindi gaanong halatang kaso: kung ang iyong server ay nagpoproseso ng napakalaking bilang ng mga koneksyon sa bawat segundo. Kahit na ang mga koneksyon ay panandalian, patuloy silang sinusubaybayan ng Linux sa loob ng ilang panahon (120s bilang default). Halimbawa, kung ang iyong conntrack table ay na-configure para sa 128k na mga entry at sinusubukan mong humawak ng 1100 na koneksyon sa bawat segundo, lalampas sila sa laki ng conntrack table, kahit na ang mga koneksyon ay masyadong maikli ang buhay (128k/120s = 1092 na koneksyon/ s).
Mayroong ilang mga angkop na uri ng mga app na nabibilang sa mga kategoryang ito. Bukod pa rito, kung marami kang masamang aktor, ang pagpuno sa conntrack table ng iyong server ng maraming kalahating bukas na koneksyon ay maaaring gamitin bilang bahagi ng pag-atake ng denial of service (DOS). Sa parehong mga kaso, ang conntrack ay maaaring maging isang limitadong bottleneck sa iyong system. Sa ilang mga kaso, maaaring sapat na ang pagsasaayos sa mga parameter ng conntrack table upang matugunan ang iyong mga pangangailangan - sa pamamagitan ng pagpapalaki ng laki o pagbabawas ng mga conntrack timeout (ngunit kung mali ang gagawin mo, magkakaroon ka ng maraming problema). Para sa ibang mga kaso, kakailanganing i-bypass ang conntrack para sa agresibong trapiko.
Tunay na halimbawa
Magbigay tayo ng partikular na halimbawa: isang malaking provider ng SaaS na nakatrabaho namin ay may ilang memcached server sa mga host (hindi virtual machine), na ang bawat isa ay nagpoproseso ng 50K+ panandaliang koneksyon sa bawat segundo.
Nag-eksperimento sila sa pagsasaayos ng conntrack, pagtaas ng mga sukat ng talahanayan at pagbabawas ng oras ng pagsubaybay, ngunit ang pagsasaayos ay hindi maaasahan, ang pagkonsumo ng RAM ay tumaas nang malaki, na isang problema (sa pagkakasunud-sunod ng GBytes!), At ang mga koneksyon ay napakaikli na ang conntrack ay hindi. lumikha ng karaniwan nitong benepisyo sa pagganap (pinababang pagkonsumo ng CPU o packet latency).
Bumaling sila sa Calico bilang alternatibo. Binibigyang-daan ka ng mga patakaran ng network ng Calico na huwag gumamit ng conntrack para sa ilang partikular na uri ng trapiko (gamit ang opsyon sa patakarang doNotTrack). Nagbigay ito sa kanila ng antas ng pagganap na kailangan nila, kasama ang karagdagang antas ng seguridad na ibinigay ng Calico.
Anong mga haba ang kailangan mong puntahan para ma-bypass ang conntrack?
- Ang mga patakaran sa network na huwag subaybayan ay dapat na simetriko sa pangkalahatan. Sa kaso ng provider ng SaaS: tumakbo ang kanilang mga application sa loob ng protektadong zone at samakatuwid, gamit ang patakaran sa network, maaari nilang i-whitelist ang trapiko mula sa iba pang mga partikular na application na pinahintulutan ang pag-access sa memcached.
- Hindi isinasaalang-alang ng patakarang do-not-track ang direksyon ng koneksyon. Kaya, kung ang memcached server ay na-hack, maaari mong teoretikal na subukang kumonekta sa alinman sa mga memcached na kliyente, hangga't ginagamit nito ang tamang source port. Gayunpaman, kung natukoy mo nang tama ang patakaran sa network para sa iyong mga memcached na kliyente, tatanggihan pa rin ang mga pagtatangka sa koneksyon na ito sa panig ng kliyente.
- Ang patakarang do-not-track ay inilalapat sa bawat packet, kumpara sa mga normal na patakaran, na inilalapat lamang sa unang packet sa isang daloy. Maaari nitong mapataas ang pagkonsumo ng CPU bawat packet dahil dapat ilapat ang patakaran para sa bawat packet. Ngunit para sa mga panandaliang koneksyon, ang gastos na ito ay balanse ng pagbawas sa pagkonsumo ng mapagkukunan para sa pagproseso ng conntrack. Halimbawa, sa kaso ng isang provider ng SaaS, napakaliit ng bilang ng mga packet para sa bawat koneksyon, kaya nabigyang-katwiran ang karagdagang pagkonsumo ng CPU kapag nag-aaplay ng mga patakaran sa bawat packet.
Simulan natin ang pagsubok
Pinatakbo namin ang pagsubok sa iisang pod na may memcached server at maramihang memcached client pod na tumatakbo sa malalayong node para makapagpatakbo kami ng napakalaking bilang ng mga koneksyon sa bawat segundo. Ang server na may memcached server pod ay may 8 core at 512k na entry sa conntrack table (ang karaniwang laki ng naka-configure na talahanayan para sa host).
Sinukat namin ang pagkakaiba sa pagganap sa pagitan ng: walang patakaran sa network; na may regular na patakaran ng Calico; at patakarang do-not-track ng Calico.
Para sa unang pagsubok, itinakda namin ang bilang ng mga koneksyon sa 4.000 bawat segundo, para makapag-focus kami sa pagkakaiba sa pagkonsumo ng CPU. Walang makabuluhang pagkakaiba sa pagitan ng walang patakaran at regular na patakaran, ngunit ang do-not-track ay tumaas nang humigit-kumulang 20% ββsa pagkonsumo ng CPU:
Sa pangalawang pagsubok, naglunsad kami ng pinakamaraming koneksyon na maaaring makabuo at masusukat ng aming mga kliyente ang maximum na bilang ng mga koneksyon sa bawat segundo na kayang hawakan ng aming memcached server. Gaya ng inaasahan, ang mga kaso ng "walang patakaran" at "regular na patakaran" ay parehong umabot sa conntrack na limitasyon na mahigit 4,000 na koneksyon sa bawat segundo (512k / 120s = 4,369 na koneksyon/s). Sa pamamagitan ng patakarang huwag subaybayan, nagpadala ang aming mga kliyente ng 60,000 koneksyon kada segundo nang walang anumang problema. Sigurado kami na maaari naming dagdagan ang bilang na ito sa pamamagitan ng pagdaragdag ng higit pang mga kliyente, ngunit sa palagay namin ay sapat na ang mga numerong ito upang ilarawan ang punto ng artikulong ito!
Konklusyon
Ang Conntrack ay isang mahalagang tampok na kernel. Ginagawa niya ang kanyang trabaho nang perpekto. Madalas itong ginagamit ng mga pangunahing bahagi ng system. Gayunpaman, sa ilang partikular na sitwasyon, ang kasikipan dahil sa conntrack ay mas malaki kaysa sa mga normal na benepisyong ibinibigay nito. Sa sitwasyong ito, maaaring gamitin ang mga patakaran ng network ng Calico upang piliing huwag paganahin ang paggamit ng conntrack habang pinapataas ang seguridad ng network. Para sa lahat ng iba pang trapiko, patuloy na magiging kaibigan mo ang conntrack!
Basahin din ang iba pang mga artikulo sa aming blog:
Pinagmulan: www.habr.com