નબળાઈઓથી સાવચેત રહો જે કામના રાઉન્ડ લાવે છે. ભાગ 1: FragmentSmack/SegmentSmack

કેમ છો બધા! મારું નામ દિમિત્રી સેમસોનોવ છે, હું ઓડનોક્લાસ્નીકીમાં અગ્રણી સિસ્ટમ એડમિનિસ્ટ્રેટર તરીકે કામ કરું છું. અમારી પાસે 7 હજારથી વધુ ભૌતિક સર્વર્સ છે, અમારા ક્લાઉડમાં 11 હજાર કન્ટેનર અને 200 એપ્લિકેશન્સ છે, જે વિવિધ રૂપરેખાંકનોમાં 700 વિવિધ ક્લસ્ટર બનાવે છે. મોટાભાગના સર્વર્સ CentOS 7 ચલાવે છે.
14 ઓગસ્ટ, 2018 ના રોજ, FragmentSmack નબળાઈ વિશેની માહિતી પ્રકાશિત કરવામાં આવી હતી
(CVE-2018-5391) અને સેગમેન્ટસ્મેક (CVE-2018-5390). આ નેટવર્ક એટેક વેક્ટર અને એકદમ ઉચ્ચ સ્કોર (7.5) સાથેની નબળાઈઓ છે, જે રિસોર્સ એક્ઝોશન (CPU)ને કારણે સેવાને નકારવાની (DoS) ધમકી આપે છે. તે સમયે FragmentSmack માટે કર્નલ ફિક્સની દરખાસ્ત કરવામાં આવી ન હતી; વધુમાં, તે નબળાઈ વિશેની માહિતીના પ્રકાશન કરતાં ઘણું પાછળથી બહાર આવ્યું હતું. સેગમેન્ટસ્મેકને દૂર કરવા માટે, કર્નલને અપડેટ કરવાનું સૂચન કરવામાં આવ્યું હતું. અપડેટ પેકેજ પોતે તે જ દિવસે બહાર પાડવામાં આવ્યું હતું, જે બાકી હતું તે તેને ઇન્સ્ટોલ કરવાનું હતું.
ના, અમે કર્નલને અપડેટ કરવાની વિરુદ્ધ નથી! જો કે, ત્યાં ઘોંઘાટ છે ...

અમે ઉત્પાદન પર કર્નલને કેવી રીતે અપડેટ કરીએ છીએ

સામાન્ય રીતે, કંઈ જટિલ નથી:

1. પેકેજો ડાઉનલોડ કરો;
2. તેમને સંખ્યાબંધ સર્વર્સ પર ઇન્સ્ટોલ કરો (અમારા ક્લાઉડને હોસ્ટ કરતા સર્વર્સ સહિત);
3. ખાતરી કરો કે કંઈપણ તૂટી ગયું નથી;
4. ખાતરી કરો કે બધી પ્રમાણભૂત કર્નલ સેટિંગ્સ ભૂલો વિના લાગુ કરવામાં આવી છે;
5. થોડા દિવસો રાહ જુઓ;
6. સર્વર કામગીરી તપાસો;
7. નવા સર્વરની જમાવટને નવા કર્નલ પર સ્વિચ કરો;
8. ડેટા સેન્ટર દ્વારા બધા સર્વર્સને અપડેટ કરો (સમસ્યાઓના કિસ્સામાં વપરાશકર્તાઓ પર અસર ઘટાડવા માટે એક સમયે એક ડેટા સેન્ટર);
9. બધા સર્વર્સ રીબુટ કરો.

અમારી પાસેના કર્નલોની બધી શાખાઓ માટે પુનરાવર્તન કરો. આ ક્ષણે તે છે:

• સ્ટોક CentOS 7 3.10 - મોટાભાગના નિયમિત સર્વરો માટે;
• વેનીલા 4.19 - અમારા માટે એક-મેઘ વાદળો, કારણ કે અમને BFQ, BBR, વગેરેની જરૂર છે;
• Elrepo કર્નલ-ml 5.2 - માટે અત્યંત લોડ થયેલ વિતરકો, કારણ કે 4.19 અસ્થિર વર્તન કરવા માટે વપરાય છે, પરંતુ સમાન સુવિધાઓની જરૂર છે.

જેમ તમે અનુમાન લગાવ્યું હશે, હજારો સર્વર્સને રીબૂટ કરવામાં સૌથી લાંબો સમય લાગે છે. તમામ સર્વર માટે તમામ નબળાઈઓ મહત્વપૂર્ણ ન હોવાથી, અમે ફક્ત તે જ રીબૂટ કરીએ છીએ જે ઈન્ટરનેટથી સીધા સુલભ છે. ક્લાઉડમાં, લવચીકતાને મર્યાદિત ન કરવા માટે, અમે બાહ્ય રીતે સુલભ કન્ટેનરને વ્યક્તિગત સર્વર્સ સાથે નવા કર્નલ સાથે બાંધતા નથી, પરંતુ અપવાદ વિના તમામ હોસ્ટને રીબૂટ કરીએ છીએ. સદનસીબે, ત્યાંની પ્રક્રિયા નિયમિત સર્વરો કરતાં સરળ છે. ઉદાહરણ તરીકે, રીબૂટ દરમિયાન સ્ટેટલેસ કન્ટેનર બીજા સર્વર પર જઈ શકે છે.

જો કે, હજી ઘણું કામ બાકી છે, અને તેમાં ઘણા અઠવાડિયા લાગી શકે છે, અને જો નવા સંસ્કરણમાં કોઈ સમસ્યા હોય તો, કેટલાક મહિનાઓ સુધી. હુમલાખોરો આને સારી રીતે સમજે છે, તેથી તેમને પ્લાન Bની જરૂર છે.

FragmentSmack/SegmentSmack. વર્કઅરાઉન્ડ

સદનસીબે, કેટલીક નબળાઈઓ માટે આવી યોજના B અસ્તિત્વમાં છે, અને તેને વર્કઅરાઉન્ડ કહેવામાં આવે છે. મોટેભાગે, આ કર્નલ/એપ્લિકેશન સેટિંગ્સમાં ફેરફાર છે જે સંભવિત અસરને ઘટાડી શકે છે અથવા નબળાઈઓના શોષણને સંપૂર્ણપણે દૂર કરી શકે છે.

FragmentSmack/SegmentSmack ના કિસ્સામાં દરખાસ્ત કરવામાં આવી હતી આ ઉપાય:

«તમે net.ipv4.ipfrag_high_thresh અને net.ipv3.ipfrag_low_thresh (અને ipv4 net.ipv4.ipfrag_high_thresh અને net.ipv6.ipfrag_high_thresh અને net.ipv6.ipfrag_low_thresh માટે તેમના સમકક્ષો) માં 6MB અને 256MB ના ડિફૉલ્ટ મૂલ્યોને kB192 kB262144 અથવા kB64ive માં બદલી શકો છો. નીચેનું. પરીક્ષણો હાર્ડવેર, સેટિંગ્સ અને શરતોના આધારે હુમલા દરમિયાન CPU વપરાશમાં નાનાથી નોંધપાત્ર ઘટાડો દર્શાવે છે. જો કે, ipfrag_high_thresh=XNUMX બાઇટ્સને કારણે કેટલીક પ્રભાવ અસર થઈ શકે છે, કારણ કે એક સમયે માત્ર બે XNUMXK ટુકડાઓ ફરીથી એસેમ્બલી કતારમાં ફિટ થઈ શકે છે. ઉદાહરણ તરીકે, મોટા UDP પેકેટો સાથે કામ કરતી એપ્લીકેશનો તૂટી જશે તેવું જોખમ છે».

પરિમાણો પોતાને કર્નલ દસ્તાવેજીકરણમાં નીચે પ્રમાણે વર્ણવેલ:

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.

અમારી પાસે ઉત્પાદન સેવાઓ પર મોટા UDP નથી. LAN પર ફ્રેગમેન્ટેડ ટ્રાફિક નથી; WAN પર ફ્રેગમેન્ટેડ ટ્રાફિક છે, પરંતુ નોંધપાત્ર નથી. ત્યાં કોઈ ચિહ્નો નથી - તમે વર્કઅરાઉન્ડ રોલ આઉટ કરી શકો છો!

FragmentSmack/SegmentSmack. ફર્સ્ટ બ્લડ

અમે જે પ્રથમ સમસ્યાનો સામનો કર્યો તે એ હતી કે ક્લાઉડ કન્ટેનર કેટલીકવાર નવી સેટિંગ્સને માત્ર આંશિક રીતે લાગુ કરે છે (ફક્ત ipfrag_low_thresh), અને કેટલીકવાર તેને બિલકુલ લાગુ કરતા નથી - તે ફક્ત શરૂઆતમાં ક્રેશ થઈ ગયા હતા. સમસ્યાનું સ્થિર રીતે પુનઃઉત્પાદન કરવું શક્ય ન હતું (બધી સેટિંગ્સ કોઈપણ મુશ્કેલીઓ વિના મેન્યુઅલી લાગુ કરવામાં આવી હતી). શરૂઆતમાં કન્ટેનર ક્રેશ કેમ થાય છે તે સમજવું પણ એટલું સરળ નથી: કોઈ ભૂલો મળી નથી. એક વસ્તુ ચોક્કસ હતી: સેટિંગ્સને પાછું ફેરવવાથી કન્ટેનર ક્રેશની સમસ્યા હલ થાય છે.

હોસ્ટ પર Sysctl લાગુ કરવા માટે તે શા માટે પૂરતું નથી? કન્ટેનર તેના પોતાના સમર્પિત નેટવર્ક નેમસ્પેસમાં રહે છે, તેથી ઓછામાં ઓછું નેટવર્ક Sysctl પરિમાણોનો ભાગ કન્ટેનરમાં હોસ્ટથી અલગ હોઈ શકે છે.

કન્ટેનરમાં Sysctl સેટિંગ્સ કેવી રીતે લાગુ કરવામાં આવે છે? અમારા કન્ટેનર અનપ્રિવિલેજ્ડ હોવાથી, તમે કન્ટેનરમાં જ જઈને કોઈપણ Sysctl સેટિંગને બદલી શકશો નહીં - તમારી પાસે પૂરતા અધિકારો નથી. કન્ટેનર ચલાવવા માટે, અમારા ક્લાઉડ તે સમયે ડોકર (હવે પોડમેન). નવા કન્ટેનરના પરિમાણો જરૂરી Sysctl સેટિંગ્સ સહિત, API મારફતે ડોકરને પસાર કરવામાં આવ્યા હતા.
સંસ્કરણો દ્વારા શોધ કરતી વખતે, તે બહાર આવ્યું કે ડોકર API એ બધી ભૂલો પરત કરી નથી (ઓછામાં ઓછા સંસ્કરણ 1.10 માં). જ્યારે અમે "ડોકર રન" દ્વારા કન્ટેનર શરૂ કરવાનો પ્રયાસ કર્યો, ત્યારે અમે આખરે ઓછામાં ઓછું કંઈક જોયું:

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.

પરિમાણ મૂલ્ય માન્ય નથી. પણ શા માટે? અને શા માટે તે ફક્ત ક્યારેક જ માન્ય નથી? તે બહાર આવ્યું છે કે ડોકર એ ક્રમની બાંયધરી આપતું નથી કે જેમાં Sysctl પરિમાણો લાગુ કરવામાં આવ્યા છે (નવીનતમ પરીક્ષણ કરેલ સંસ્કરણ 1.13.1 છે), તેથી કેટલીકવાર ipfrag_high_thresh એ 256K પર સેટ કરવાનો પ્રયાસ કર્યો જ્યારે ipfrag_low_thresh હજુ 3M હતો, એટલે કે, ઉપલી મર્યાદા ઓછી હતી. નીચી મર્યાદા કરતાં, જે ભૂલ તરફ દોરી જાય છે.

તે સમયે, અમે પહેલાથી જ સ્ટાર્ટ પછી કન્ટેનરને ફરીથી ગોઠવવા માટે અમારી પોતાની પદ્ધતિનો ઉપયોગ કર્યો હતો (પછી કન્ટેનર ઠંડું કરવું જૂથ ફ્રીઝર અને મારફતે કન્ટેનરના નેમસ્પેસમાં આદેશો ચલાવી રહ્યા છે આઈપી નેટન્સ), અને અમે આ ભાગમાં Sysctl પેરામીટર લખવાનું પણ ઉમેર્યું છે. સમસ્યા હલ થઈ ગઈ.

FragmentSmack/SegmentSmack. પ્રથમ રક્ત 2

ક્લાઉડમાં વર્કઅરાઉન્ડનો ઉપયોગ સમજવા માટે અમારી પાસે સમય હતો તે પહેલાં, વપરાશકર્તાઓ તરફથી પ્રથમ દુર્લભ ફરિયાદો આવવા લાગી. તે સમયે, પ્રથમ સર્વર્સ પર વર્કઅરાઉન્ડનો ઉપયોગ કરવાની શરૂઆતથી ઘણા અઠવાડિયા પસાર થઈ ગયા હતા. પ્રારંભિક તપાસ દર્શાવે છે કે વ્યક્તિગત સેવાઓ સામે ફરિયાદો પ્રાપ્ત થઈ હતી, અને આ સેવાઓના તમામ સર્વર સામે નહીં. સમસ્યા ફરીથી અત્યંત અનિશ્ચિત બની છે.

સૌ પ્રથમ, અમે, અલબત્ત, Sysctl સેટિંગ્સને રોલ બેક કરવાનો પ્રયાસ કર્યો, પરંતુ આની કોઈ અસર થઈ નહીં. સર્વર અને એપ્લિકેશન સેટિંગ્સ સાથે વિવિધ મેનિપ્યુલેશન્સ પણ મદદ કરી શક્યા નથી. રીબૂટ મદદ કરી. Linux ને રીબૂટ કરવું એ એટલું જ અકુદરતી છે જેટલું જૂના દિવસોમાં વિન્ડોઝ માટે સામાન્ય હતું. જો કે, તે મદદ કરી, અને Sysctl માં નવી સેટિંગ્સ લાગુ કરતી વખતે અમે તેને "કર્નલ ગ્લિચ" સુધી લઈ લીધું. તે કેટલું વ્યર્થ હતું ...

ત્રણ અઠવાડિયા પછી સમસ્યા ફરી આવી. આ સર્વર્સનું રૂપરેખાંકન એકદમ સરળ હતું: પ્રોક્સી/બેલેન્સર મોડમાં Nginx. બહુ ટ્રાફિક નથી. નવી પ્રારંભિક નોંધ: ગ્રાહકો પર 504 ભૂલોની સંખ્યા દરરોજ વધી રહી છે (દ્વાર સમય સમાપ્તિ). ગ્રાફ આ સેવા માટે દરરોજ 504 ભૂલોની સંખ્યા બતાવે છે:

બધી ભૂલો સમાન બેકએન્ડ વિશે છે - જે ક્લાઉડમાં છે તેના વિશે. આ બેકએન્ડ પર પેકેજ ટુકડાઓ માટે મેમરી વપરાશ ગ્રાફ આના જેવો દેખાય છે:

આ ઓપરેટિંગ સિસ્ટમ ગ્રાફમાં સમસ્યાના સૌથી સ્પષ્ટ અભિવ્યક્તિઓ પૈકી એક છે. ક્લાઉડમાં, તે જ સમયે, QoS (ટ્રાફિક કંટ્રોલ) સેટિંગ્સ સાથે અન્ય નેટવર્ક સમસ્યાને ઠીક કરવામાં આવી હતી. પેકેટ ટુકડાઓ માટે મેમરી વપરાશના ગ્રાફ પર, તે બરાબર એ જ દેખાતું હતું:

ધારણા સરળ હતી: જો તેઓ ગ્રાફ પર સમાન દેખાય છે, તો તેમની પાસે સમાન કારણ છે. તદુપરાંત, આ પ્રકારની મેમરી સાથેની કોઈપણ સમસ્યાઓ અત્યંત દુર્લભ છે.

નિશ્ચિત સમસ્યાનો સાર એ હતો કે અમે QoS માં ડિફોલ્ટ સેટિંગ્સ સાથે fq પેકેટ શેડ્યૂલરનો ઉપયોગ કર્યો હતો. મૂળભૂત રીતે, એક કનેક્શન માટે, તે તમને કતારમાં 100 પેકેટો ઉમેરવાની મંજૂરી આપે છે, અને કેટલાક જોડાણો, ચેનલની અછતની પરિસ્થિતિઓમાં, કતારને ક્ષમતામાં રોકવાનું શરૂ કરે છે. આ કિસ્સામાં, પેકેટો છોડવામાં આવે છે. tc આંકડામાં (tc -s qdisc) તે આના જેવું જોઈ શકાય છે:

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” એ એક કનેક્શનની કતાર મર્યાદાને ઓળંગવાને કારણે ડ્રોપ થયેલા પેકેટો છે અને “ડ્રોપ 464545” એ આ શેડ્યૂલરના તમામ છોડેલા પેકેટોનો સરવાળો છે. કતારની લંબાઈ વધારીને 1 હજાર કરી અને કન્ટેનર ફરીથી ચાલુ કર્યા પછી, સમસ્યા ઊભી થવાનું બંધ થઈ ગયું. તમે પાછળ બેસીને સ્મૂધી પી શકો છો.

FragmentSmack/SegmentSmack. છેલ્લું લોહી

સૌપ્રથમ, કર્નલમાં નબળાઈઓની જાહેરાતના ઘણા મહિનાઓ પછી, આખરે FragmentSmack માટે એક ફિક્સ દેખાયો (હું તમને યાદ અપાવી દઉં કે ઓગસ્ટમાં જાહેરાતની સાથે, ફક્ત સેગમેન્ટસ્મેક માટેનો એક ફિક્સ બહાર પાડવામાં આવ્યો હતો), જેણે અમને વર્કઅરાઉન્ડને છોડી દેવાની તક આપી, જેના કારણે અમને ઘણી મુશ્કેલી પડી. આ સમય દરમિયાન, અમે પહેલાથી જ કેટલાક સર્વરોને નવા કર્નલમાં સ્થાનાંતરિત કરવામાં વ્યવસ્થાપિત કરી લીધા હતા, અને હવે અમારે શરૂઆતથી જ શરૂ કરવાનું હતું. અમે FragmentSmack ફિક્સની રાહ જોયા વિના કર્નલને શા માટે અપડેટ કર્યું? હકીકત એ છે કે આ નબળાઈઓ સામે રક્ષણ કરવાની પ્રક્રિયા CentOS ને અપડેટ કરવાની પ્રક્રિયા સાથે એકરુપ (અને મર્જ) થઈ (જે માત્ર કર્નલને અપડેટ કરવા કરતાં પણ વધુ સમય લે છે). વધુમાં, SegmentSmack એ વધુ ખતરનાક નબળાઈ છે, અને તેના માટેનો સુધારો તરત જ દેખાયો, તેથી તે કોઈપણ રીતે અર્થપૂર્ણ બન્યું. જો કે, અમે ફક્ત CentOS પર કર્નલને અપડેટ કરી શક્યા નથી કારણ કે FragmentSmack નબળાઈ, જે CentOS 7.5 દરમિયાન દેખાઈ હતી, તે ફક્ત સંસ્કરણ 7.6 માં નિશ્ચિત કરવામાં આવી હતી, તેથી અમારે 7.5 પર અપડેટ બંધ કરવું પડ્યું અને 7.6 પર અપડેટ સાથે ફરીથી પ્રારંભ કરવું પડ્યું. અને આ પણ થાય છે.

બીજું, સમસ્યાઓ વિશેની દુર્લભ વપરાશકર્તા ફરિયાદો અમને પાછી આવી છે. હવે અમે પહેલાથી જ ખાતરીપૂર્વક જાણીએ છીએ કે તે બધા ક્લાયંટ તરફથી અમારા કેટલાક સર્વર પર ફાઇલોના અપલોડ સાથે સંબંધિત છે. તદુપરાંત, કુલ સમૂહમાંથી અપલોડ્સની ખૂબ જ ઓછી સંખ્યા આ સર્વર્સમાંથી પસાર થઈ હતી.

ઉપરની વાર્તામાંથી આપણે યાદ રાખીએ છીએ તેમ, Sysctl ને રોલ બેક કરવાથી મદદ મળી નથી. રીબૂટ મદદ કરી, પરંતુ અસ્થાયી રૂપે.
Sysctl સંબંધિત શંકા દૂર કરવામાં આવી ન હતી, પરંતુ આ વખતે શક્ય તેટલી વધુ માહિતી એકત્રિત કરવી જરૂરી હતી. શું થઈ રહ્યું હતું તે વધુ ચોક્કસ રીતે અભ્યાસ કરવા માટે ક્લાયંટ પર અપલોડ સમસ્યાનું પુનઃઉત્પાદન કરવાની ક્ષમતાનો પણ મોટો અભાવ હતો.

બધા ઉપલબ્ધ આંકડાઓ અને લૉગ્સનું વિશ્લેષણ અમને શું થઈ રહ્યું છે તે સમજવાની નજીક લાવી શક્યું નથી. ચોક્કસ જોડાણને "અનુભૂતિ" કરવા માટે સમસ્યાને પુનઃઉત્પાદિત કરવાની ક્ષમતાનો તીવ્ર અભાવ હતો. અંતે, વિકાસકર્તાઓ, એપ્લિકેશનના વિશિષ્ટ સંસ્કરણનો ઉપયોગ કરીને, Wi-Fi દ્વારા કનેક્ટ થવા પર પરીક્ષણ ઉપકરણ પર સમસ્યાઓનું સ્થિર પ્રજનન પ્રાપ્ત કરવામાં વ્યવસ્થાપિત થયા. તપાસમાં આ એક મોટી સફળતા હતી. Nginx સાથે જોડાયેલ ક્લાયંટ, જે બેકએન્ડ પર પ્રોક્સી કરે છે, જે અમારી Java એપ્લિકેશન હતી.

સમસ્યાઓ માટેનો સંવાદ આના જેવો હતો (Nginx પ્રોક્સી બાજુ પર નિશ્ચિત):

1. ક્લાયન્ટ: ફાઇલ ડાઉનલોડ કરવા વિશે માહિતી મેળવવાની વિનંતી.
2. જાવા સર્વર: પ્રતિભાવ.
3. ક્લાયંટ: ફાઇલ સાથે પોસ્ટ કરો.
4. જાવા સર્વર: ભૂલ.

તે જ સમયે, જાવા સર્વર લોગ પર લખે છે કે ક્લાયંટ પાસેથી 0 બાઇટ્સ ડેટા પ્રાપ્ત થયો હતો, અને Nginx પ્રોક્સી લખે છે કે વિનંતીમાં 30 સેકન્ડથી વધુ સમય લાગ્યો હતો (30 સેકન્ડ એ ક્લાયંટ એપ્લિકેશનનો સમય સમાપ્ત થાય છે). શા માટે સમયસમાપ્તિ અને શા માટે 0 બાઇટ્સ? HTTP પરિપ્રેક્ષ્યમાં, બધું જોઈએ તે પ્રમાણે કાર્ય કરે છે, પરંતુ ફાઇલ સાથેની POST નેટવર્કમાંથી અદૃશ્ય થઈ જાય છે. વધુમાં, તે ક્લાયંટ અને Nginx વચ્ચે અદૃશ્ય થઈ જાય છે. Tcpdump સાથે તમારી જાતને સજ્જ કરવાનો આ સમય છે! પરંતુ પ્રથમ તમારે નેટવર્ક ગોઠવણીને સમજવાની જરૂર છે. Nginx પ્રોક્સી L3 બેલેન્સર પાછળ છે NFware. L3 બેલેન્સરથી સર્વર પર પેકેટો પહોંચાડવા માટે ટનલીંગનો ઉપયોગ થાય છે, જે પેકેટોમાં તેના હેડરો ઉમેરે છે:

આ કિસ્સામાં, નેટવર્ક આ સર્વર પર Vlan-ટેગ કરેલા ટ્રાફિકના રૂપમાં આવે છે, જે પેકેટોમાં તેના પોતાના ફીલ્ડ પણ ઉમેરે છે:

અને આ ટ્રાફિકને પણ ખંડિત કરી શકાય છે (આવતા ફ્રેગમેન્ટેડ ટ્રાફિકની તે જ નાની ટકાવારી કે જેના વિશે અમે વર્કઅરાઉન્ડના જોખમોનું મૂલ્યાંકન કરતી વખતે વાત કરી હતી), જે હેડરની સામગ્રીમાં પણ ફેરફાર કરે છે:

ફરી એકવાર: પેકેટો Vlan ટેગ સાથે સમાવિષ્ટ છે, ટનલ સાથે સમાવિષ્ટ છે, ખંડિત છે. આ કેવી રીતે થાય છે તે વધુ સારી રીતે સમજવા માટે, ચાલો ક્લાયંટથી Nginx પ્રોક્સી સુધીના પેકેટ રૂટને ટ્રેસ કરીએ.

1. પેકેટ L3 બેલેન્સર સુધી પહોંચે છે. ડેટા સેન્ટરમાં યોગ્ય રૂટીંગ માટે, પેકેટને ટનલમાં સમાવીને નેટવર્ક કાર્ડ પર મોકલવામાં આવે છે.
2. પેકેટ + ટનલ હેડરો MTU માં બંધબેસતા ન હોવાથી, પેકેટને ટુકડાઓમાં કાપીને નેટવર્ક પર મોકલવામાં આવે છે.
3. L3 બેલેન્સર પછીની સ્વિચ, જ્યારે પેકેટ મેળવે છે, ત્યારે તેમાં Vlan ટેગ ઉમેરે છે અને તેને મોકલે છે.
4. Nginx પ્રોક્સીની સામેની સ્વિચ (પોર્ટ સેટિંગ્સના આધારે) જુએ છે કે સર્વર Vlan-એન્કેપ્સ્યુલેટેડ પેકેટની અપેક્ષા રાખે છે, તેથી તે Vlan ટૅગને દૂર કર્યા વિના, તેને જેમ છે તેમ મોકલે છે.
5. Linux વ્યક્તિગત પેકેજોના ટુકડાઓ લે છે અને તેમને એક મોટા પેકેજમાં મર્જ કરે છે.
6. આગળ, પેકેટ Vlan ઇન્ટરફેસ પર પહોંચે છે, જ્યાં તેમાંથી પ્રથમ સ્તર દૂર કરવામાં આવે છે - Vlan encapsulation.
7. Linux પછી તેને ટનલ ઈન્ટરફેસ પર મોકલે છે, જ્યાં તેમાંથી અન્ય સ્તર દૂર કરવામાં આવે છે - ટનલ એન્કેપ્સ્યુલેશન.

મુશ્કેલી એ છે કે આ બધું tcpdump માં પરિમાણો તરીકે પસાર કરવું.
ચાલો અંતથી શરૂ કરીએ: શું ક્લાયન્ટના સ્વચ્છ (બિનજરૂરી હેડર વિના) IP પેકેટ છે, જેમાં vlan અને ટનલ એન્કેપ્સ્યુલેશન દૂર કરવામાં આવ્યા છે?

tcpdump host <ip клиента>

ના, સર્વર પર આવા કોઈ પેકેજો નહોતા. તેથી સમસ્યા અગાઉ હોવી જોઈએ. શું ફક્ત Vlan એન્કેપ્સ્યુલેશનવાળા કોઈ પેકેટો દૂર કરવામાં આવ્યા છે?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx એ હેક્સ ફોર્મેટમાં ક્લાયંટનું IP સરનામું છે.
32:4 — ફીલ્ડનું સરનામું અને લંબાઈ જેમાં SCR IP ટનલ પેકેટમાં લખાયેલ છે.

ક્ષેત્રનું સરનામું જડ બળ દ્વારા પસંદ કરવાનું હતું, કારણ કે ઇન્ટરનેટ પર તેઓ લગભગ 40, 44, 50, 54 લખે છે, પરંતુ ત્યાં કોઈ IP સરનામું ન હતું. તમે હેક્સમાંના એક પેકેટને પણ જોઈ શકો છો (tcpdump માં -xx અથવા -XX પેરામીટર) અને તમે જાણો છો તે IP સરનામાની ગણતરી કરી શકો છો.

શું Vlan અને ટનલ એન્કેપ્સ્યુલેશન વગરના પેકેટ ટુકડાઓ દૂર કરવામાં આવ્યા છે?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

આ જાદુ અમને છેલ્લા એક સહિત તમામ ટુકડાઓ બતાવશે. સંભવતઃ, સમાન વસ્તુ આઇપી દ્વારા ફિલ્ટર કરી શકાય છે, પરંતુ મેં પ્રયાસ કર્યો નથી, કારણ કે આવા ઘણા બધા પેકેટો નથી, અને જેની મને જરૂર હતી તે સામાન્ય પ્રવાહમાં સરળતાથી મળી આવ્યા હતા. આ રહ્યા તેઓ:

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 ..............

આ એક ફોટોગ્રાફ સાથેના એક પેકેજ (સમાન ID 53652)ના બે ટુકડા છે (પ્રથમ પેકેજમાં Exif શબ્દ દેખાય છે). હકીકત એ છે કે આ સ્તરે પેકેજો છે, પરંતુ ડમ્પ્સમાં મર્જ કરેલા સ્વરૂપમાં નથી, સમસ્યા એસેમ્બલી સાથે સ્પષ્ટપણે છે. આખરે આના દસ્તાવેજી પુરાવા છે!

પેકેટ ડીકોડરમાં એવી કોઈ સમસ્યા નથી કે જે બિલ્ડને અટકાવે. અહીં પ્રયાસ કર્યો: hpd.gasmi.net. શરૂઆતમાં, જ્યારે તમે ત્યાં કંઈક સ્ટફ કરવાનો પ્રયાસ કરો છો, ત્યારે ડીકોડરને પેકેટ ફોર્મેટ ગમતું નથી. તે બહાર આવ્યું છે કે Srcmac અને Ethertype (ટુકડાની માહિતી સાથે સંબંધિત નથી) વચ્ચે કેટલાક વધારાના બે ઓક્ટેટ હતા. તેમને દૂર કર્યા પછી, ડીકોડર કામ કરવાનું શરૂ કર્યું. જો કે, તેણે કોઈ સમસ્યા દર્શાવી નથી.
ગમે તે કહે, પણ તે Sysctl સિવાય બીજું કંઈ મળ્યું ન હતું. જે બાકી હતું તે સ્કેલને સમજવા અને આગળની ક્રિયાઓ નક્કી કરવા માટે સમસ્યા સર્વરને ઓળખવાનો માર્ગ શોધવાનો હતો. જરૂરી કાઉન્ટર પર્યાપ્ત ઝડપથી મળી આવ્યું:

netstat -s | grep "packet reassembles failed”

તે OID=1.3.6.1.2.1.4.31.1.1.16.1 હેઠળ snmpd માં પણ છે (ipSystemStatsReasmFails).

"IP રી-એસેમ્બલી એલ્ગોરિધમ દ્વારા શોધાયેલ નિષ્ફળતાઓની સંખ્યા (કોઈપણ કારણસર: સમય સમાપ્ત થયો, ભૂલો, વગેરે)."

સર્વર્સના જૂથમાં કે જેના પર સમસ્યાનો અભ્યાસ કરવામાં આવ્યો હતો, બે પર આ કાઉન્ટર ઝડપથી વધ્યું, વધુ બે પર ધીમે ધીમે, અને વધુ બે પર તે બિલકુલ વધ્યું નહીં. જાવા સર્વર પર HTTP ભૂલોની ગતિશીલતા સાથે આ કાઉન્ટરની ગતિશીલતાની તુલના કરવાથી એક સહસંબંધ બહાર આવ્યો. એટલે કે મીટર પર નજર રાખી શકાતી હતી.

સમસ્યાઓનું વિશ્વસનીય સૂચક હોવું ખૂબ જ મહત્વપૂર્ણ છે જેથી તમે ચોક્કસ રીતે નિર્ધારિત કરી શકો કે Sysctl રોલ બેક કરવાથી મદદ મળે છે કે કેમ, કારણ કે અગાઉની વાર્તાથી આપણે જાણીએ છીએ કે એપ્લિકેશનમાંથી આ તરત જ સમજી શકાતું નથી. આ સૂચક અમને વપરાશકર્તાઓને શોધે તે પહેલાં ઉત્પાદનમાં તમામ સમસ્યાવાળા વિસ્તારોને ઓળખવાની મંજૂરી આપશે.
Sysctl ને રોલ બેક કર્યા પછી, મોનિટરિંગ ભૂલો બંધ થઈ ગઈ, આમ સમસ્યાઓનું કારણ સાબિત થયું, તેમજ હકીકત એ છે કે રોલબેક મદદ કરે છે.

અમે અન્ય સર્વર્સ પર ફ્રેગમેન્ટેશન સેટિંગ્સને પાછી ખેંચી છે, જ્યાં નવું મોનિટરિંગ અમલમાં આવ્યું છે, અને કેટલાક સ્થળોએ અમે ટુકડાઓ માટે અગાઉના ડિફોલ્ટ કરતાં પણ વધુ મેમરી ફાળવી છે (આ UDP આંકડા હતા, જેનું આંશિક નુકસાન સામાન્ય સામે ધ્યાનપાત્ર ન હતું. પૃષ્ઠભૂમિ).

સૌથી મહત્વપૂર્ણ પ્રશ્નો

અમારા L3 બેલેન્સર પર પેકેટો શા માટે ખંડિત થાય છે? વપરાશકર્તાઓથી બેલેન્સર સુધી પહોંચતા મોટાભાગના પેકેટો SYN અને ACK છે. આ પેકેજોની સાઈઝ નાની છે. પરંતુ આવા પેકેટોનો હિસ્સો ઘણો મોટો હોવાથી, તેમની પૃષ્ઠભૂમિ સામે અમે મોટા પેકેટોની હાજરી નોંધી નથી જે ટુકડા થવા લાગ્યા.

કારણ તૂટેલી રૂપરેખાંકન સ્ક્રિપ્ટ હતી advmss Vlan ઇન્ટરફેસવાળા સર્વર્સ પર (તે સમયે ઉત્પાદનમાં ટૅગ કરેલા ટ્રાફિકવાળા બહુ ઓછા સર્વર્સ હતા). Advmss અમને ક્લાયન્ટને તે માહિતી પહોંચાડવા માટે પરવાનગી આપે છે કે અમારી દિશામાં પેકેટો કદમાં નાના હોવા જોઈએ જેથી તેમની સાથે ટનલ હેડરો જોડ્યા પછી તેઓને ખંડિત ન થવું પડે.

શા માટે Sysctl રોલબેક મદદ કરતું નથી, પરંતુ રીબૂટ કર્યું? Sysctl ને રોલ બેક કરવાથી પેકેજો મર્જ કરવા માટે ઉપલબ્ધ મેમરીની માત્રા બદલાઈ ગઈ છે. તે જ સમયે, દેખીતી રીતે ટુકડાઓ માટે મેમરી ઓવરફ્લોની ખૂબ જ હકીકત કનેક્શનમાં મંદી તરફ દોરી ગઈ, જેના કારણે ટુકડાઓ કતારમાં લાંબા સમય સુધી વિલંબિત થયા. એટલે કે, પ્રક્રિયા ચક્રમાં ગઈ.
રીબૂટથી મેમરી સાફ થઈ અને બધું ક્રમમાં પાછું આવ્યું.

શું વર્કઅરાઉન્ડ વિના કરવું શક્ય હતું? હા, પરંતુ હુમલાની ઘટનામાં વપરાશકર્તાઓને સેવા વિના છોડી દેવાનું ઉચ્ચ જોખમ છે. અલબત્ત, વર્કઅરાઉન્ડના ઉપયોગથી વપરાશકર્તાઓ માટેની સેવાઓમાંથી એકની મંદી સહિત વિવિધ સમસ્યાઓ આવી, પરંતુ તેમ છતાં અમે માનીએ છીએ કે ક્રિયાઓ ન્યાયી હતી.

આન્દ્રે ટિમોફીવનો ખૂબ ખૂબ આભાર (એટીમોફેયેવ) તપાસ કરવામાં સહાય માટે, તેમજ એલેક્સી ક્રેનેવ (devicex) - સર્વર પર સેન્ટોસ અને કર્નલ્સને અપડેટ કરવાના ટાઇટેનિક કાર્ય માટે. એક પ્રક્રિયા જે આ કિસ્સામાં શરૂઆતથી ઘણી વખત શરૂ કરવી પડી હતી, જેના કારણે તે ઘણા મહિનાઓ સુધી ખેંચાઈ હતી.

સોર્સ: www.habr.com