කාර්යබහුලත්වය ගෙන දෙන දුර්වලතා වලින් පරිස්සම් වන්න. 1 කොටස: FragmentSmack/SegmentSmack

ආයුබෝවන් සියල්ලටම! මගේ නම දිමිත්‍රි සැම්සොනොව්, මම ඔඩ්නොක්ලාස්නිකි හි ප්‍රමුඛ පද්ධති පරිපාලකයෙකු ලෙස සේවය කරමි. අපට භෞතික සේවාදායකයන් 7 දහසකට වඩා, අපගේ වලාකුළේ බහාලුම් 11 දහසක් සහ යෙදුම් 200 ක් ඇත, ඒවා විවිධ වින්‍යාසයන්හි විවිධ පොකුරු 700 ක් සාදයි. සේවාදායකයන්ගෙන් අතිමහත් බහුතරයක් CentOS 7 ධාවනය කරයි.
14 අගෝස්තු 2018 දින, FragmentSmack අවදානම පිළිබඳ තොරතුරු ප්‍රකාශයට පත් කරන ලදී
(CVE-2018-5391) සහ SegmentSmack (CVE-2018-5390) මේවා ජාල ප්‍රහාරක දෛශිකයක් සහ තරමක් ඉහළ ලකුණු (7.5) සමඟ ඇති දුර්වලතා වන අතර, සම්පත් වෙහෙසට පත්වීම (CPU) හේතුවෙන් සේවා ප්‍රතික්ෂේප කිරීම (DoS) තර්ජනය කරයි. FragmentSmack සඳහා කර්නල් නිවැරදි කිරීමක් එකල යෝජනා කර නොතිබුණි; එපමනක් නොව, එය අවදානම පිළිබඳ තොරතුරු ප්‍රකාශයට පත් කිරීමට වඩා බොහෝ පසුව සිදු විය. SegmentSmack ඉවත් කිරීම සඳහා, කර්නලය යාවත්කාලීන කිරීමට යෝජනා කරන ලදී. යාවත්කාලීන පැකේජය එදිනම නිකුත් කරන ලදී, ඉතිරිව ඇත්තේ එය ස්ථාපනය කිරීම පමණි.
නැත, අපි කර්නලය යාවත්කාලීන කිරීමට කිසිසේත් විරුද්ධ නැත! කෙසේ වෙතත්, සූක්ෂ්මතා තිබේ ...

නිෂ්පාදනයේදී අපි කර්නලය යාවත්කාලීන කරන ආකාරය

පොදුවේ, කිසිවක් සංකීර්ණ නොවේ:

1. පැකේජ බාගන්න;
2. සේවාදායකයන් ගණනාවක ඒවා ස්ථාපනය කරන්න (අපගේ වලාකුළු සත්කාරක සේවාදායක ඇතුළුව);
3. කිසිවක් කැඩී නැති බවට වග බලා ගන්න;
4. සියලුම සම්මත කර්නල් සැකසුම් දෝෂයකින් තොරව යොදන බවට වග බලා ගන්න;
5. දින කිහිපයක් ඉන්න;
6. සේවාදායක කාර්ය සාධනය පරීක්ෂා කරන්න;
7. නව සර්වර් යෙදවීම නව කර්නලයට මාරු කරන්න;
8. දත්ත මධ්‍යස්ථානය මගින් සියලුම සේවාදායකයන් යාවත්කාලීන කරන්න (ගැටළු වලදී පරිශීලකයින්ට ඇති බලපෑම අවම කිරීම සඳහා වරකට එක් දත්ත මධ්‍යස්ථානයක්);
9. සියලුම සේවාදායකයන් නැවත ආරම්භ කරන්න.

අප සතුව ඇති කර්නල්වල සියලුම ශාඛා සඳහා නැවත නැවත කරන්න. මේ මොහොතේ එය මෙසේය.

• Stock CentOS 7 3.10 - බොහෝ සාමාන්‍ය සේවාදායකයන් සඳහා;
• වැනිලා 4.19 - අපේ සඳහා එක් වලාකුළු, අපට BFQ, BBR, ආදිය අවශ්‍ය නිසා;
• Elrepo kernel-ml 5.2 - සඳහා අධික ලෙස පටවන ලද බෙදාහරින්නන්, මන්ද 4.19 අස්ථායී ලෙස හැසිරීමට භාවිතා කළ නමුත් එකම විශේෂාංග අවශ්ය වේ.

ඔබ අනුමාන කර ඇති පරිදි, සේවාදායකයන් දහස් ගණනක් නැවත ආරම්භ කිරීම දිගු කාලයක් ගත වේ. සියලුම දුර්වලතා සියලුම සේවාදායකයන් සඳහා තීරණාත්මක නොවන බැවින්, අපි නැවත ආරම්භ කරන්නේ අන්තර්ජාලයෙන් සෘජුවම ප්‍රවේශ විය හැකි ඒවා පමණි. වලාකුළෙහි, නම්‍යශීලීභාවය සීමා නොකිරීමට, අපි නව කර්නලයක් සහිත තනි සේවාදායකයන්ට බාහිරව ප්‍රවේශ විය හැකි බහාලුම් බැඳ නොගනිමු, නමුත් ව්‍යතිරේකයකින් තොරව සියලුම ධාරක නැවත ආරම්භ කරන්න. වාසනාවකට මෙන්, එහි ක්‍රියා පටිපාටිය සාමාන්‍ය සේවාදායකයන්ට වඩා සරල ය. උදාහරණයක් ලෙස, නැවත පණගැන්වීමේදී අස්ථායී බහාලුම් වෙනත් සේවාදායකයකට මාරු කළ හැකිය.

කෙසේ වෙතත්, තවමත් වැඩ ගොඩක් ඇති අතර, එය සති කිහිපයක් ගත විය හැකි අතර, නව අනුවාදය සමඟ ගැටළු තිබේ නම්, මාස කිහිපයක් දක්වා. ප්‍රහාරකයන්ට මෙය හොඳින් වැටහෙන බැවින් ඔවුන්ට B සැලැස්මක් අවශ්‍ය වේ.

FragmentSmack/SegmentSmack. විසඳුම්

වාසනාවකට මෙන්, සමහර දුර්වලතා සඳහා එවැනි සැලැස්මක් B පවතින අතර, එය වැඩමුළුව ලෙස හැඳින්වේ. බොහෝ විට, මෙය කර්නල්/යෙදුම් සැකසුම් වල වෙනසක් වන අතර එමඟින් විය හැකි බලපෑම අවම කිරීමට හෝ අවදානම් සූරාකෑම සම්පූර්ණයෙන්ම ඉවත් කළ හැකිය.

FragmentSmack/SegmentSmack සම්බන්ධයෙන් යෝජනා කරන ලදී මෙම විසඳුම:

«ඔබට net.ipv4.ipfrag_high_thresh සහ net.ipv3.ipfrag_low_thresh හි පෙරනිමි අගයන් 4MB සහ 4MB (සහ ipv6 net.ipv6.ipfrag_high_thresh සහ net.ipv6.ipfrag_low_thresh සහ net.ipv256.ipfrag_low_thresh සහ net.ipv192.ipfrag_low_thresh සඳහා පිළිවෙළින් kB හෝ 262144 kB වෙත) පෙරනිමි අගයන් වෙනස් කළ හැක. පහත් දෘඪාංග, සැකසුම් සහ කොන්දේසි මත පදනම්ව ප්‍රහාරයකදී CPU භාවිතයේ කුඩා හෝ සැලකිය යුතු අඩුවීමක් පරීක්ෂණ මගින් පෙන්වයි. කෙසේ වෙතත්, ipfrag_high_thresh=64 bytes නිසා යම් කාර්ය සාධන බලපෑමක් ඇති විය හැක, මන්ද 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 යෙදීම ප්‍රමාණවත් නොවන්නේ ඇයි? කන්ටේනරය ජීවත් වන්නේ තමන්ගේම කැපවූ ජාලයක් වන Namespace තුළය, එබැවින් අවම වශයෙන් ජාලයේ කොටසක් Sysctl පරාමිති කන්ටේනරය තුළ ධාරකයට වඩා වෙනස් විය හැක.

කන්ටේනරය තුළ Sysctl සැකසුම් හරියටම යොදන්නේ කෙසේද? අපගේ බහාලුම් වරප්‍රසාද නොලබන බැවින්, ඔබට බහාලුම් තුළට යාමෙන් කිසිදු Sysctl සැකසුම් වෙනස් කිරීමට නොහැකි වනු ඇත - ඔබට ප්‍රමාණවත් හිමිකම් නොමැත. බහාලුම් ක්‍රියාත්මක කිරීමට, එකල අපගේ වලාකුළු භාවිතා කළේ ඩොකර් (දැන් පොඩ්මන්) අවශ්‍ය Sysctl සිටුවම් ඇතුළුව නව බහාලුම්වල පරාමිතීන් API හරහා Docker වෙත ලබා දෙන ලදී.
අනුවාද හරහා සෙවීමේදී, Docker 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 පරාමිති යොදන අනුපිළිවෙල Docker සහතික නොකරන බව පෙනී ගියේය (නවතම පරීක්ෂා කරන ලද අනුවාදය 1.13.1), එබැවින් සමහර විට ipfrag_high_thresh ipfrag_low_thresh තවමත් 256M වන විට 3K ලෙස සැකසීමට උත්සාහ කරයි, එනම් ඉහළ සීමාව අඩු විය. දෝෂයට තුඩු දුන් පහළ සීමාවට වඩා.

එම අවස්ථාවේදී, අපි දැනටමත් ආරම්භයෙන් පසු බහාලුම් නැවත සකස් කිරීම සඳහා අපගේම යාන්ත්‍රණයක් භාවිතා කළෙමු (පසුව කන්ටේනරය කැටි කිරීම කණ්ඩායම් ශීතකරණය සහ කන්ටේනරයේ නාම අවකාශයේ විධාන ක්‍රියාත්මක කිරීම හරහා ip netns), සහ අපි මෙම කොටසට Sysctl පරාමිති ලිවීමද එකතු කළෙමු. ප්‍රශ්නය විසඳුනා.

FragmentSmack/SegmentSmack. පළමු රුධිරය 2

ක්ලවුඩ් හි වැඩකටයුතු භාවිතය තේරුම් ගැනීමට අපට කාලය ලැබීමට පෙර, පරිශීලකයින්ගෙන් පළමු දුර්ලභ පැමිණිලි පැමිණීමට පටන් ගත්තේය. ඒ වන විට, පළමු සේවාදායකයේ Workround භාවිතා කිරීම ආරම්භ කර සති කිහිපයක් ගත වී ඇත. මූලික පරීක්ෂණයෙන් පෙන්නුම් කළේ තනි සේවාවන්ට එරෙහිව පැමිණිලි ලැබී ඇති අතර මෙම සේවාවන්හි සියලුම සේවාදායකයන් නොවන බවයි. ගැටලුව නැවතත් අතිශයින්ම අවිනිශ්චිත වී ඇත.

පළමුවෙන්ම, අපි, ඇත්ත වශයෙන්ම, Sysctl සැකසුම් ආපසු හැරවීමට උත්සාහ කළ නමුත්, මෙය කිසිදු බලපෑමක් ඇති කළේ නැත. සේවාදායකය සහ යෙදුම් සැකසුම් සමඟ විවිධ උපාමාරු ද උදව් කළේ නැත. නැවත ආරම්භ කිරීම උදව් විය. ලිනක්ස් නැවත ආරම්භ කිරීම පැරණි දිනවල වින්ඩෝස් සඳහා සාමාන්‍ය දෙයක් වූවා සේම අස්වාභාවික ය. කෙසේ වෙතත්, එය උපකාර වූ අතර, 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 dropped” යනු මෙම උපලේඛකයේ අතහැර දැමූ සියලුම පැකට් වල එකතුවයි. පෝලිමේ දිග 1 දහස දක්වා වැඩි කර කන්ටේනර් නැවත ආරම්භ කිරීමෙන් පසුව, ගැටළුව ඇතිවීම නතර විය. ඔබට නැවත වාඩි වී ස්මූති පානය කළ හැකිය.

FragmentSmack/SegmentSmack. අන්තිම රුධිරය

පළමුවෙන්ම, කර්නලයේ ඇති දුර්වලතා නිවේදනය කිරීමෙන් මාස කිහිපයකට පසු, FragmentSmack සඳහා විසඳුමක් අවසානයේ දර්ශනය විය (අගෝස්තු මාසයේ නිවේදනය සමඟ, SegmentSmack සඳහා පමණක් නිවැරදි කිරීමක් නිකුත් කරන ලද බව මම ඔබට මතක් කරමි), එමඟින් අපට විසඳුම් අත්හැරීමට අවස්ථාවක් ලබා දුන්නේය. එය අපට බොහෝ කරදර ඇති කළේය. මෙම කාලය තුළ, අපි දැනටමත් සමහර සේවාදායකයන් නව කර්නලයට මාරු කිරීමට සමත් වී ඇති අතර දැන් අපට මුල සිටම ආරම්භ කිරීමට සිදු විය. FragmentSmack නිවැරදි කරන තෙක් බලා නොසිට අපි කර්නලය යාවත්කාලීන කළේ ඇයි? කාරණය නම්, මෙම අවදානම් වලින් ආරක්ෂා වීමේ ක්‍රියාවලිය CentOS යාවත්කාලීන කිරීමේ ක්‍රියාවලිය සමඟ (සහ ඒකාබද්ධ වූ) සමපාත විය (එය කර්නලය පමණක් යාවත්කාලීන කිරීමට වඩා වැඩි කාලයක් ගත වේ). ඊට අමතරව, SegmentSmack යනු වඩාත් භයානක අවදානමක් වන අතර, ඒ සඳහා විසඳුමක් වහාම දර්ශනය විය, එබැවින් එය කෙසේ හෝ අර්ථවත් විය. කෙසේ වෙතත්, CentOS 7.5 අතරතුර දර්ශනය වූ FragmentSmack අවදානම 7.6 අනුවාදයේ පමණක් සවි කර ඇති නිසා අපට CentOS හි කර්නලය සරලව යාවත්කාලීන කිරීමට නොහැකි විය, එබැවින් අපට යාවත්කාලීන කිරීම 7.5 දක්වා නවතා 7.6 වෙත යාවත්කාලීන කිරීම සමඟ නැවත ආරම්භ කිරීමට සිදු විය. ඒ වගේම මේකත් වෙනවා.

දෙවනුව, ගැටළු පිළිබඳ දුර්ලභ පරිශීලක පැමිණිලි අප වෙත ආපසු පැමිණ ඇත. ඒවා සියල්ලම සේවාදායකයින්ගෙන් අපගේ සමහර සේවාදායකයන් වෙත ගොනු උඩුගත කිරීමට සම්බන්ධ බව දැන් අපි දැනටමත් නිසැකවම දනිමු. එපමණක් නොව, සම්පූර්ණ ස්කන්ධයෙන් උඩුගත කිරීම් ඉතා කුඩා ප්‍රමාණයක් මෙම සේවාදායකයන් හරහා ගියේය.

ඉහත කතාවෙන් අපට මතක ඇති පරිදි, Sysctl ආපසු හැරවීම උදව් කළේ නැත. නැවත පණගැන්වීම උදව් විය, නමුත් තාවකාලිකව.
Sysctl සම්බන්ධ සැකයන් ඉවත් නොකළ නමුත් මෙවර හැකි තරම් තොරතුරු රැස් කිරීම අවශ්‍ය විය. සිදුවන්නේ කුමක්ද යන්න වඩාත් නිවැරදිව අධ්‍යයනය කිරීම සඳහා සේවාදායකයා මත උඩුගත කිරීමේ ගැටලුව ප්‍රතිනිෂ්පාදනය කිරීමේ හැකියාවේ විශාල අඩුවක් ද විය.

පවතින සියලුම සංඛ්‍යාලේඛන සහ ලඝු-සටහන් විශ්ලේෂණය කිරීමෙන් සිදුවන්නේ කුමක්ද යන්න අවබෝධ කර ගැනීමට අපට සමීප නොවීය. නිශ්චිත සම්බන්ධතාවයක් "දැනීම" සඳහා ගැටළුව ප්රතිනිෂ්පාදනය කිරීමේ හැකියාවෙහි තියුණු හිඟයක් පැවතුනි. අවසාන වශයෙන්, සංවර්ධකයින්, යෙදුමේ විශේෂ අනුවාදයක් භාවිතා කරමින්, Wi-Fi හරහා සම්බන්ධ වූ විට පරීක්ෂණ උපාංගයක ගැටළු ස්ථාවර ලෙස ප්‍රතිනිෂ්පාදනය කිරීමට සමත් විය. මෙය විමර්ශනයේ පෙරළියක් විය. අපගේ ජාවා යෙදුම වූ පසු අන්තයට ප්‍රොක්සි කරන ලද, Nginx වෙත සම්බන්ධ වූ සේවාදායකයා.

ගැටළු සඳහා සංවාදය මේ වගේ විය (Nginx ප්‍රොක්සි පැත්තේ සවි කර ඇත):

1. සේවාදායකයා: ගොනුවක් බාගත කිරීම පිළිබඳ තොරතුරු ලබා ගැනීමට ඉල්ලීම.
2. ජාවා සේවාදායකය: ප්රතිචාරය.
3. සේවාදායකයා: ගොනුව සමඟ POST කරන්න.
4. ජාවා සේවාදායකය: දෝෂයකි.

ඒ අතරම, ජාවා සේවාදායකය සේවාදායකයාගෙන් දත්ත බයිට් 0 ක් ලැබුණු බව ලොගයට ලියන අතර, ඉල්ලීම තත්පර 30 කට වඩා ගත වූ බව Nginx ප්‍රොක්සි ලියයි (තත්පර 30 යනු සේවාදායක යෙදුමේ කල් ඉකුත්වීමයි). කල් ඉකුත්වීම සහ බයිට් 0 ඇයි? HTTP ඉදිරිදර්ශනයකින්, සෑම දෙයක්ම කළ යුතු ආකාරයටම ක්‍රියා කරයි, නමුත් ගොනුව සහිත POST ජාලයෙන් අතුරුදහන් වන බව පෙනේ. එපමණක් නොව, එය සේවාදායකයා සහ Nginx අතර අතුරුදහන් වේ. Tcpdump සමඟ සන්නද්ධ වීමට කාලයයි! නමුත් මුලින්ම ඔබ ජාල වින්යාසය තේරුම් ගත යුතුය. Nginx proxy L3 balancer පිටුපස ඇත NFware. L3 balancer සිට සේවාදායකය වෙත පැකට් ලබා දීමට උමං මාර්ග භාවිතා කරයි, එය පැකට් වලට එහි ශීර්ෂ එකතු කරයි:

මෙම අවස්ථාවෙහිදී, ජාලය Vlan-ටැග් කළ ගමනාගමනයේ ස්වරූපයෙන් මෙම සේවාදායකයට පැමිණේ, එය පැකට් වලට තමන්ගේම ක්ෂේත්‍ර එකතු කරයි:

තවද මෙම ගමනාගමනය ද ඛණ්ඩනය කළ හැකිය (වර්‍යාරවුන්ඩ් වෙතින් අවදානම් තක්සේරු කිරීමේදී අප කතා කළ එම කුඩා ප්‍රතිශතය එන ඛණ්ඩනය වූ ගමනාගමනය), එය ශීර්ෂවල අන්තර්ගතය ද වෙනස් කරයි:

නැවත වරක්: පැකට් Vlan ටැග් එකකින් ආවරණය කර, උමගකින් වට කර, ඛණ්ඩනය කර ඇත. මෙය සිදුවන්නේ කෙසේදැයි වඩා හොඳින් අවබෝධ කර ගැනීම සඳහා, අපි සේවාදායකයාගේ සිට Nginx ප්‍රොක්සිය දක්වා පැකට් මාර්ගය සොයා ගනිමු.

1. පැකට්ටුව L3 balancer වෙත ළඟා වේ. දත්ත මධ්‍යස්ථානය තුළ නිවැරදි මාර්ගගත කිරීම සඳහා, පැකට්ටුව උමගක කොටා ජාල කාඩ්පතට යවනු ලැබේ.
2. පැකට් + උමං ශීර්ෂයන් MTU එකට නොගැලපෙන බැවින්, පැකට්ටුව කැබලිවලට කපා ජාලයට යවනු ලැබේ.
3. L3 balancer එකට පසුව ඇති ස්විචය, පැකට්ටුවක් ලබා ගන්නා විට, එයට Vlan ටැග් එකක් එකතු කර එය යවයි.
4. Nginx ප්‍රොක්සිය ඉදිරිපිට ඇති ස්විචය (වරාය සැකසුම් මත පදනම්ව) සේවාදායකය Vlan-සංවෘත පැකට්ටුවක් අපේක්ෂා කරන බව දකියි, එබැවින් එය Vlan ටැගය ඉවත් නොකර එය යවයි.
5. ලිනක්ස් තනි පැකේජවල කොටස් ගෙන ඒවා එක් විශාල පැකේජයකට ඒකාබද්ධ කරයි.
6. ඊළඟට, පැකට්ටුව Vlan අතුරුමුහුණත වෙත ළඟා වන අතර, එහි පළමු ස්ථරය ඉවත් කරනු ලැබේ - Vlan encapsulation.
7. Linux පසුව එය උමං අතුරුමුහුණත වෙත යවයි, එහිදී තවත් ස්ථරයක් එයින් ඉවත් කරනු ලැබේ - උමං ආවරණය කිරීම.

දුෂ්කරතාවය වන්නේ මේ සියල්ල tcpdump වෙත පරාමිති ලෙස යැවීමයි.
අපි අවසානයෙන් පටන් ගනිමු: vlan සහ උමං ආවරණ ඉවත් කර ඇති, සේවාදායකයින් වෙතින් පිරිසිදු (අනවශ්‍ය ශීර්ෂ නොමැතිව) IP පැකට් තිබේද?

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

නැත, සේවාදායකයේ එවැනි පැකේජ නොතිබුණි. එබැවින් ගැටලුව කලින් විය යුතුය. Vlan encapsulation පමණක් ඉවත් කර ඇති පැකට් තිබේද?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx යනු හෙක්ස් ආකෘතියේ සේවාදායක IP ලිපිනයයි.
32:4 — උමං පැකට්ටුවේ SCR IP ලියා ඇති ක්ෂේත්‍රයේ ලිපිනය සහ දිග.

ක්ෂේත්‍ර ලිපිනය තිරිසන් බලයෙන් තෝරා ගත යුතු විය, මන්ද ඔවුන් අන්තර්ජාලයේ 40, 44, 50, 54 ගැන ලියන නමුත් එහි IP ලිපිනයක් නොතිබුණි. ඔබට හෙක්ස් හි එක් පැකට්ටුවක් (tcpdump හි -xx හෝ -XX පරාමිතිය) දෙස බලා ඔබ දන්නා IP ලිපිනය ගණනය කළ හැකිය.

Vlan සහ Tunnel encapsulation ඉවත් නොකළ පැකට් කොටස් තිබේද?

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

මෙම මැජික් අපට අවසාන කොටස ඇතුළුව සියලුම කොටස් පෙන්වනු ඇත. බොහෝ විට, එකම දේ IP මඟින් පෙරීමට හැකිය, නමුත් මම උත්සාහ කළේ නැත, මන්ද එවැනි පැකට් බොහොමයක් නොමැති අතර මට අවශ්‍ය ඒවා සාමාන්‍ය ප්‍රවාහයෙන් පහසුවෙන් සොයාගත හැකිය. මෙන්න ඒගොල්ලො:

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

මේවා ඡායාරූපයක් සහිත එක් පැකේජයක (එකම හැඳුනුම්පත 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 balancer මත පැකට් ඛණ්ඩනය වන්නේ ඇයි? පරිශීලකයන්ගෙන් සමතුලිත කරන්නන් වෙත පැමිණෙන බොහෝ පැකට් SYN සහ ACK වේ. මෙම පැකේජවල ප්‍රමාණය කුඩා වේ. නමුත් එවැනි පැකට් වල කොටස ඉතා විශාල බැවින්, ඒවායේ පසුබිමට එරෙහිව, කැබලිවලට කැඩීමට පටන් ගත් විශාල පැකට් ඇති බව අපට නොපෙනුණි.

හේතුව කැඩී ගිය වින්‍යාස පිටපතකි advmss Vlan අතුරුමුහුණත් සහිත සේවාදායකයන් මත (එකල නිෂ්පාදනයේ ටැග් කළ ගමනාගමනය සහිත සේවාදායකයන් සිටියේ ඉතා ස්වල්පයකි). Advmss මඟින් අපගේ දිශාවට ඇති පැකට් ප්‍රමාණයෙන් කුඩා විය යුතු බවට තොරතුරු සේවාලාභියාට ලබා දීමට ඉඩ සලසයි, එවිට ඒවාට උමං ශීර්ෂයන් ඇමිණීමෙන් පසු ඒවා ඛණ්ඩනය කිරීමට අවශ්‍ය නොවේ.

Sysctl rollback උදව් නොකළ නමුත් නැවත ආරම්භ කළේ ඇයි? Sysctl ආපසු පෙරළීම පැකේජ ඒකාබද්ධ කිරීම සඳහා පවතින මතක ප්‍රමාණය වෙනස් කළේය. ඒ අතරම, පෙනෙන විදිහට කොටස් සඳහා මතකය පිටාර ගැලීම සම්බන්ධතා මන්දගාමී වීමට හේතු වූ අතර එමඟින් කොටස් පෝලිමේ දිගු කාලයක් ප්‍රමාද වීමට හේතු විය. එනම් ක්‍රියාවලිය චක්‍ර වශයෙන් සිදු විය.
නැවත පණගැන්වීම මතකය ඉවත් කළ අතර සියල්ල පිළිවෙලට ආපසු ගියේය.

විසඳුම් නොමැතිව කළ හැකිද? ඔව්, නමුත් ප්‍රහාරයක් සිදු වූ විට පරිශීලකයින් සේවාව නොමැතිව ඉවත් වීමේ ඉහළ අවදානමක් ඇත. ඇත්ත වශයෙන්ම, වර්‍රවුන්ඩ් භාවිතය පරිශීලකයින් සඳහා වන එක් සේවාවක් මන්දගාමී වීම ඇතුළු විවිධ ගැටළු වලට හේතු විය, නමුත් කෙසේ වෙතත් ක්‍රියාවන් යුක්ති සහගත බව අපි විශ්වාස කරමු.

බොහෝ ස්තූතියි Andrey Timofeev (atimofeyev) විමර්ශනය පැවැත්වීමේ සහාය සඳහා මෙන්ම ඇලෙක්සි ක්‍රෙනෙව් (devicex) - සර්වර් වල සෙන්ටෝස් සහ කර්නල් යාවත්කාලීන කිරීමේ ටයිටැනික් වැඩ සඳහා. මෙම නඩුවේ ආරම්භයේ සිට කිහිප වතාවක් ආරම්භ කළ යුතු ක්රියාවලියක්, එය මාස ගණනාවක් ඇදී ගියේ එබැවිනි.

මූලාශ්රය: www.habr.com