Ferbining folgjen ("conntrack") is in kearnfunksje fan 'e Linux kernel netwurk stack. It lit de kernel alle logyske netwurkferbiningen of streamen byhâlde en dêrmei alle pakketten identifisearje dy't elke stream útmeitsje, sadat se opfolgjend tegearre kinne wurde ferwurke.
Conntrack is in wichtige kernelfunksje dy't wurdt brûkt yn guon basisgefallen:
- NAT fertrout op ynformaasje fan conntrack, sadat it alle pakketten fan deselde stream gelyk kin behannelje. Bygelyks, as in pod tagong hat ta in Kubernetes-tsjinst, brûkt de kube-proxy load balancer NAT om ferkear nei in spesifike pod binnen it kluster te rjochtsjen. Conntrack registrearret dat foar in opjûne ferbining, alle pakketten nei de IP tsjinst moatte wurde stjoerd nei deselde pod, en dat pakketten werom troch de backend pod moatte wurde NATed werom nei de pod dêr't it fersyk kaam.
- Stateful firewalls lykas Calico fertrouwe op ynformaasje fan connecttrack nei whitelist "antwurd" ferkear. Hjirmei kinne jo in netwurkbelied skriuwe dat seit "tastean myn pod te ferbinen mei elk IP-adres op ôfstân" sûnder in belied te skriuwen om eksplisyt antwurdferkear ta te stean. (Sûnder dit soene jo de folle minder feilige "tastean pakketten ta myn pod fan elke IP"-regel moatte tafoegje.)
Derneist ferbetteret conntrack typysk systeemprestaasjes (troch CPU-konsumpsje en pakketlatinsje te ferminderjen) sûnt allinich it earste pakket yn in stream
moatte gean troch de hiele netwurk stack om te bepalen wat te dwaan mei it. Sjoch it berjocht "" om in foarbyld te sjen fan hoe't dit wurket.
Conntrack hat lykwols syn beheiningen ...
Dus wêr gie it allegear ferkeard?
De conntrack tafel hat in ynstelbere maksimum grutte, en as it wurdt fol, begjinne ferbinings meastal wurde ôfwiisd of falle. D'r is genôch frije romte yn 'e tabel om it ferkear fan' e measte applikaasjes te behanneljen, en dit sil nea in probleem wurde. D'r binne lykwols in pear senario's wêryn jo miskien wolle beskôgje it brûken fan de conntrack-tabel:
- It meast foar de hân lizzende gefal is as jo server in ekstreem grut oantal tagelyk aktive ferbiningen omgiet. Bygelyks, as jo conntrack tabel is konfigurearre foar 128k entries, mar jo hawwe> 128k tagelyk ferbinings, Jo sille grif in probleem!
- In wat minder dúdlik gefal: as jo server in heul grut oantal ferbiningen per sekonde ferwurket. Sels as de ferbiningen koart libje, bliuwe se troch Linux foar in skoft (standert 120s) kontrolearre. As jo bygelyks jo conntrack-tabel is konfigureare foar 128k-yngongen en jo besykje 1100 ferbiningen per sekonde te behanneljen, sille se de grutte fan 'e conntrack-tabel grutter meitsje, sels as de ferbiningen heul koart binne (128k / 120s = 1092 ferbiningen / s).
D'r binne ferskate niche-soarten apps dy't yn dizze kategoryen falle. Derneist, as jo in protte minne akteurs hawwe, kin it foljen fan jo tsjinner's conntrack-tabel mei in protte heal-iepen ferbiningen brûkt wurde as ûnderdiel fan in Denial of Service (DOS) oanfal. Yn beide gefallen kin conntrack in beheinende knelpunt wurde yn jo systeem. Yn guon gefallen kin it oanpassen fan de parameters fan 'e conntrack-tabel genôch wêze om oan jo behoeften te foldwaan - troch de grutte te fergrutsjen of de konntrack-timeouts te ferminderjen (mar as jo it ferkeard dogge, sille jo in soad problemen krije). Foar oare gefallen sil it nedich wêze om conntrack te omgean foar agressyf ferkear.
Echte foarbyld
Litte wy in spesifyk foarbyld jaan: ien grutte SaaS-provider wêrmei wy wurken hie in oantal memcached tsjinners op hosts (net firtuele masines), dy't elk 50K+ koarte termyn ferbiningen per sekonde ferwurke.
Se eksperimintearre mei de konfiguraasje fan 'e ferbining, tanimmende tabelgrutte en ferminderjen fan trackingtiid, mar de konfiguraasje wie ûnbetrouber, it RAM-konsumpsje ferhege gâns, wat in probleem wie (yn' e folchoarder fan GBytes!), En de ferbiningen wiene sa koart dat conntrack net dien. meitsje syn gewoane prestaasjesfoardiel (fermindere konsumpsje CPU of pakketlatinsje).
Se kearden nei Calico as alternatyf. Calico-netwurkbelied lit jo conntrack net brûke foar bepaalde soarten ferkear (mei de doNotTrack-beliedsopsje). Dit joech har it nivo fan prestaasjes dat se nedich wiene, plus it tafoege nivo fan feiligens levere troch Calico.
Hokker lingte sille jo moatte gean om conntrack te omgean?
- Net-track-netwurkbelied moat oer it algemien symmetrysk wêze. Yn it gefal fan 'e SaaS-provider: har applikaasjes rûnen binnen de beskerme sône en dêrom koene se, mei help fan netwurkbelied, ferkear fan oare spesifike applikaasjes whitelistje dy't tagong mochten ta memcached.
- It net-track-belied hâldt gjin rekken mei de rjochting fan de ferbining. Sa, as de memcached tsjinner is hacked, kinne jo teoretysk besykje te ferbinen mei ien fan de memcached kliïnten, sa lang as it brûkt de juste boarne haven. As jo lykwols it netwurkbelied foar jo memcached kliïnten goed definieare hawwe, dan wurde dizze ferbiningspogingen noch altyd ôfwiisd oan 'e kliïntkant.
- It net-track-belied wurdt tapast op elk pakket, yn tsjinstelling ta normale belied, dy't allinich tapast wurde op it earste pakket yn in stream. Dit kin it CPU-konsumpsje per pakket ferheegje, om't it belied foar elk pakket tapast wurde moat. Mar foar koarte-libbene ferbinings, dizze kosten wurdt balansearre troch de reduksje fan boarne konsumpsje foar conntrack ferwurkjen. Bygelyks, yn it gefal fan in SaaS-provider, wie it oantal pakketten foar elke ferbining heul lyts, sadat it ekstra CPU-konsumpsje by it tapassen fan belied op elk pakket rjochtfeardige wie.
Litte wy begjinne te testen
Wy rûnen de test op in inkele pod mei in memcached tsjinner en meardere memcached client pods dy't rinne op ôfstân knopen sadat wy koenen rinne in hiel grut oantal ferbinings per sekonde. De tsjinner mei de memcached tsjinner pod hie 8 kearnen en 512k yngongen yn de conntrack tabel (de standert konfigurearre tabel grutte foar de host).
Wy mjitten de prestaasjes ferskil tusken: gjin netwurk belied; mei reguliere Calico belied; en Calico do-net-track belied.
Foar de earste test sette wy it oantal ferbiningen op 4.000 per sekonde, sadat wy rjochtsje kinne op it ferskil yn CPU-konsumpsje. D'r wiene gjin signifikante ferskillen tusken gjin belied en gewoan belied, mar do-not-track ferhege CPU-konsumpsje mei sawat 20%:
Yn 'e twadde test lansearren wy safolle ferbiningen as ús kliïnten it maksimale oantal ferbiningen per sekonde kinne generearje en mjitten dat ús memcached-tsjinner koe omgean. Lykas ferwachte berikten de gefallen fan "gjin belied" en "gewoane belied" beide de ferbiningslimyt fan mear dan 4,000 ferbiningen per sekonde (512k / 120s = 4,369 ferbiningen / s). Mei in net-track belied stjoerde ús kliïnten 60,000 ferbiningen per sekonde sûnder problemen. Wy binne der wis fan dat wy dit oantal kinne ferheegje troch mear kliïnten ta te foegjen, mar wy fiele dat dizze nûmers al genôch binne om it punt fan dit artikel te yllustrearjen!
konklúzje
Conntrack is in wichtige kernelfunksje. Hy docht syn wurk perfekt. It wurdt faak brûkt troch wichtige systeemkomponinten. Yn guon spesifike senario's is de oerlêst troch conntrack lykwols grutter as de normale foardielen dy't it leveret. Yn dit senario, Calico netwurk belied kin brûkt wurde om selektyf útskeakelje it brûken fan conntrack wylst tanimmende netwurk feiligens. Foar alle oare ferkear bliuwt conntrack jo freon!
Lês ek oare artikels op ús blog:
Boarne: www.habr.com