Verbindingsopsporing (“conntrack”) is 'n kernkenmerk van die Linux-kernnetwerkstapel. Dit laat die kern toe om tred te hou met alle logiese netwerkverbindings of -vloeie en sodoende al die pakkies waaruit elke vloei bestaan te identifiseer sodat hulle opeenvolgend saam verwerk kan word.
Conntrack is 'n belangrike kernkenmerk wat in sommige basiese gevalle gebruik word:
- NAT maak staat op inligting van conntrack sodat dit alle pakkies van dieselfde stroom gelyk kan behandel. Byvoorbeeld, wanneer 'n peul toegang tot 'n Kubernetes-diens verkry, gebruik die kube-instaanbediener-ladingbalanseerder NAT om verkeer na 'n spesifieke peul binne die groepering te lei. Conntrack rekords dat vir 'n gegewe verbinding, alle pakkies na die IP-diens na dieselfde pod gestuur moet word, en dat pakkies wat deur die backend-peul teruggestuur word, teruggestuur moet word na die pod waaruit die versoek gekom het.
- Statige firewalls soos Calico maak staat op inligting van connecttrack tot witlys "reaksie" verkeer. Dit laat jou toe om 'n netwerkbeleid te skryf wat sê "laat my pod toe om aan enige afgeleë IP-adres te koppel" sonder om 'n beleid te skryf om eksplisiet reaksieverkeer toe te laat. (Sonder dit sal jy die veel minder veilige "laat pakkies toe by my pod vanaf enige IP"-reël moet byvoeg.)
Boonop verbeter conntrack gewoonlik stelselwerkverrigting (deur die vermindering van SVE-verbruik en pakkie latency) aangesien slegs die eerste pakkie in 'n stroom
moet deur die hele netwerkstapel gaan om te bepaal wat om daarmee te doen. Sien die pos "" om 'n voorbeeld te sien van hoe dit werk.
Conntrack het egter sy beperkings ...
So waar het dit alles verkeerd geloop?
Die conntrack-tabel het 'n konfigureerbare maksimum grootte, en as dit vol raak, begin verbindings gewoonlik verwerp of laat val word. Daar is genoeg vrye spasie in die tabel om die verkeer van die meeste toepassings te hanteer, en dit sal nooit 'n probleem word nie. Daar is egter 'n paar scenario's waarin jy dalk wil oorweeg om die verbindingstabel te gebruik:
- Die mees voor die hand liggende geval is as jou bediener 'n uiters groot aantal gelyktydig aktiewe verbindings hanteer. Byvoorbeeld, as jou verbindingstabel opgestel is vir 128k inskrywings, maar jy het >128k gelyktydige verbindings, sal jy sekerlik 'n probleem ondervind!
- 'N Effens minder ooglopende geval: as jou bediener 'n baie groot aantal verbindings per sekonde verwerk. Selfs al is die verbindings van korte duur, word hulle vir 'n geruime tyd deur Linux gemonitor (120s by verstek). Byvoorbeeld, as jou verbindingstabel opgestel is vir 128k-inskrywings en jy probeer om 1100 verbindings per sekonde te hanteer, sal hulle die grootte van die verbindingstabel oorskry, selfs al is die verbindings baie kortstondig (128k/120s = 1092 verbindings/ s).
Daar is verskeie nistipes toepassings wat in hierdie kategorieë val. Daarbenewens, as jy baie slegte akteurs het, kan die vul van jou bediener se verbindingstabel met baie half-oop verbindings gebruik word as deel van 'n ontkenning van diens (DOS) aanval. In beide gevalle kan conntrack 'n beperkende bottelnek in u stelsel word. In sommige gevalle kan die aanpassing van die verbindingstabel-parameters genoeg wees om aan jou behoeftes te voldoen - deur die grootte te vergroot of die verbindings-time-outs te verminder (maar as jy dit verkeerd doen, sal jy baie probleme ondervind). In ander gevalle sal dit nodig wees om die verbindingsspoor vir aggressiewe verkeer te omseil.
Werklike voorbeeld
Kom ons gee 'n spesifieke voorbeeld: een groot SaaS-verskaffer waarmee ons gewerk het, het 'n aantal memcached-bedieners op gashere gehad (nie virtuele masjiene nie), wat elkeen 50K+ korttermynverbindings per sekonde verwerk het.
Hulle het geëksperimenteer met die conntrack-konfigurasie, die verhoging van tabelgroottes en die vermindering van opsporingstyd, maar die konfigurasie was onbetroubaar, die RAM-verbruik het aansienlik toegeneem, wat 'n probleem was (op die orde van GBytes!), en die verbindings was so kort dat conntrack nie skep sy gewone werkverrigtingvoordeel (verminderde verbruik SVE of pakkie latency).
Hulle het na Calico as 'n alternatief gewend. Calico-netwerkbeleide laat jou toe om nie conntrack vir sekere soorte verkeer te gebruik nie (met die doNotTrack-beleidsopsie). Dit het hulle die vlak van prestasie gegee wat hulle nodig gehad het, plus die bykomende vlak van sekuriteit wat deur Calico verskaf word.
Tot watter lengtes sal jy moet gaan om die verbinding te omseil?
- Moenie-navolg-netwerkbeleide moet oor die algemeen simmetries wees. In die geval van die SaaS-verskaffer: hul toepassings het binne die beskermde sone gehardloop en daarom kon hulle, met behulp van netwerkbeleid, verkeer van ander spesifieke toepassings wat toegang tot memcached toegelaat het, witlys.
- Die moenie-volg-beleid neem nie die rigting van die verbinding in ag nie. Dus, as die memcached-bediener gehack word, kan u teoreties probeer om aan enige van die memcached-kliënte te koppel, solank dit die korrekte bronpoort gebruik. As jy egter die netwerkbeleid vir jou memcached-kliënte korrek gedefinieer het, sal hierdie verbindingspogings steeds aan die kliëntkant verwerp word.
- Die moenie-volg-beleid word op elke pakkie toegepas, in teenstelling met normale beleide, wat slegs op die eerste pakkie in 'n vloei toegepas word. Dit kan die SVE-verbruik per pakkie verhoog omdat die beleid vir elke pakkie toegepas moet word. Maar vir kortstondige verbindings word hierdie uitgawe gebalanseer deur die vermindering in hulpbronverbruik vir verbindingsverwerking. Byvoorbeeld, in die geval van 'n SaaS-verskaffer, was die aantal pakkies vir elke verbinding baie klein, sodat die bykomende SVE-verbruik by die toepassing van beleide op elke pakkie geregverdig was.
Kom ons begin toets
Ons het die toets op 'n enkele pod uitgevoer met 'n memcached-bediener en verskeie memcached-kliëntpeule wat op afgeleë nodusse loop sodat ons 'n baie groot aantal verbindings per sekonde kon laat loop. Die bediener met die memcached bediener pod het 8 kerns en 512k inskrywings in die conntrack tabel (die standaard gekonfigureerde tabel grootte vir die gasheer).
Ons het die prestasieverskil gemeet tussen: geen netwerkbeleid nie; met gereelde Calico-polis; en Calico-nie-volg-beleid.
Vir die eerste toets het ons die aantal verbindings op 4.000 20 per sekonde gestel, sodat ons kon fokus op die verskil in SVE-verbruik. Daar was geen beduidende verskille tussen geen beleid en gereelde beleid nie, maar moenie-volg nie, het SVE-verbruik met ongeveer XNUMX% verhoog:
In die tweede toets het ons soveel verbindings geloods as wat ons kliënte kon genereer en die maksimum aantal verbindings per sekonde gemeet wat ons memcached-bediener kan hanteer. Soos verwag, het die gevalle van "geen beleid" en "gewone beleid" albei die verbindingslimiet van meer as 4,000 512 verbindings per sekonde bereik (120k / 4,369s = 60,000 verbindings/s). Met 'n moenie-volg-beleid het ons kliënte sonder enige probleme XNUMX XNUMX verbindings per sekonde gestuur. Ons is seker ons kan hierdie getal verhoog deur meer kliënte by te voeg, maar ons voel hierdie getalle is reeds genoeg om die punt van hierdie artikel te illustreer!
Gevolgtrekking
Conntrack is 'n belangrike kernkenmerk. Hy doen sy werk perfek. Dit word dikwels deur sleutelstelselkomponente gebruik. In sommige spesifieke scenario's weeg die opeenhoping as gevolg van verbinding egter swaarder as die normale voordele wat dit bied. In hierdie scenario kan Calico-netwerkbeleide gebruik word om die gebruik van verbinding selektief te deaktiveer terwyl netwerksekuriteit verhoog word. Vir alle ander verkeer bly conntrack jou vriend!
Lees ook ander artikels op ons blog:
Bron: will.com