Moien alleguer! Mäin Numm ass Dmitry Samsonov, ech schaffen als féierende Systemadministrator bei Odnoklassniki. Mir hu méi wéi 7 Tausend kierperlech Serveren, 11 Tausend Container an eiser Wollek an 200 Uwendungen, déi a verschiddene Konfiguratiounen 700 verschidde Cluster bilden. Déi grouss Majoritéit vun de Servere lafen CentOS 7.
De 14. August 2018 gouf Informatioun iwwer d'FragmentSmack Schwachstelle publizéiert
() und SegmentSmack (). Dëst sinn Schwachstelle mat engem Netzwierkattackvektor an engem zimlech héije Score (7.5), wat denial of Service (DoS) bedroht wéinst Ressourceausschöpfung (CPU). E Kernel Fix fir FragmentSmack gouf zu där Zäit net proposéiert; Ausserdeem ass et vill méi spéit erauskomm wéi d'Publikatioun vun Informatioun iwwer d'Schwachheet. Fir SegmentSmack ze eliminéieren, gouf proposéiert de Kernel ze aktualiséieren. Den Update Package selwer gouf de selwechten Dag verëffentlecht, alles wat blouf war et z'installéieren.
Nee, mir si guer net géint d'Aktualiséierung vum Kernel! Wéi och ëmmer, et ginn Nuancen ...
Wéi mir de Kernel bei der Produktioun aktualiséieren
Am Allgemengen, näischt komplizéiert:
- Download Packagen;
- Installéiert se op enger Rei vu Serveren (inklusiv Serveren déi eis Cloud hosten);
- Vergewëssert Iech datt näischt gebrach ass;
- Vergewëssert Iech datt all Standard Kernel Astellunge ouni Feeler applizéiert ginn;
- Waart e puer Deeg;
- Check Server Leeschtung;
- Wiesselt Deployment vun neie Serveren op den neie Kernel;
- Update all Server duerch Datenzenter (een Datenzenter gläichzäiteg fir den Effekt op d'Benotzer am Fall vu Probleemer ze minimiséieren);
- Restart all Server.
Widderhuelen fir all Branchen vun de Kären déi mir hunn. Am Moment ass et:
- Stock CentOS 7 3.10 - fir déi meescht regelméisseg Serveren;
- Vanill 4.19 - fir eis , well mir brauchen BFQ, BBR, etc.;
- Elrepo kernel-ml 5.2 - fir , well 4.19 benotzt sech onbestänneg ze behuelen, awer déiselwecht Funktiounen sinn néideg.
Wéi Dir vläicht scho virgestallt hutt, dausende vu Serveren nei starten dauert déi längst Zäit. Well net all Schwachstelle fir all Server kritesch sinn, restarte mir nëmmen déi, déi direkt vum Internet zougänglech sinn. An der Wollek, fir d'Flexibilitéit net ze limitéieren, verbannen mir net extern zougänglech Container op eenzel Server mat engem neie Kernel, mee restart all Hosten ouni Ausnam. Glécklecherweis ass d'Prozedur do méi einfach wéi mat normale Serveren. Zum Beispill, stateless Container kënnen einfach op en anere Server réckelen wärend engem Neistart.
Allerdéngs ass et nach vill Aarbecht, an et kann e puer Wochen huelen, a wann et Problemer mat der neier Versioun, bis zu e puer Méint. Ugräifer verstinn dat ganz gutt, also brauche se e Plang B.
FragmentSmack/SegmentSmack. Ëmgéigend
Glécklecherweis, fir e puer Schwachstelle existéiert esou e Plang B, an et gëtt Workaround genannt. Meeschtens ass dëst eng Ännerung vun de Kernel / Applikatioun Astellungen, déi de méiglechen Effekt minimiséieren oder d'Ausbeutung vu Schwachstelle komplett eliminéieren.
Am Fall vu FragmentSmack/SegmentSmack dës Léisung:
«Dir kënnt d'Standardwäerter vun 4MB an 3MB an net.ipv4.ipfrag_high_thresh an net.ipv4.ipfrag_low_thresh änneren (an hir Géigeparteien fir ipv6 net.ipv6.ipfrag_high_thresh an net.ipv6.ipfrag_low_thresh) op respektiv 256 kB oder 192 kB respektiv ënneschten. Tester weisen kleng bis bedeitend Drëpsen an der CPU Benotzung während engem Attack ofhängeg vun Hardware, Astellungen a Konditiounen. Wéi och ëmmer, et kann e puer Performance Impakt ginn wéinst ipfrag_high_thresh = 262144 Bytes, well nëmmen zwee 64K Fragmenter kënnen an d'Reassembly Queue passen. Zum Beispill gëtt et e Risiko datt Applikatiounen, déi mat grousse UDP-Päckchen funktionnéieren, briechen".
D'Parameteren selwer beschriwwen wéi follegt:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Mir hu keng grouss UDPs op Produktiounsservicer. Et gëtt kee fragmentéierte Verkéier um LAN; et gëtt fragmentéiert Traffic um WAN, awer net bedeitend. Et gi keng Schëlder - Dir kënnt Workaround ausrollen!
FragmentSmack/SegmentSmack. Éischt Blutt
Den éischte Problem, dee mir begéint hunn, war datt d'Cloudbehälter heiansdo déi nei Astellungen nëmmen deelweis applizéiert hunn (nëmmen ipfrag_low_thresh), an heiansdo guer net applizéiert hunn - si sinn einfach am Ufank erofgefall. Et war net méiglech de Problem stabil ze reproduzéieren (all Astellunge goufen manuell ouni Schwieregkeeten applizéiert). Verstoen firwat de Container um Start klappt ass och net sou einfach: keng Feeler goufen fonnt. Eng Saach war sécher: d'Astellunge zréckrollen léist de Problem mat Container ofbriechen.
Firwat ass et net genuch fir Sysctl op den Host z'applizéieren? De Container lieft a sengem eegenen dedizéierten Netzwierk Namespace, also op d'mannst am Container ka vum Host ënnerscheeden.
Wéi genau ginn Sysctl Astellungen am Container applizéiert? Well eis Container onprivilegéiert sinn, kënnt Dir keng Sysctl-Astellung änneren andeems Dir an de Container selwer gitt - Dir hutt einfach net genuch Rechter. Fir Container ze lafen, huet eis Cloud zu där Zäit Docker benotzt (elo ). D'Parameteren vum neie Container goufen op Docker iwwer d'API iwwerginn, dorënner déi néideg Sysctl Astellungen.
Wärend d'Versioune gesicht hunn, huet et erausgestallt datt d'Docker API net all Feeler zréckginn (op d'mannst an der Versioun 1.10). Wéi mir probéiert hunn de Container iwwer "Docker Run" ze starten, hu mir endlech op d'mannst eppes gesinn:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
De Parameterwäert ass net valabel. Mee firwat? A firwat gëlt et net nëmmen heiansdo? Et huet sech erausgestallt datt Docker d'Uerdnung net garantéiert an där Sysctl Parameteren applizéiert ginn (déi lescht getest Versioun ass 1.13.1), also heiansdo probéiert ipfrag_high_thresh op 256K gesat ze ginn wann ipfrag_low_thresh nach ëmmer 3M war, dat heescht, déi iewescht Limit war méi niddereg wéi déi ënnescht Grenz, déi zu de Feeler gefouert.
Zu där Zäit hu mir schonn eisen eegene Mechanismus benotzt fir de Container nom Start nei ze konfiguréieren (de Container no der afréieren an ausféieren Kommandoen am Nummraum vum Container via ), a mir hunn och Schreiwen Sysctl Parameteren zu dësem Deel bäigefüügt. De Problem gouf geléist.
FragmentSmack/SegmentSmack. Éischt Blutt 2
Ier mer Zäit haten fir d'Benotzung vu Workaround an der Wollek ze verstoen, hunn déi éischt selten Reklamatioune vu Benotzer ugefaang ze kommen. Zu där Zäit sinn e puer Woche vergaangen zënter dem Ufank vum Workaround op den éischte Serveren ze benotzen. Déi éischt Enquête huet gewisen datt Reklamatioune géint eenzel Servicer kritt goufen, an net all Server vun dëse Servicer. De Problem ass nees extrem onsécher ginn.
Als éischt hu mir natierlech probéiert d'Sysctl-Astellungen zréckzerollen, awer dëst huet keen Effekt. Verschidde Manipulatioune mam Server an Applikatiounsastellungen hunn och net gehollef. Restart gehollef. Linux nei starten ass sou onnatierlech wéi et normal war fir Windows an den alen Deeg. Wéi och ëmmer, et huet gehollef, a mir hunn et op e "Kernel Glitch" gekräizegt wann Dir déi nei Astellungen am Sysctl applizéiert. Wéi frivol et war ...
Dräi Woche méi spéit huet de Problem erëmfonnt. D'Konfiguratioun vun dëse Serveren war ganz einfach: Nginx am Proxy / Balancer Modus. Net vill Verkéier. Nei Aféierungsnotiz: d'Zuel vun de 504 Feeler op Clienten gëtt all Dag erop (). D'Grafik weist d'Zuel vu 504 Feeler pro Dag fir dëse Service:
All d'Feeler sinn ongeféier deeselwechte Backend - iwwer deen deen an der Wollek ass. D'Erënnerungsverbrauchsgrafik fir Packagefragmenter op dësem Backend huet esou ausgesinn:
Dëst ass eng vun den offensichtlechste Manifestatiounen vum Problem an de Grafike vum Betribssystem. An der Wollek, just zur selwechter Zäit, gouf en anere Netzwierkprobleem mat QoS (Traffic Control) Astellunge fixéiert. Op der Grafik vum Erënnerungsverbrauch fir Paketfragmenter huet et genau d'selwecht ausgesinn:
D'Annahme war einfach: wa se d'selwecht op de Grafike kucken, dann hunn se dee selwechte Grond. Ausserdeem sinn all Probleemer mat dëser Zort Erënnerung extrem seelen.
D'Essenz vum fixen Problem war datt mir de fq Packet Scheduler mat Standardastellungen am QoS benotzt hunn. Par défaut, fir eng Verbindung, erlaabt et Iech 100 Päck an d'Schlaang ze addéieren, an e puer Verbindungen, a Situatioune vu Kanalmangel, hunn ugefaang d'Schlaang op d'Kapazitéit ze verstoppen. An dësem Fall gi Pakete gefall. An tc Statistiken (tc -s qdisc) kann et esou gesi ginn:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
"464545 flows_plimit" sinn d'Päckchen, déi erofgefall sinn wéinst der Iwwerschreiden vun der Schlaanglimit vun enger Verbindung, an "gefall 464545" ass d'Zomm vun all erofgeluede Pakete vun dësem Scheduler. Nodeems d'Schlaanglängt op 1 Tausend erhéicht gouf an d'Container nei gestart gouf, huet de Problem opgehalen. Dir kënnt zréck sëtzen an e Smoothie drénken.
FragmentSmack/SegmentSmack. Last Blutt
Als éischt, e puer Méint no der Ukënnegung vu Schwachstelle am Kernel, ass endlech e Fix fir FragmentSmack opgetaucht (loosst mech drun erënneren datt zesumme mat der Ukënnegung am August e Fix nëmme fir SegmentSmack verëffentlecht gouf), wat eis eng Chance huet Workaround opzeginn, wat eis zimlech vill Ierger gesuergt huet. Wärend dëser Zäit hu mir et scho fäerdeg bruecht e puer vun de Serveren op den neie Kernel ze transferéieren, an elo hu mir vun Ufank un ugefaang. Firwat hu mir de Kernel aktualiséiert ouni op de FragmentSmack Fix ze waarden? D'Tatsaach ass datt de Prozess vum Schutz géint dës Schwächen zesummegefall (a fusionéiert) mam Prozess vun der Aktualiséierung vum CentOS selwer (wat nach méi Zäit brauch wéi d'Aktualiséierung vun nëmmen de Kernel). Zousätzlech ass SegmentSmack eng méi geféierlech Schwachstelle, an eng Fix fir et ass direkt erschéngt, sou datt et iwwerhaapt Sënn gemaach huet. Mir konnten awer net einfach den Kernel op CentOS aktualiséieren, well d'FragmentSmack Schwachstelle, déi während CentOS 7.5 erschéngt, nëmmen an der Versioun 7.6 fixéiert gouf, also hu mir den Update op 7.5 misse stoppen an erëm mat der Update op 7.6 ufänken. An dat geschitt och.
Zweetens, selten Benotzer Reklamatiounen iwwer Problemer hunn eis zréck. Elo wësse mer scho sécher datt se all mat der Eroplueden vu Dateie vu Clienten op e puer vun eise Server verbonne sinn. Ausserdeem ass eng ganz kleng Zuel vun Eropluede vun der Gesamtmass duerch dës Server gaang.
Wéi mir eis aus der Geschicht hei uewen erënneren, huet d'Sysctl zréckrollen net gehollef. Restart gehollef, awer temporär.
Verdacht iwwer Sysctl goufen net ewechgeholl, awer dës Kéier war et néideg sou vill wéi méiglech Informatiounen ze sammelen. Et war och e grousse Mangel u Fäegkeet fir den Uploadproblem um Client ze reproduzéieren fir méi präzis ze studéieren wat geschitt ass.
Analyse vun all verfügbare Statistiken a Logbicher huet eis net méi no bruecht fir ze verstoen wat geschitt ass. Et war en akuten Mangel u Fäegkeet fir de Problem ze reproduzéieren fir eng spezifesch Verbindung ze "fillen". Schlussendlech hunn d'Entwéckler, mat enger spezieller Versioun vun der Applikatioun, et fäerdeg bruecht eng stabil Reproduktioun vu Probleemer op engem Testapparat ze erreechen wann se iwwer Wi-Fi verbonne sinn. Dëst war en Duerchbroch an der Enquête. De Client verbonne mat Nginx, deen op de Backend geproxyd huet, wat eis Java Applikatioun war.
Den Dialog fir Probleemer war sou (op der Nginx Proxy Säit fixéiert):
- Client: Ufro fir Informatiounen iwwer d'Download vun enger Datei ze kréien.
- Java Server: Äntwert.
- Client: POST mat Datei.
- Java Server: Feeler.
Zur selwechter Zäit schreift de Java-Server op de Logbuch datt 0 Bytes vun Daten vum Client kritt goufen, an den Nginx Proxy schreift datt d'Ufro méi wéi 30 Sekonnen gedauert huet (30 Sekonnen ass den Timeout vun der Clientapplikatioun). Firwat den Timeout a firwat 0 Bytes? Aus enger HTTP Perspektiv funktionnéiert alles wéi et soll, awer de POST mat der Datei schéngt aus dem Netz ze verschwannen. Ausserdeem verschwënnt et tëscht dem Client an Nginx. Et ass Zäit Iech mat Tcpdump ze bewaffnen! Awer als éischt musst Dir d'Netzkonfiguratioun verstoen. Nginx Proxy ass hannert dem L3 Balancer . Tunneling gëtt benotzt fir Pakete vum L3 Balancer op de Server ze liwweren, wat seng Header op d'Päck bäidréit:
An dësem Fall kënnt d'Netz op dëse Server a Form vu Vlan-tagged Traffic, deen och seng eege Felder un d'Päck bäidréit:
An dëse Traffic kann och fragmentéiert ginn (dee selwechte klenge Prozentsaz vum erakommen fragmentéierte Verkéier iwwer dee mir geschwat hunn wann Dir d'Risiken aus Workaround bewäerten), wat och den Inhalt vun den Header ännert:
Nach eng Kéier: Pakete gi mat engem Vlan-Tag verschlësselt, mat engem Tunnel verschlësselt, fragmentéiert. Fir besser ze verstoen wéi dëst geschitt, loosst eis de Paketroute vum Client op den Nginx Proxy verfollegen.
- De Paket erreecht de L3 Balancer. Fir korrekt Routing am Rechenzentrum gëtt de Paket an engem Tunnel verschlësselt an op d'Netzwierkskaart geschéckt.
- Well de Paket + Tunnel Header net an d'MTU passen, gëtt de Paket a Fragmenter geschnidden an an d'Netz geschéckt.
- De Schalter nom L3 Balancer, wann Dir e Paket kritt, füügt e Vlan-Tag derbäi a schéckt se weider.
- De Schalter virum Nginx Proxy gesäit (baséiert op den Port-Astellungen) datt de Server e Vlan-encapsuléierte Paket erwaart, sou datt et se schéckt wéi ass, ouni de Vlan-Tag ze läschen.
- Linux hëlt Fragmenter vun eenzelne Packagen a fusionéiert se an ee grousse Package.
- Als nächst kënnt de Paket op d'Vlan-Interface, wou déi éischt Schicht dovunner ofgeschaaft gëtt - Vlan-Encapsulation.
- Linux schéckt et dann an d'Tunnel-Interface, wou eng aner Schicht dovunner ofgeschaaft gëtt - Tunnel Encapsulation.
D'Schwieregkeet ass dëst alles als Parameteren op tcpdump ze passéieren.
Loosst eis vum Enn ufänken: Ginn et propper (ouni onnéideg Header) IP-Pakete vu Clienten, mat vlan an Tunnelverschlësselung ewechgeholl?
tcpdump host <ip клиента>
Nee, et waren keng sou Packagen um Server. Also de Problem muss méi fréi do sinn. Ginn et Pakete mat nëmmen Vlan Encapsulation ewechgeholl?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx ass d'IP Adress vum Client am Hexformat.
32: 4 - Adress an Längt vum Feld an deem d'SCR IP am Tunnelpaket geschriwwe gëtt.
D'Feldadress huet misse mat brute Kraaft ausgewielt ginn, well se um Internet schreiwen iwwer 40, 44, 50, 54, awer et war keng IP Adress do. Dir kënnt och ee vun de Paketen an Hex kucken (den -xx oder -XX Parameter am tcpdump) an d'IP Adress berechnen déi Dir wësst.
Ginn et Pak Fragmenter ouni Vlan an Tunnel encapsulation geläscht?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Dës Magie wäert eis all d'Fragmenter weisen, och déi lescht. Wahrscheinlech kann déiselwecht Saach duerch IP gefiltert ginn, awer ech hunn net probéiert, well et net ganz vill sou Päckchen sinn, an déi, déi ech gebraucht hunn, waren einfach am allgemenge Floss fonnt. Hei sinn se:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Dëst sinn zwee Fragmenter vun engem Package (selwescht ID 53652) mat enger Foto (d'Wuert Exif ass am éischte Package sichtbar). Wéinst der Tatsaach, datt et Packagen op dësem Niveau sinn, awer net an der fusionéierter Form an den Dumpen, ass de Problem kloer mat der Assemblée. Endlech gëtt et dokumentaresch Beweiser dofir!
De Paketdecoder huet keng Probleemer opgedeckt déi de Bau verhënneren. Probéiert et hei: . Am Ufank, wann Dir probéiert eppes do ze stuffen, huet den Decoder de Paketformat net gär. Et huet sech erausgestallt datt et e puer extra zwee Oktetten tëscht Srcmac an Ethertype waren (net mat Fragmentinformatioun verbonnen). Nodeems se ewechgeholl goufen, huet den Decoder ugefaang ze schaffen. Et huet awer keng Problemer gewisen.
Wat och ëmmer ee seet, näischt anescht gouf fonnt ausser déi Sysctl. Alles wat blouf war e Wee ze fannen fir Problemserveren z'identifizéieren fir d'Skala ze verstoen an iwwer weider Aktiounen ze entscheeden. Déi néideg Konter gouf séier genuch fonnt:
netstat -s | grep "packet reassembles failed”
Et ass och am snmpd ënner OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"D'Zuel vun de Feeler, déi vum IP-Re-Assemblée Algorithmus festgestallt ginn (aus irgend engem Grond: Timeout, Feeler, etc.)."
Ënnert der Grupp vu Serveren, op deenen de Problem studéiert gouf, ass op zwee dëse Konter méi séier eropgaang, op zwee méi lues, an op zwee méi ass et guer net eropgaang. D'Dynamik vun dësem Konter ze vergläichen mat der Dynamik vun HTTP-Feeler um Java-Server huet eng Korrelatioun opgedeckt. Dat heescht, de Meter kéint iwwerwaacht ginn.
En zouverlässeg Indikator vu Probleemer ze hunn ass ganz wichteg fir datt Dir präzis feststellt ob Sysctl zréckrollen hëlleft, well aus der viregter Geschicht wësse mer datt dëst net direkt aus der Applikatioun verstane kann. Dësen Indikator erlaabt eis all Problemberäicher an der Produktioun z'identifizéieren ier d'Benotzer et entdecken.
Nom Réckrollen vum Sysctl hunn d'Iwwerwaachungsfehler gestoppt, sou datt d'Ursaach vun de Probleemer bewisen ass, wéi och d'Tatsaach datt d'Rollback hëlleft.
Mir hunn d'Fragmentéierungsastellungen op anere Serveren zréckgeréckelt, wou nei Iwwerwaachung an d'Spill koumen, an iergendwou hu mir nach méi Erënnerung fir Fragmenter zougewisen wéi virdru Standard (dëst war UDP Statistiken, de partielle Verloscht vun deem war net opfälleg géint den allgemengen Hannergrond) .
Déi wichtegst Froen
Firwat sinn Päckchen op eisem L3 Balancer fragmentéiert? Déi meescht vun de Päckchen, déi vu Benotzer op Balancer kommen, sinn SYN an ACK. D'Gréisste vun dëse Packagen si kleng. Awer well den Undeel vun esou Päckchen ganz grouss ass, géint hiren Hannergrond hu mir net d'Präsenz vu grousse Päck gemierkt, déi ugefaang ze fragmentéieren.
De Grond war e futtis Konfiguratiounsskript op Serveren mat Vlan Schnëttplazen (et waren ganz wéineg Serveren mat tagged Traffic an der Produktioun zu där Zäit). Advmss erlaabt eis dem Client d'Informatioun ze vermëttelen datt Päckchen an eiser Richtung méi kleng a Gréisst solle sinn, sou datt se net fragmentéiert musse ginn, nodeems se Tunnel Header ugeschloss hunn.
Firwat huet Sysctl Rollback net gehollef, awer Neistart huet? D'Rulling zréck Sysctl huet d'Quantitéit u Erënnerung geännert fir Packagen ze fusionéieren. Zur selwechter Zäit huet anscheinend de ganz Fakt vum Erënnerungsiwwerlaf fir Fragmenter zu enger Verlängerung vu Verbindungen gefouert, wat zu Fragmenter gefouert huet fir eng laang Zäit an der Schlaang ze verspéiten. Dat ass, de Prozess ass an Zyklen gaangen.
De Restart huet d'Erënnerung geläscht an alles ass zréck op d'Bestellung.
War et méiglech ouni Workaround ze maachen? Jo, awer et ass en héije Risiko fir Benotzer ouni Service am Fall vun engem Attack ze loossen. Natierlech huet d'Benotzung vu Workaround zu verschiddene Probleemer gefouert, dorënner de Verlängerung vun engem vun de Servicer fir Benotzer, awer trotzdem gleewen mir datt d'Aktiounen gerechtfäerdegt waren.
Villmools Merci dem Andrey Timofeev () fir Hëllef bei der Duerchféierung vun der Enquête, souwéi Alexey Krenev () - fir d'titanesch Aarbecht fir d'Aktualiséierung vun Centos a Kernelen op Serveren. E Prozess, deen an dësem Fall e puer Mol vun Ufank un huet misse lancéiert ginn, an dofir huet e vill Méint gedauert.
Source: will.com