Sveiki visiem! Mani sauc Dmitrijs Samsonovs, es strÄdÄju par vadoÅ”o sistÄmas administratoru uzÅÄmumÄ Odnoklassniki. Mums ir vairÄk nekÄ 7 tÅ«kstoÅ”i fizisko serveru, 11 tÅ«kstoÅ”i konteineru mÄkonÄ« un 200 aplikÄcijas, kas dažÄdÄs konfigurÄcijÄs veido 700 dažÄdus klasterus. LielÄkajÄ daÄ¼Ä serveru darbojas CentOS 7.
14. gada 2018. augustÄ tika publicÄta informÄcija par FragmentSmack ievainojamÄ«bu
() un SegmentSmack (). TÄs ir ievainojamÄ«bas ar tÄ«kla uzbrukuma vektoru un diezgan augstu punktu skaitu (7.5), kas apdraud pakalpojuma atteikumu (DoS) resursu izsmelÅ”anas (CPU) dÄļ. Kodola labojums FragmentSmack tobrÄ«d netika piedÄvÄts, turklÄt tas iznÄca daudz vÄlÄk, nekÄ tika publicÄta informÄcija par ievainojamÄ«bu. Lai novÄrstu SegmentSmack, tika ierosinÄts atjauninÄt kodolu. Pati atjauninÄÅ”anas pakotne tika izlaista tajÄ paÅ”Ä dienÄ, atlika tikai to instalÄt.
NÄ, mÄs vispÄr neesam pret kodola atjauninÄÅ”anu! TomÄr ir nianses...
KÄ mÄs atjauninÄm kodolu ražoÅ”anÄ
KopumÄ nekas sarežģīts:
- LejupielÄdÄt pakotnes;
- InstalÄjiet tos vairÄkos serveros (tostarp serveros, kas mitina mÅ«su mÄkoni);
- PÄrliecinieties, ka nekas nav salauzts;
- PÄrliecinieties, vai visi standarta kodola iestatÄ«jumi tiek lietoti bez kļūdÄm;
- Pagaidiet dažas dienas;
- PÄrbaudiet servera veiktspÄju;
- PÄrslÄgt jaunu serveru izvietoÅ”anu uz jauno kodolu;
- Atjauniniet visus serverus pÄc datu centra (vienÄ datu centrÄ, lai problÄmu gadÄ«jumÄ samazinÄtu ietekmi uz lietotÄjiem);
- PÄrstartÄjiet visus serverus.
AtkÄrtojiet to visiem mÅ«su kodolu atzariem. Å obrÄ«d tas ir:
- Stock CentOS 7 3.10 ā lielÄkajai daļai parasto serveru;
- Vaniļa 4.19 - mÅ«sÄjiem , jo mums vajag BFQ, BBR utt.;
- Elrepo kodols-ml 5.2 - par , jo 4.19 agrÄk izturÄjÄs nestabili, bet ir vajadzÄ«gas tÄs paÅ”as funkcijas.
KÄ jau varÄja uzminÄt, tÅ«kstoÅ”iem serveru pÄrstartÄÅ”ana aizÅem visilgÄko laiku. TÄ kÄ ne visas ievainojamÄ«bas ir kritiskas visiem serveriem, mÄs atsÄknÄjam tikai tos, kas ir tieÅ”i pieejami no interneta. MÄkonÄ«, lai neierobežotu elastÄ«bu, mÄs nepiesaistÄm ÄrÄji pieejamos konteinerus atseviŔķiem serveriem ar jaunu kodolu, bet pÄrstartÄjam visus saimniekdatorus bez izÅÄmuma. Par laimi, procedÅ«ra tur ir vienkÄrÅ”Äka nekÄ ar parastajiem serveriem. PiemÄram, atsÄknÄÅ”anas laikÄ konteineri bez statusa var vienkÄrÅ”i pÄrvietoties uz citu serveri.
TomÄr darba joprojÄm ir daudz, un tas var ilgt vairÄkas nedÄļas, un, ja rodas problÄmas ar jauno versiju, lÄ«dz pat vairÄkiem mÄneÅ”iem. UzbrucÄji to ļoti labi saprot, tÄpÄc viÅiem ir nepiecieÅ”ams plÄns B.
FragmentSmack/SegmentSmack. Apiet
Par laimi, dažÄm ievainojamÄ«bÄm pastÄv Å”Äds plÄns B, un to sauc par risinÄjumu. VisbiežÄk tÄs ir kodola/lietojumprogrammas iestatÄ«jumu izmaiÅas, kas var samazinÄt iespÄjamo efektu vai pilnÄ«bÄ novÄrst ievainojamÄ«bu izmantoÅ”anu.
FragmentSmack/SegmentSmack gadÄ«jumÄ Å Äds risinÄjums:
Ā«Varat mainÄ«t noklusÄjuma vÄrtÄ«bas 4MB un 3MB failos net.ipv4.ipfrag_high_thresh un net.ipv4.ipfrag_low_thresh (un to ekvivalentos ipv6 net.ipv6.ipfrag_high_thresh un net.ipv6.ipfrag_low_thresh) uz attiecÄ«gi 256 vai kB un kB. zemÄks. Testi uzrÄda nelielu lÄ«dz ievÄrojamu CPU lietojuma kritumu uzbrukuma laikÄ atkarÄ«bÄ no aparatÅ«ras, iestatÄ«jumiem un apstÄkļiem. TomÄr ipfrag_high_thresh=192 baiti var ietekmÄt veiktspÄju, jo montÄžas rindÄ vienlaikus var ietilpt tikai divi 262144 64 fragmenti. PiemÄram, pastÄv risks, ka lietojumprogrammas, kas strÄdÄ ar lielÄm UDP paketÄm, sabojÄsies'.
PaÅ”i parametri aprakstÄ«ts Å”Ädi:
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.
Mums nav lielu UDP ražoÅ”anas pakalpojumiem. VietÄjÄ tÄ«klÄ nav sadrumstalotas trafika; WAN ir sadrumstalota trafika, taÄu tÄ nav nozÄ«mÄ«ga. Nav nekÄdu pazÄ«mju ā varat ieviest risinÄjumu!
FragmentSmack/SegmentSmack. PirmÄs asinis
PirmÄ problÄma, ar ko mÄs saskÄrÄmies, bija tÄ, ka mÄkoÅa konteineri dažreiz lietoja jaunos iestatÄ«jumus tikai daļÄji (tikai ipfrag_low_thresh), un dažreiz tos neizmantoja vispÄr ā tie vienkÄrÅ”i avarÄja sÄkumÄ. ProblÄmu nebija iespÄjams stabili reproducÄt (visi iestatÄ«jumi tika lietoti manuÄli bez jebkÄdÄm grÅ«tÄ«bÄm). Saprast, kÄpÄc konteiners avarÄ sÄkumÄ, arÄ« nav tik vienkÄrÅ”i: kļūdas netika atrastas. Viena lieta bija droÅ”a: iestatÄ«jumu atgrieÅ”ana atrisina konteinera avÄriju problÄmu.
KÄpÄc nepietiek ar Sysctl lietoÅ”anu resursdatorÄ? Konteiners atrodas savÄ Ä«paÅ”Ä tÄ«klÄ Namespace, tÄpÄc vismaz konteinerÄ var atŔķirties no saimniekdatora.
KÄ tieÅ”i Sysctl iestatÄ«jumi tiek lietoti konteinerÄ? TÄ kÄ mÅ«su konteineri nav priviliÄ£Äti, jÅ«s nevarÄsit mainÄ«t nevienu Sysctl iestatÄ«jumu, ieejot paÅ”Ä konteinerÄ ā jums vienkÄrÅ”i nav pietiekami daudz tiesÄ«bu. Lai darbinÄtu konteinerus, mÅ«su mÄkonis tajÄ laikÄ izmantoja Docker (tagad ). JaunÄ konteinera parametri tika nodoti Docker, izmantojot API, ieskaitot nepiecieÅ”amos Sysctl iestatÄ«jumus.
PÄrmeklÄjot versijas, izrÄdÄ«jÄs, ka Docker API neatgrieza visas kļūdas (vismaz versijÄ 1.10). Kad mÄÄ£inÄjÄm iedarbinÄt konteineru, izmantojot ādocker runā, mÄs beidzot redzÄjÄm vismaz kaut ko:
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.
Parametra vÄrtÄ«ba nav derÄ«ga. Bet kÄpÄc? Un kÄpÄc tas nav derÄ«gs tikai dažreiz? IzrÄdÄ«jÄs, ka Docker negarantÄ secÄ«bu, kÄdÄ tiek lietoti Sysctl parametri (jaunÄkÄ pÄrbaudÄ«tÄ versija ir 1.13.1), tÄpÄc dažreiz ipfrag_high_thresh mÄÄ£inÄja iestatÄ«t uz 256K, kad ipfrag_low_thresh vÄl bija 3M, tas ir, augÅ”ÄjÄ robeža bija zemÄka. nekÄ apakÅ”ÄjÄ robeža, kas izraisÄ«ja kļūdu.
TajÄ laikÄ mÄs jau izmantojÄm savu mehÄnismu konteinera pÄrkonfigurÄÅ”anai pÄc palaiÅ”anas (konteinera iesaldÄÅ”ana pÄc un komandu izpilde konteinera nosaukumvietÄ, izmantojot ), un Å”ai daļai pievienojÄm arÄ« Sysctl parametru rakstÄ«Å”anu. ProblÄma tika atrisinÄta.
FragmentSmack/SegmentSmack. PirmÄs asinis 2
Pirms mums bija laiks izprast Workaround izmantoÅ”anu mÄkonÄ«, sÄka saÅemt pirmÄs retÄs lietotÄju sÅ«dzÄ«bas. TobrÄ«d bija pagÄjuÅ”as vairÄkas nedÄļas kopÅ” Workaround lietoÅ”anas sÄkuma pirmajos serveros. SÄkotnÄjÄ izmeklÄÅ”ana parÄdÄ«ja, ka sÅ«dzÄ«bas saÅemtas par atseviŔķiem pakalpojumiem, nevis visiem Å”o pakalpojumu serveriem. ProblÄma atkal ir kļuvusi ÄrkÄrtÄ«gi neskaidra.
PirmkÄrt, mÄs, protams, mÄÄ£inÄjÄm atsaukt Sysctl iestatÄ«jumus, taÄu tam nebija nekÄdas ietekmes. NelÄ«dzÄja arÄ« dažÄdas manipulÄcijas ar servera un aplikÄcijas iestatÄ«jumiem. AtsÄknÄÅ”ana palÄ«dzÄja. Linux atsÄknÄÅ”ana ir tikpat nedabiska, kÄ tas bija normÄli operÄtÄjsistÄmai Windows vecos laikos. TomÄr tas palÄ«dzÄja, un, piemÄrojot jaunos Sysctl iestatÄ«jumus, mÄs to izraisÄ«jÄm lÄ«dz ākodola kļūmeiā. Cik tas bija vieglprÄtÄ«gi...
PÄc trim nedÄļÄm problÄma atkÄrtojÄs. Å o serveru konfigurÄcija bija diezgan vienkÄrÅ”a: Nginx starpniekservera/balansÄtÄja režīmÄ. Nav daudz satiksmes. Jauna ievada piezÄ«me: 504 kļūdu skaits klientiem pieaug katru dienu (). DiagrammÄ parÄdÄ«ts 504 kļūdu skaits dienÄ Å”im pakalpojumam:
Visas kļūdas ir par vienu un to paÅ”u aizmuguri ā par to, kas atrodas mÄkonÄ«. AtmiÅas patÄriÅa grafiks pakotÅu fragmentiem Å”ajÄ aizmugursistÄmÄ izskatÄ«jÄs Å”Ädi:
Å Ä« ir viena no acÄ«mredzamÄkajÄm problÄmas izpausmÄm operÄtÄjsistÄmas grafikos. MÄkonÄ« tajÄ paÅ”Ä laikÄ tika novÄrsta cita tÄ«kla problÄma ar QoS (Traffic Control) iestatÄ«jumiem. PakeÅ”u fragmentu atmiÅas patÄriÅa grafikÄ tas izskatÄ«jÄs tieÅ”i tÄpat:
PieÅÄmums bija vienkÄrÅ”s: ja tie grafikos izskatÄs vienÄdi, tad tiem ir viens un tas pats iemesls. TurklÄt jebkÄdas problÄmas ar Å”Äda veida atmiÅu ir ÄrkÄrtÄ«gi reti.
FiksÄtÄs problÄmas bÅ«tÄ«ba bija tÄda, ka mÄs izmantojÄm fq pakeÅ”u plÄnotÄju ar noklusÄjuma iestatÄ«jumiem QoS. PÄc noklusÄjuma vienam savienojumam tas ļauj rindai pievienot 100 paketes, un daži savienojumi kanÄla trÅ«kuma situÄcijÄs sÄka aizsprostot rindu lÄ«dz ietilpÄ«bai. Å ajÄ gadÄ«jumÄ paketes tiek nomestas. Tc statistikÄ (tc -s qdisc) to var redzÄt Å”Ädi:
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ā ir paketes, kas tika izmestas, jo ir pÄrsniegts viena savienojuma rindas ierobežojums, un ānokrita 464545ā ir visu Ŕī plÄnotÄja atmesto pakeÅ”u summa. PÄc rindas garuma palielinÄÅ”anas lÄ«dz 1 tÅ«kstotim un konteineru restartÄÅ”anas problÄma pÄrstÄja rasties. JÅ«s varat sÄdÄt un iedzert smÅ«tiju.
FragmentSmack/SegmentSmack. PÄdÄjÄs asinis
PirmkÄrt, vairÄkus mÄneÅ”us pÄc paziÅojuma par ievainojamÄ«bu kodolÄ, beidzot parÄdÄ«jÄs FragmentSmack labojums (atgÄdinÄÅ”u, ka lÄ«dz ar paziÅojumu augustÄ tika izlaists tikai SegmentSmack labojums), kas deva mums iespÄju atteikties no Workaround, kas mums sagÄdÄja diezgan daudz nepatikÅ”anas. Å ajÄ laikÄ mÄs jau bijÄm paspÄjuÅ”i pÄrsÅ«tÄ«t dažus serverus uz jauno kodolu, un tagad mums bija jÄsÄk no sÄkuma. KÄpÄc mÄs atjauninÄjÄm kodolu, negaidot FragmentSmack labojumu? Fakts ir tÄds, ka aizsardzÄ«bas process pret Ŕīm ievainojamÄ«bÄm sakrita (un apvienojÄs) ar paÅ”a CentOS atjauninÄÅ”anas procesu (kas aizÅem pat vairÄk laika nekÄ tikai kodola atjauninÄÅ”ana). TurklÄt SegmentSmack ir bÄ«stamÄka ievainojamÄ«ba, un tÄs labojums parÄdÄ«jÄs nekavÄjoties, tÄpÄc tam bija jÄga. TomÄr mÄs nevarÄjÄm vienkÄrÅ”i atjauninÄt CentOS kodolu, jo FragmentSmack ievainojamÄ«ba, kas parÄdÄ«jÄs CentOS 7.5 laikÄ, tika novÄrsta tikai 7.6 versijÄ, tÄpÄc mums bija jÄpÄrtrauc atjauninÄÅ”ana uz 7.5 un jÄsÄk no jauna ar atjauninÄÅ”anu uz 7.6. Un tas arÄ« notiek.
OtrkÄrt, pie mums ir atgriezuÅ”Äs retas lietotÄju sÅ«dzÄ«bas par problÄmÄm. Tagad mÄs jau droÅ”i zinÄm, ka tie visi ir saistÄ«ti ar failu augÅ”upielÄdi no klientiem uz dažiem mÅ«su serveriem. TurklÄt caur Å”iem serveriem tika veikts ļoti neliels augÅ”upielÄdes skaits no kopÄjÄs masas.
KÄ mÄs atceramies no iepriekÅ” minÄtÄ stÄsta, Sysctl atgrieÅ”ana nepalÄ«dzÄja. AtsÄknÄÅ”ana palÄ«dzÄja, bet Ä«slaicÄ«gi.
Aizdomas par Sysctl netika noÅemtas, taÄu Å”oreiz bija nepiecieÅ”ams savÄkt pÄc iespÄjas vairÄk informÄcijas. TÄpat ļoti trÅ«ka spÄjas reproducÄt augÅ”upielÄdes problÄmu klientam, lai precÄ«zÄk izpÄtÄ«tu notiekoÅ”o.
Visas pieejamÄs statistikas un žurnÄlu analÄ«ze neļÄva mums tuvÄk saprast, kas notiek. Bija akÅ«ts nespÄja atveidot problÄmu, lai āsajustuā konkrÄtu saikni. Visbeidzot, izstrÄdÄtÄjiem, izmantojot Ä«paÅ”u lietojumprogrammas versiju, izdevÄs panÄkt stabilu problÄmu reproducÄÅ”anu testa ierÄ«cÄ, kad tika izveidots savienojums, izmantojot Wi-Fi. Tas bija izrÄviens izmeklÄÅ”anÄ. Klients izveidoja savienojumu ar Nginx, kas bija starpniekserveris ar aizmugursistÄmu, kas bija mÅ«su Java lietojumprogramma.
Dialogs par problÄmÄm bija Å”Äds (fiksÄts Nginx starpniekservera pusÄ):
- Klients: pieprasÄ«t informÄciju par faila lejupielÄdi.
- Java serveris: atbilde.
- Klients: POST ar failu.
- Java serveris: kļūda.
TajÄ paÅ”Ä laikÄ Java serveris ieraksta žurnÄlÄ, ka no klienta tika saÅemti 0 baiti datu, un Nginx starpniekserveris raksta, ka pieprasÄ«jums aizÅÄma vairÄk nekÄ 30 sekundes (30 sekundes ir klienta lietojumprogrammas taimauts). KÄpÄc noildze un kÄpÄc 0 baiti? No HTTP viedokļa viss darbojas kÄ nÄkas, taÄu Ŕķiet, ka POST ar failu pazÅ«d no tÄ«kla. TurklÄt tas pazÅ«d starp klientu un Nginx. Ir pienÄcis laiks bruÅoties ar Tcpdump! Bet vispirms jums ir jÄsaprot tÄ«kla konfigurÄcija. Nginx starpniekserveris atrodas aiz L3 balansÄtÄja . TunelÄÅ”ana tiek izmantota, lai piegÄdÄtu paketes no L3 balansÄtÄja uz serveri, kas pievieno paketÄm savas galvenes:
Å ajÄ gadÄ«jumÄ tÄ«kls Å”ajÄ serverÄ« nonÄk Vlan marÄ·Ätas trafika veidÄ, kas arÄ« pievieno savus laukus paketÄm:
Un Ŕī trafika var bÅ«t arÄ« sadrumstalota (tÄ pati neliela daļa no ienÄkoÅ”Äs sadrumstalotÄs trafika, par kuru mÄs runÄjÄm, novÄrtÄjot riskus, ko rada risinÄjums), kas arÄ« maina galveÅu saturu:
VÄlreiz: paketes ir iekapsulÄtas ar Vlan tagu, iekapsulÄtas ar tuneli, sadrumstalotas. Lai labÄk izprastu, kÄ tas notiek, izsekosim pakeÅ”u marÅ”rutu no klienta uz Nginx starpniekserveri.
- Pakete sasniedz L3 balansÄtÄju. Pareizai marÅ”rutÄÅ”anai datu centrÄ pakete tiek iekapsulÄta tunelÄ« un nosÅ«tÄ«ta uz tÄ«kla karti.
- TÄ kÄ pakete + tuneļa galvenes neietilpst MTU, pakete tiek sagriezta fragmentos un nosÅ«tÄ«ta uz tÄ«klu.
- SlÄdzis aiz L3 balansÄtÄja, saÅemot paketi, pievieno tai Vlan tagu un nosÅ«ta to.
- SlÄdzis Nginx starpniekservera priekÅ”Ä redz (pamatojoties uz porta iestatÄ«jumiem), ka serveris gaida Vlan iekapsulÄtu paketi, tÄpÄc tas nosÅ«ta to tÄdu, kÄds tas ir, nenoÅemot Vlan tagu.
- Linux Åem atseviŔķu pakotÅu fragmentus un apvieno tos vienÄ lielÄ pakotnÄ.
- TÄlÄk pakete sasniedz Vlan saskarni, kur no tÄs tiek noÅemts pirmais slÄnis - Vlan iekapsulÄÅ”ana.
- PÄc tam Linux to nosÅ«ta uz tuneļa interfeisu, kur no tÄ tiek noÅemts vÄl viens slÄnis - tuneļa iekapsulÄÅ”ana.
GrÅ«tÄ«bas ir nodot to visu kÄ parametrus tcpdump.
SÄksim no beigÄm: vai ir tÄ«ras (bez nevajadzÄ«gÄm galvenÄm) IP paketes no klientiem, ar noÅemtu vlan un tuneļa iekapsulÄciju?
tcpdump host <ip ŠŗŠ»ŠøŠµŠ½ŃŠ°>
NÄ, serverÄ« Å”Ädu pakotÅu nebija. TÄtad problÄmai jÄbÅ«t jau agrÄk. Vai ir kÄdas paketes, kurÄm ir noÅemta tikai Vlan iekapsulÄÅ”ana?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx ir klienta IP adrese hex formÄtÄ.
32:4 ā tÄ lauka adrese un garums, kurÄ tuneļa paketÄ ierakstÄ«ts SCR IP.
Lauka adrese bija jÄizvÄlas ar brutÄlu spÄku, jo internetÄ viÅi raksta par 40, 44, 50, 54, bet tur nebija IP adreses. Varat arÄ« apskatÄ«t vienu no paketÄm hex formÄtÄ (parametrs -xx vai -XX tcpdump) un aprÄÄ·inÄt jums zinÄmo IP adresi.
Vai ir pakeÅ”u fragmenti, kuriem nav noÅemta Vlan un tuneļa iekapsulÄÅ”ana?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Å Ä« maÄ£ija mums parÄdÄ«s visus fragmentus, ieskaitot pÄdÄjo. DroÅ”i vien to paÅ”u var filtrÄt pÄc IP, bet es nemÄÄ£inÄju, jo Å”Ädu pakeÅ”u nav ļoti daudz, un vajadzÄ«gÄs man bija viegli atrast vispÄrÄjÄ plÅ«smÄ. Å eit tie ir:
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 ..............
Tie ir divi viena iepakojuma fragmenti (tas pats ID 53652) ar fotogrÄfiju (pirmajÄ iepakojumÄ redzams vÄrds Exif). SakarÄ ar to, ka Å”ajÄ lÄ«menÄ« ir iepakojumi, bet ne apvienotÄ veidÄ izgÄztuvÄs, problÄma nepÄrprotami ir montÄžÄ. Beidzot tam ir dokumentÄri pierÄdÄ«jumi!
PakeÅ”u dekodÄtÄjs neatklÄja nekÄdas problÄmas, kas kavÄtu veidoÅ”anu. IzmÄÄ£inÄju Å”eit: . SÄkumÄ, mÄÄ£inot kaut ko tur ievietot, dekodÄtÄjam nepatÄ«k pakeÅ”u formÄts. IzrÄdÄ«jÄs, ka starp Srcmac un Ethertype bija daži papildu divi okteti (nav saistÄ«ti ar fragmenta informÄciju). PÄc to noÅemÅ”anas dekodÄtÄjs sÄka darboties. TomÄr tas neuzrÄdÄ«ja nekÄdas problÄmas.
Lai ko arÄ« teiktu, nekas cits netika atrasts, izÅemot Sysctl. Atlika tikai atrast veidu, kÄ identificÄt problÄmu serverus, lai saprastu mÄrogu un izlemtu par turpmÄkajÄm darbÄ«bÄm. NepiecieÅ”amais skaitÄ«tÄjs tika atrasts pietiekami Ätri:
netstat -s | grep "packet reassembles failedā
Tas ir arī snmpd ar OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"IP atkÄrtotas montÄžas algoritma atklÄto kļūmju skaits (jebkura iemesla dÄļ: noildze, kļūdas utt.)."
No serveru grupas, kurÄ problÄma tika pÄtÄ«ta, divos Å”is skaitÄ«tÄjs palielinÄjÄs ÄtrÄk, divos lÄnÄk, bet vÄl divos tas nepalielinÄjÄs vispÄr. SalÄ«dzinot Ŕī skaitÄ«tÄja dinamiku ar HTTP kļūdu dinamiku Java serverÄ«, atklÄjÄs korelÄcija. Tas ir, skaitÄ«tÄju varÄja uzraudzÄ«t.
Ir ļoti svarÄ«gi, lai bÅ«tu uzticams problÄmu indikators, lai jÅ«s varÄtu precÄ«zi noteikt, vai Sysctl atgrieÅ”ana palÄ«dz, jo no iepriekÅ”ÄjÄ stÄsta mÄs zinÄm, ka to nevar uzreiz saprast no lietojumprogrammas. Å is rÄdÄ«tÄjs ļautu mums identificÄt visas ražoÅ”anas problemÄtiskÄs jomas, pirms lietotÄji to atklÄj.
PÄc Sysctl atgrieÅ”anas pÄrraudzÄ«bas kļūdas apstÄjÄs, tÄdÄjÄdi tika pierÄdÄ«ts problÄmu cÄlonis, kÄ arÄ« tas, ka atgrieÅ”ana palÄ«dz.
MÄs atcÄlÄm sadrumstalotÄ«bas iestatÄ«jumus citos serveros, kur parÄdÄ«jÄs jauna uzraudzÄ«ba, un kaut kur fragmentiem pieŔķīrÄm vÄl vairÄk atmiÅas nekÄ iepriekÅ” bija pÄc noklusÄjuma (tÄ bija UDP statistika, kuras daļÄjs zudums nebija manÄms uz vispÄrÄjÄ fona) .
SvarÄ«gÄkie jautÄjumi
KÄpÄc mÅ«su L3 balansÄtÄja paketes ir sadrumstalotas? LielÄkÄ daļa pakeÅ”u, kas pienÄk no lietotÄjiem lÄ«dzsvarotÄjiem, ir SYN un ACK. Å o iepakojumu izmÄri ir mazi. Bet, tÄ kÄ Å”Ädu pakeÅ”u Ä«patsvars ir ļoti liels, uz to fona mÄs nepamanÄ«jÄm lielu pakeÅ”u klÄtbÅ«tni, kas sÄka sadrumstalot.
Iemesls bija bojÄts konfigurÄcijas skripts serveros ar Vlan saskarnÄm (tolaik ražoÅ”anÄ bija ļoti maz serveru ar tagu trafiku). Advmss ļauj mums nodot klientam informÄciju, ka mÅ«su virzienÄ esoÅ”ajÄm paketÄm jÄbÅ«t mazÄkÄm, lai pÄc tuneļa galveÅu pievienoÅ”anas tÄm nebÅ«tu jÄsadala.
KÄpÄc Sysctl atcelÅ”ana nepalÄ«dzÄja, bet atsÄknÄÅ”ana palÄ«dzÄja? Sysctl atgrieÅ”ana mainÄ«ja pakotÅu sapludinÄÅ”anai pieejamÄs atmiÅas apjomu. TajÄ paÅ”Ä laikÄ, acÄ«mredzot, pats fragmentu atmiÅas pÄrpildes fakts izraisÄ«ja savienojumu palÄninÄÅ”anos, kas noveda pie fragmentu ilgas aizkavÄÅ”anÄs rindÄ. Tas ir, process noritÄja ciklos.
AtsÄknÄÅ”ana iztÄ«rÄ«ja atmiÅu, un viss atgriezÄs kÄrtÄ«bÄ.
Vai bija iespÄjams iztikt bez risinÄjuma? JÄ, taÄu pastÄv liels risks atstÄt lietotÄjus bez pakalpojuma uzbrukuma gadÄ«jumÄ. Protams, Workaround izmantoÅ”ana radÄ«ja dažÄdas problÄmas, tostarp viena no pakalpojumu bremzÄÅ”anu lietotÄjiem, taÄu mÄs uzskatÄm, ka darbÄ«bas bija pamatotas.
Liels paldies Andrejam Timofejevam () par palÄ«dzÄ«bu izmeklÄÅ”anas veikÅ”anÄ, kÄ arÄ« Aleksejam KreÅevam () - par titÄnisko Centos un kodolu atjauninÄÅ”anu serveros. Process, kas Å”ajÄ gadÄ«jumÄ vairÄkas reizes bija jÄsÄk no sÄkuma, tÄpÄc tas ievilkÄs daudzus mÄneÅ”us.
Avots: www.habr.com