سلام و ټولو ته! زما نوم دیمیتري سامسونوف دی، زه په اوډنوکلاسنیکي کې د سیسټم د مخکښ مدیر په توګه کار کوم. موږ له 7 زرو څخه ډیر فزیکي سرورونه لرو، زموږ په بادل کې 11 زره کانټینرونه او 200 غوښتنلیکونه، کوم چې په مختلفو ترتیبونو کې 700 مختلف کلسترونه جوړوي. د سرورونو ډیری برخه CentOS 7 چلوي.
د اګست په 14، 2018، د FragmentSmack زیانمننې په اړه معلومات خپاره شول
() او SegmentSmack (). دا د شبکې برید ویکتور او په کافي اندازه لوړې نمرې (7.5) سره زیانمنونکي دي ، کوم چې د سرچینو د ختمیدو (CPU) له امله د خدماتو انکار (DoS) ګواښوي. د FragmentSmack لپاره د کرنل فکس په هغه وخت کې وړاندیز شوی نه و؛ سربیره پردې، دا د زیان مننې په اړه د معلوماتو خپرولو څخه ډیر وروسته راپورته شو. د SegmentSmack له منځه وړلو لپاره، دا وړاندیز شوی و چې د کرنل تازه کړي. د اوسمهال کڅوړه پخپله په ورته ورځ خپره شوې وه، ټول هغه څه چې پاتې وو د نصبولو لپاره وو.
نه، موږ په هیڅ ډول د کرنل تازه کولو مخالف نه یو! په هرصورت، دلته باریکونه شتون لري ...
څنګه موږ په تولید کې دانه تازه کوو
په عموم کې، هیڅ شی پیچلی نه دی:
- کڅوړې ډاونلوډ کړئ؛
- دا په یو شمیر سرورونو کې نصب کړئ (د سرورونو په شمول زموږ د بادل کوربه کول)؛
- ډاډ ترلاسه کړئ چې هیڅ شی مات شوی نه وي؛
- ډاډ ترلاسه کړئ چې ټول معیاري کرنل تنظیمات پرته له خطا پلي کیږي؛
- څو ورځې انتظار وکړئ؛
- د سرور فعالیت چیک کړئ؛
- د نوي سرورونو ځای پرځای کول نوي کرنل ته؛
- د ډیټا مرکز لخوا ټول سرورونه تازه کړئ (په یو وخت کې یو ډیټا مرکز د ستونزو په صورت کې په کاروونکو باندې اغیز کمولو لپاره)؛
- ټول سرورونه ریبوټ کړئ.
د دانه ټولو څانګو لپاره تکرار کړئ چې موږ یې لرو. دا مهال دا دی:
- سټاک CentOS 7 3.10 - د ډیری منظم سرورونو لپاره؛
- وینیلا 4.19 - زموږ لپاره ځکه چې موږ BFQ، BBR او داسې نور ته اړتیا لرو؛
- Elrepo kernel-ml 5.2 - لپاره ، ځکه چې 4.19 بې ثباته چلند کاوه ، مګر ورته ځانګړتیاو ته اړتیا ده.
لکه څنګه چې تاسو اټکل کړی وي، د زرګونو سرورونو ریبوټ کول خورا اوږد وخت نیسي. ځکه چې ټولې زیانمننې د ټولو سرورونو لپاره مهم ندي، موږ یوازې هغه ریبوټ کوو چې د انټرنیټ څخه مستقیم لاسرسی لري. په کلاوډ کې، د دې لپاره چې انعطاف محدود نه کړو، موږ د نوي کرنل سره انفرادي سرورونو ته د بهرني لاسرسي وړ کانټینرونه نه وتړو، مګر ټول کوربه پرته له استثنا څخه ریبوټ کوو. خوشبختانه، هلته پروسیجر د منظم سرورونو په پرتله ساده دی. د مثال په توګه ، بې ریاسته کانټینرونه کولی شي په ساده ډول د ریبوټ پرمهال بل سرور ته لاړ شي.
په هرصورت، لاهم ډیر کار شتون لري، او دا څو اونۍ وخت نیسي، او که چیرې د نوي نسخې سره کومه ستونزه وي، تر څو میاشتو پورې. برید کوونکي پدې ښه پوهیږي، نو دوی یو پلان B ته اړتیا لري.
FragmentSmack/SegmentSmack. د کار چاره
خوشبختانه، د ځینو زیان منونکو لپاره دا ډول پالن B شتون لري، او دا د کار کولو په نوم یادیږي. ډیری وختونه، دا د کرنل / غوښتنلیک ترتیباتو کې بدلون دی چې کولی شي ممکنه اغیزه کمه کړي یا په بشپړه توګه د زیانونو استخراج له منځه یوسي.
د FragmentSmack/SegmentSmack په صورت کې دا د حل لاره:
«تاسو کولی شئ د 4MB او 3MB ډیفالټ ارزښتونه په net.ipv4.ipfrag_high_thresh او net.ipv4.ipfrag_low_thresh (او د ipv6 net.ipv6.ipfrag_high_thresh او net.ipv6.ipfrag_low_thresh او net.ipv256.ipfrag_low_thresh لپاره د دوی همکاران) کې بدل کړئ یا په درناوي kB192 kB262144. ښکته ازموینې د هارډویر ، تنظیماتو او شرایطو پورې اړه لري د برید پرمهال د CPU کارولو کې کوچني څخه تر پام وړ کمښت ښیې. په هرصورت، ممکن د ipfrag_high_thresh=64 بایټس له امله د فعالیت اغیزې شتون ولري، ځکه چې یوازې دوه 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 هیڅ ترتیب بدل کړئ - تاسو په ساده ډول کافي حقونه نلرئ. د کانټینرونو چلولو لپاره ، زموږ بادل په هغه وخت کې ډاکر کارولی (اوس ). د نوي کانټینر پیرامیټونه د API له لارې ډاکر ته لیږدول شوي، په شمول د اړین Sysctl ترتیبات.
پداسې حال کې چې د نسخو له لارې لټون کول، دا معلومه شوه چې د ډاکر 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 ترتیبات بیرته راوباسي، مګر دا هیڅ اغیزه ونلري. د سرور او غوښتنلیک تنظیماتو سره مختلف لاسوهنې هم مرسته ونه کړه. ریبوټ مرسته وکړه. د لینکس ریبوټ کول هغومره غیر طبیعي دي لکه څنګه چې په پخوانیو ورځو کې د وینډوز لپاره عادي و. سره له دې، دا مرسته وکړه، او موږ دا د "کرنل خرابۍ" ته پورته کړه کله چې په Sysctl کې نوي ترتیبات پلي کول. څومره بې ځایه وه...
درې اونۍ وروسته ستونزه بیا تکرار شوه. د دې سرورونو ترتیب خورا ساده و: نګینکس په پراکسي / بیلانس حالت کې. ډیر ترافیک نه. نوې ابتدايي یادونه: د پیرودونکو په اړه د 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 له لارې وصل وي. دا په تحقیقاتو کې یو پرمختګ و. پیرودونکی د نګینکس سره وصل شوی ، کوم چې د شالید سره پراکسي شوی ، کوم چې زموږ د جاوا غوښتنلیک و.
د ستونزو لپاره خبرې اترې داسې وې (د نګینکس پراکسي اړخ کې ټاکل شوی):
- پیرودونکي: د فایل ډاونلوډ کولو په اړه د معلوماتو ترلاسه کولو غوښتنه وکړئ.
- جاوا سرور: ځواب.
- پیرودونکي: د فایل سره پوسټ کړئ.
- جاوا سرور: تېروتنه.
په ورته وخت کې ، د جاوا سرور لاګ ته لیکي چې د پیرودونکي څخه 0 بایټ ډیټا ترلاسه شوي ، او نګینکس پراکسي لیکي چې غوښتنې له 30 ثانیو څخه ډیر وخت نیولی (30 ثانیې د پیرودونکي غوښتنلیک وخت پای دی). ولې مهال ویش او ولې 0 بایټس؟ د HTTP له نظره، هرڅه لکه څنګه چې باید کار وکړي، مګر د فایل سره POST داسې ښکاري چې له شبکې څخه ورک شي. سربیره پردې ، دا د پیرودونکي او نګینکس ترمینځ ورک کیږي. دا وخت دی چې خپل ځان د Tcpdump سره سمبال کړئ! مګر لومړی تاسو اړتیا لرئ د شبکې تنظیمات پوه شئ. نګینکس پراکسي د L3 بیلانس تر شا دی . تونل کول د L3 بیلانس څخه سرور ته د کڅوړو رسولو لپاره کارول کیږي، کوم چې خپل سرلیکونه پاکټونو ته اضافه کوي:
په دې حالت کې، شبکه دې سرور ته د Vlan-ټاګ شوي ټرافیک په بڼه راځي، کوم چې په پیکټونو کې خپلې ساحې هم اضافه کوي:
او دا ټرافیک هم ټوټه ټوټه کیدی شي (د راتلونکو ټوټې شوي ټرافیک ډیره لږه سلنه چې موږ یې په اړه خبرې وکړې کله چې د Workaround څخه خطرونه ارزول)، کوم چې د سرلیکونو مینځپانګه هم بدلوي:
یوځل بیا: پاکټونه د Vlan ټګ سره پوښل شوي ، د تونل سره پوښل شوي ، ټوټې شوي. د ښه پوهیدو لپاره چې دا څنګه پیښیږي ، راځئ چې د پیرودونکي څخه نګینکس پراکسي ته د پاکټ لاره تعقیب کړو.
- کڅوړه د L3 بیلانسر ته رسیږي. د معلوماتو مرکز کې د سمې لارې کولو لپاره، کڅوړه په تونل کې پوښل کیږي او د شبکې کارت ته لیږل کیږي.
- څرنګه چې د پیکټ + تونل سرلیکونه په MTU کې مناسب نه دي، پیکټ په ټوټو ویشل کیږي او شبکې ته لیږل کیږي.
- د L3 بیلانسر وروسته سویچ، کله چې پاکټ ترلاسه کوي، د Vlan ټاګ اضافه کوي او دا یې لیږي.
- د نګینکس پراکسي مخې ته سویچ لیدل کیږي (د پورټ تنظیماتو پراساس) چې سرور د Vlan-encapsulated پاکټ په تمه دی ، نو دا د Vlan ټاګ لرې کولو پرته ورته لیږي.
- لینکس د انفرادي کڅوړو ټوټې اخلي او په یوه لوی کڅوړه کې یې یوځای کوي.
- بیا ، کڅوړه د Vlan انٹرفیس ته رسي ، چیرې چې لومړی پرت له هغې څخه لرې کیږي - Vlan encapsulation.
- لینکس بیا دا د تونل انٹرفیس ته لیږي ، چیرې چې بل پرت له هغې څخه لرې کیږي - د تونل انکیپسولیشن.
مشکل دا دی چې دا ټول د پیرامیټونو په توګه tcpdump ته انتقال کړئ.
راځئ چې له پای څخه پیل وکړو: ایا د پیرودونکو څخه پاک (د غیر ضروري سرلیکونو پرته) IP پاکټونه شتون لري ، د vlan او تونل انکیپسولیشن لرې کولو سره؟
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 او تونل انکیپسولیشن پرته د پاکټ ټوټې شتون لري؟
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 ..............
دا د یوې کڅوړې دوه ټوټې دي (د ورته ID 53652) عکس سره (د Exif کلمه په لومړۍ کڅوړه کې لیدل کیږي). د دې حقیقت له امله چې پدې کچه کڅوړې شتون لري ، مګر په ډمپونو کې په ضمیمه شوي شکل کې ندي ، ستونزه په واضح ډول د مجلس سره ده. په نهایت کې د دې سند اسناد شتون لري!
د پاکټ ډیکوډر کومه ستونزه نه وه ښکاره کړې چې د جوړولو مخه ونیسي. دلته یې هڅه وکړه: . په لومړي سر کې، کله چې تاسو هڅه وکړئ هلته یو څه ډک کړئ، ډیکوډر د پاکټ بڼه نه خوښوي. دا معلومه شوه چې د Srcmac او Ethertype ترمنځ ځینې اضافي دوه آکټیټونه شتون لري (د ټوټې معلوماتو سره تړاو نلري). د دوی د لرې کولو وروسته، کوډ کوونکی کار پیل کړ. په هرصورت، دا کومه ستونزه نه وه ښودلې.
هر څه چې ووایې، پرته له دې سیسټل څخه بل څه ونه موندل شول. ټول هغه څه چې پاتې وو د ستونزې د سرورونو پیژندلو لپاره د یوې لارې موندل و ترڅو په پیمانه پوه شي او د نورو کړنو په اړه پریکړه وکړي. اړین کاونټر په چټکۍ سره وموندل شو:
netstat -s | grep "packet reassembles failed”
دا د OID=1.3.6.1.2.1.4.31.1.1.16.1 لاندې snmpd کې هم دی ().
"د IP بیا اسمبلۍ الګوریتم لخوا کشف شوي د ناکامیو شمیر (د هر دلیل لپاره: وخت پای ته رسیدلی ، غلطۍ ، او داسې نور)."
د سرورونو د ډلې په مینځ کې چې ستونزه یې مطالعه شوې ، دا کاونټر په دوه باندې ګړندی وده وکړه ، په دوه باندې ورو او په دوه باندې هیڅ نه وده وکړه. په جاوا سرور کې د HTTP غلطیو متحرکاتو سره د دې کاونټر متحرکات پرتله کول یو ارتباط څرګند کړ. دا دی، میټر څارنه کیدی شي.
د ستونزو د باور وړ شاخص درلودل خورا مهم دي نو تاسو کولی شئ په سمه توګه وټاکئ چې ایا د Sysctl بیرته راګرځول مرسته کوي، ځکه چې د تیرې کیسې څخه موږ پوهیږو چې دا د غوښتنلیک څخه سمدلاسه نه پوهیږي. دا شاخص به موږ ته اجازه راکړي چې په تولید کې ټولې ستونزې سیمې وپیژنو مخکې لدې چې کاروونکي یې ومومي.
د Sysctl بیرته راګرځولو وروسته، د څارنې تېروتنې ودرول شوې، پدې توګه د ستونزو لامل ثابت شوی، او همدارنګه دا حقیقت چې رول بیک مرسته کوي.
موږ په نورو سرورونو کې د ټوټې کولو تنظیمات بیرته راوګرځول، چیرې چې نوې څارنه پیل شوه، او چیرته چې موږ د پخوانیو ډیفالټ په پرتله د ټوټو لپاره حتی ډیر حافظه تخصیص کړه (دا د UDP احصایې وې، چې د عمومي شالید په وړاندې د پام وړ نه و) .
تر ټولو مهمې پوښتنې
ولې زموږ په L3 بیلنسر کې کڅوړې ټوټې شوې؟ ډیری پاکټونه چې د کاروونکو څخه بیلانسر ته راځي SYN او ACK دي. د دې کڅوړو اندازه کوچنۍ ده. مګر څنګه چې د دې ډول کڅوړو برخه خورا لویه ده، د دوی د شالید په مقابل کې موږ د لویو کڅوړو شتون نه و لیدلی چې ټوټه ټوټه پیل شوه.
لامل د مات شوي ترتیب سکریپټ و په سرورونو کې د Vlan انٹرفیس سره (په هغه وخت کې په تولید کې د ټګ شوي ترافیک سره خورا لږ سرورونه وو). Advmss موږ ته اجازه راکوي چې پیرودونکي ته هغه معلومات وړاندې کړو چې زموږ په لور کې پاکټونه باید په اندازې کې کوچني وي ترڅو دوی ته د تونل سرلیکونو ضمیمه کولو وروسته دوی ټوټه ټوټه نشي.
ولې د Sysctl رول بیک مرسته ونه کړه، مګر ریبوټ یې وکړ؟ د Sysctl بیرته راګرځول د ضم کولو کڅوړو لپاره د موجود حافظې مقدار بدل کړ. په ورته وخت کې، په ښکاره ډول د ټوټو لپاره د حافظې ډیریدو حقیقت د اتصال ورو کیدو لامل شوی ، کوم چې د دې لامل شوی چې ټوټې په کتار کې د اوږدې مودې لپاره وځنډول شي. دا، پروسه په دوره کې روانه وه.
ریبوټ حافظه پاکه کړه او هرڅه بیرته ترتیب ته راستون شول.
ایا دا ممکنه وه چې پرته له کار څخه کار واخیستل شي؟ هو، مګر د برید په صورت کې د خدماتو پرته د کاروونکو پریښودلو لوړ خطر شتون لري. البته، د کاري حل کارول د مختلفو ستونزو لامل شوي، په شمول د کاروونکو لپاره د یو خدماتو سست کول، مګر بیا هم موږ باور لرو چې کړنې توجیه شوي.
له اندری تیموفیف څخه ډیره مننه (د تحقیقاتو په ترسره کولو کې د مرستې لپاره، او همدارنګه الیکسي کرینیف () - په سرورونو کې د سینټوس او کرنل تازه کولو د ټایټانیک کار لپاره. یوه پروسه چې په دې حالت کې باید له پیل څخه څو ځله پیل شي، له همدې امله دا د ډیرو میاشتو لپاره ودرول شوه.
سرچینه: www.habr.com