Het volgen van verbindingen (“conntrack”) is een kernkenmerk van de Linux-kernelnetwerkstack. Het stelt de kernel in staat alle logische netwerkverbindingen of stromen bij te houden en daardoor alle pakketten te identificeren waaruit elke stroom bestaat, zodat ze samen opeenvolgend kunnen worden verwerkt.
Conntrack is een belangrijke kernelfunctie die in enkele basisgevallen wordt gebruikt:
- NAT is afhankelijk van informatie van conntrack, zodat het alle pakketten uit dezelfde stroom gelijk kan behandelen. Wanneer een pod bijvoorbeeld toegang krijgt tot een Kubernetes-service, gebruikt de kube-proxy load balancer NAT om verkeer naar een specifieke pod binnen het cluster te leiden. Conntrack registreert dat voor een bepaalde verbinding alle pakketten naar de IP-service naar dezelfde pod moeten worden verzonden, en dat pakketten die door de backend-pod worden geretourneerd, moeten worden teruggestuurd naar de pod waar het verzoek vandaan kwam.
- Stateful firewalls zoals Calico vertrouwen op informatie van connecttrack om ‘respons’-verkeer op de witte lijst te zetten. Hierdoor kunt u een netwerkbeleid schrijven dat zegt: "Laat mijn pod verbinding maken met een extern IP-adres" zonder dat u een beleid hoeft te schrijven om responsverkeer expliciet toe te staan. (Zonder dit zou u de veel minder veilige regel "pakketten vanaf elk IP-adres naar mijn pod toelaten" moeten toevoegen.)
Bovendien verbetert conntrack doorgaans de systeemprestaties (door het CPU-verbruik en de pakketlatentie te verminderen), aangezien alleen het eerste pakket in een stream
moet de hele netwerkstack doorlopen om te bepalen wat ermee te doen. Zie het bericht"' om een voorbeeld te zien van hoe het werkt.
Conntrack heeft echter zijn beperkingen...
Dus waar ging het allemaal mis?
De conntrack-tabel heeft een configureerbare maximale grootte, en als deze vol raakt, worden verbindingen meestal afgewezen of verbroken. Er is voldoende vrije ruimte in de tabel om het verkeer van de meeste applicaties af te handelen, en dit zal nooit een probleem worden. Er zijn echter een paar scenario's waarin u mogelijk de conntrack-tabel wilt gebruiken:
- Het meest voor de hand liggende geval is als uw server een extreem groot aantal gelijktijdig actieve verbindingen verwerkt. Als uw conntrack-tabel bijvoorbeeld is geconfigureerd voor 128 vermeldingen, maar u >128 gelijktijdige verbindingen heeft, zult u zeker een probleem tegenkomen!
- Een iets minder voor de hand liggend geval: als uw server een zeer groot aantal verbindingen per seconde verwerkt. Zelfs als de verbindingen van korte duur zijn, worden ze nog enige tijd door Linux gemonitord (standaard 120s). Als uw conntrack-tabel bijvoorbeeld is geconfigureerd voor 128k-items en u probeert 1100 verbindingen per seconde te verwerken, zullen deze de grootte van de conntrack-tabel overschrijden, zelfs als de verbindingen van zeer korte duur zijn (128k/120s = 1092 verbindingen/ S).
Er zijn verschillende nichetypen apps die in deze categorieën vallen. Als u bovendien veel slechte actoren heeft, kan het vullen van de conntracktabel van uw server met veel halfopen verbindingen worden gebruikt als onderdeel van een Denial of Service (DOS)-aanval. In beide gevallen kan conntrack een beperkend knelpunt in uw systeem worden. In sommige gevallen kan het aanpassen van de conntrack-tabelparameters voldoende zijn om aan uw behoeften te voldoen - door de grootte te vergroten of de conntrack-time-outs te verkleinen (maar als u het verkeerd doet, zult u veel problemen tegenkomen). In andere gevallen zal het nodig zijn om conntrack voor agressief verkeer te omzeilen.
Echt voorbeeld
Laten we een specifiek voorbeeld geven: een grote SaaS-provider waarmee we samenwerkten, had een aantal memcached-servers op hosts (geen virtuele machines), die elk meer dan 50 kortetermijnverbindingen per seconde verwerkten.
Ze experimenteerden met de conntrack-configuratie, waarbij de tabelgrootte werd vergroot en de trackingtijd werd verkort, maar de configuratie was onbetrouwbaar, het RAM-verbruik nam aanzienlijk toe, wat een probleem was (in de orde van GBytes!), en de verbindingen waren zo kort dat conntrack dat niet deed. het gebruikelijke prestatievoordeel te creëren (verminderd CPU-verbruik of pakketlatentie).
Als alternatief wendden ze zich tot Calico. Met het Calico-netwerkbeleid kunt u conntrack niet gebruiken voor bepaalde soorten verkeer (met behulp van de doNotTrack-beleidsoptie). Dit gaf hen het prestatieniveau dat ze nodig hadden, plus het extra beveiligingsniveau van Calico.
Hoe ver moet je gaan om conntrack te omzeilen?
- Do-not-track-netwerkbeleid moet over het algemeen symmetrisch zijn. In het geval van de SaaS-provider: hun applicaties draaiden binnen de beschermde zone en daarom konden ze, met behulp van netwerkbeleid, verkeer van andere specifieke applicaties die toegang hadden tot memcached op de witte lijst zetten.
- Het do-not-track-beleid houdt geen rekening met de richting van de verbinding. Als de memcache-server dus wordt gehackt, kun je in theorie proberen verbinding te maken met een van de memcache-clients, zolang deze maar de juiste bronpoort gebruikt. Als u echter het netwerkbeleid voor uw clients in de geheugencache correct hebt gedefinieerd, worden deze verbindingspogingen nog steeds afgewezen aan de clientzijde.
- Het do-not-track-beleid wordt op elk pakket toegepast, in tegenstelling tot het normale beleid, dat alleen op het eerste pakket in een stroom wordt toegepast. Dit kan het CPU-verbruik per pakket verhogen, omdat het beleid voor elk pakket moet worden toegepast. Maar voor verbindingen met een korte levensduur worden deze kosten gecompenseerd door de vermindering van het verbruik van hulpbronnen voor conntrack-verwerking. In het geval van een SaaS-provider was het aantal pakketten voor elke verbinding bijvoorbeeld erg klein, dus het extra CPU-verbruik bij het toepassen van beleid op elk pakket was gerechtvaardigd.
Laten we beginnen met testen
We hebben de test uitgevoerd op een enkele pod met een memcached server en meerdere memcached client-pods die op externe knooppunten draaiden, zodat we een zeer groot aantal verbindingen per seconde konden uitvoeren. De server met de memcached serverpod had 8 kernen en 512k vermeldingen in de conntrack-tabel (de standaard geconfigureerde tabelgrootte voor de host).
We hebben het prestatieverschil gemeten tussen: geen netwerkbeleid; met regulier Calico-beleid; en Calico niet-volgbeleid.
Voor de eerste test hebben we het aantal verbindingen ingesteld op 4.000 per seconde, zodat we ons konden concentreren op het verschil in CPU-verbruik. Er waren geen significante verschillen tussen geen beleid en regulier beleid, maar houd het CPU-verbruik met ongeveer 20% niet bij:
In de tweede test lanceerden we zoveel verbindingen als onze klanten konden genereren en maten we het maximale aantal verbindingen per seconde dat onze memcached server aankon. Zoals verwacht bereikten de gevallen van ‘geen beleid’ en ‘regulier beleid’ beide de conntrack-limiet van meer dan 4,000 verbindingen per seconde (512k / 120s = 4,369 verbindingen/s). Met een do-not-track beleid stuurden onze klanten probleemloos 60,000 verbindingen per seconde. We zijn er zeker van dat we dit aantal kunnen vergroten door meer klanten toe te voegen, maar we zijn van mening dat deze cijfers al voldoende zijn om het doel van dit artikel te illustreren!
Conclusie
Conntrack is een belangrijke kernelfunctie. Hij doet zijn werk perfect. Het wordt vaak gebruikt door belangrijke systeemcomponenten. In sommige specifieke scenario's weegt de congestie als gevolg van de verbinding echter zwaarder dan de normale voordelen die deze met zich meebrengt. In dit scenario kan het Calico-netwerkbeleid worden gebruikt om het gebruik van conntrack selectief uit te schakelen en tegelijkertijd de netwerkbeveiliging te vergroten. Voor al het overige verkeer blijft conntrack je vriend!
Lees ook andere artikelen op onze blog:
Bron: www.habr.com