სიფრთხილით მოვეკიდოთ მოწყვლადობას, რომელიც იწვევს სამუშაოს. ნაწილი 1: FragmentSmack/SegmentSmack

გამარჯობა ყველას! მე მქვია დიმიტრი სამსონოვი და ვმუშაობ Odnoklassniki-ში წამყვან სისტემურ ადმინისტრატორად. ჩვენ გვაქვს 7-ზე მეტი ფიზიკური სერვერი, 11 კონტეინერი ჩვენს ღრუბელში და 200 აპლიკაცია, რომლებიც სხვადასხვა კონფიგურაციაში ქმნიან 700 სხვადასხვა კლასტერს. სერვერების დიდი უმრავლესობა მუშაობს CentOS 7.
14 წლის 2018 აგვისტოს გამოქვეყნდა ინფორმაცია FragmentSmack დაუცველობის შესახებ
(CVE-2018-5391) და SegmentSmack (CVE-2018-5390). ეს არის დაუცველობა ქსელის შეტევის ვექტორით და საკმაოდ მაღალი ქულით (7.5), რაც საფრთხეს უქმნის სერვისზე უარის თქმას (DoS) რესურსების ამოწურვის გამო (CPU). იმ დროისთვის FragmentSmack-ისთვის ბირთვის შესწორება არ იყო შემოთავაზებული, უფრო მეტიც, ის გაცილებით გვიან გამოჩნდა, ვიდრე დაუცველობის შესახებ ინფორმაციის გამოქვეყნება. SegmentSmack-ის აღმოსაფხვრელად, შემოთავაზებული იყო ბირთვის განახლება. თავად განახლების პაკეტი გამოვიდა იმავე დღეს, დარჩა მხოლოდ მისი დაყენება.
არა, ჩვენ საერთოდ არ ვართ წინააღმდეგი ბირთვის განახლების! თუმცა არის ნიუანსები...

როგორ ვაახლებთ ბირთვს წარმოებაზე

ზოგადად, არაფერი რთული:

1. ჩამოტვირთეთ პაკეტები;
2. დააინსტალირეთ ისინი რამდენიმე სერვერზე (მათ შორის სერვერებზე, რომლებიც მასპინძლობენ ჩვენს ღრუბელს);
3. დარწმუნდით, რომ არაფერი გატეხილია;
4. დარწმუნდით, რომ ბირთვის ყველა სტანდარტული პარამეტრი გამოიყენება შეცდომების გარეშე;
5. დაელოდეთ რამდენიმე დღე;
6. შეამოწმეთ სერვერის შესრულება;
7. ახალი სერვერების განლაგების გადართვა ახალ ბირთვზე;
8. განაახლეთ ყველა სერვერი მონაცემთა ცენტრის მიხედვით (თითოჯერადი მონაცემთა ცენტრი, რათა მინიმუმამდე დაიყვანოთ გავლენა მომხმარებლებზე პრობლემების შემთხვევაში);
9. გადატვირთეთ ყველა სერვერი.

გაიმეორეთ ბირთვების ყველა ტოტისთვის, რაც გვაქვს. ამ დროისთვის არის:

• საფონდო CentOS 7 3.10 - უმეტესი ჩვეულებრივი სერვერებისთვის;
• ვანილი 4.19 - ჩვენთვის ერთ ღრუბლიანი ღრუბლები, რადგან გვჭირდება BFQ, BBR და ა.შ.;
• Elrepo kernel-ml 5.2 - for ძალიან დატვირთული დისტრიბუტორები, რადგან ადრე 4.19 არასტაბილურად იქცეოდა, მაგრამ იგივე მახასიათებლებია საჭირო.

როგორც თქვენ ალბათ მიხვდით, ათასობით სერვერის გადატვირთვას ყველაზე დიდი დრო სჭირდება. ვინაიდან ყველა დაუცველობა არ არის კრიტიკული ყველა სერვერისთვის, ჩვენ მხოლოდ გადატვირთეთ ისინი, რომლებიც პირდაპირ ხელმისაწვდომია ინტერნეტიდან. ღრუბელში, იმისათვის, რომ არ შევზღუდოთ მოქნილობა, ჩვენ არ ვამაგრებთ გარედან ხელმისაწვდომ კონტეინერებს ცალკეულ სერვერებს ახალი ბირთვით, მაგრამ გადატვირთეთ ყველა ჰოსტი გამონაკლისის გარეშე. საბედნიეროდ, იქ პროცედურა უფრო მარტივია, ვიდრე ჩვეულებრივ სერვერებზე. მაგალითად, მოქალაქეობის არმქონე კონტეინერებს შეუძლიათ გადატვირთვისას უბრალოდ გადავიდნენ სხვა სერვერზე.

თუმცა, ჯერ კიდევ ბევრია სამუშაო და ამას შეიძლება რამდენიმე კვირა დასჭირდეს, ხოლო თუ რაიმე პრობლემა შეექმნა ახალ ვერსიას, რამდენიმე თვემდე. თავდამსხმელებს ეს ძალიან კარგად ესმით, ამიტომ მათ სჭირდებათ გეგმა B.

FragmentSmack/SegmentSmack. Გარშემო მუშაობა

საბედნიეროდ, ზოგიერთი დაუცველობისთვის ასეთი გეგმა B არსებობს და მას Workaround ეწოდება. ყველაზე ხშირად, ეს არის ბირთვის/აპლიკაციის პარამეტრების ცვლილება, რამაც შეიძლება შეამციროს შესაძლო ეფექტი ან მთლიანად აღმოფხვრას დაუცველობათა ექსპლუატაცია.

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) და შესაბამისად 256 kB192-ით. ქვედა. ტესტები აჩვენებენ მცირე და მნიშვნელოვან ვარდნას CPU-ს გამოყენებაში შეტევის დროს, რაც დამოკიდებულია აპარატურაზე, პარამეტრებზე და პირობებზე. თუმცა, შეიძლება გარკვეული გავლენა იქონიოს შესრულებაზე ipfrag_high_thresh=262144 ბაიტის გამო, რადგან მხოლოდ ორი 64K ფრაგმენტი შეიძლება მოთავსდეს ხელახლა შეკრების რიგში ერთდროულად. მაგალითად, არსებობს იმის რისკი, რომ აპლიკაციები, რომლებიც მუშაობენ დიდ 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 პარამეტრი თავად კონტეინერში შესვლით - უბრალოდ არ გაქვთ საკმარისი უფლებები. კონტეინერების გასაშვებად, იმ დროს ჩვენი ღრუბელი იყენებდა Docker-ს (ახლა პოდმანი). ახალი კონტეინერის პარამეტრები გადაეცა Docker-ს API-ით, მათ შორის აუცილებელი Sysctl პარამეტრები.
ვერსიების ძიებისას აღმოჩნდა, რომ 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.

პარამეტრის მნიშვნელობა არასწორია. Მაგრამ რატომ? და რატომ არ მოქმედებს მხოლოდ ხანდახან? აღმოჩნდა, რომ Docker არ იძლევა გარანტიას Sysctl პარამეტრების გამოყენების თანმიმდევრობით (უახლესი გამოცდილი ვერსიაა 1.13.1), ამიტომ ზოგჯერ ipfrag_high_thresh ცდილობდა დაეყენებინა 256K, როდესაც ipfrag_low_thresh ჯერ კიდევ 3M იყო, ანუ ზედა ზღვარი უფრო დაბალი იყო. ვიდრე ქვედა ზღვარი, რამაც შეცდომა გამოიწვია.

იმ დროს ჩვენ უკვე გამოვიყენეთ საკუთარი მექანიზმი კონტეინერის დაწყების შემდეგ ხელახალი კონფიგურაციისთვის (კონტეინერის გაყინვა შემდეგ ჯგუფური საყინულე და ბრძანებების შესრულება კონტეინერის სახელთა სივრცეში მეშვეობით ip netns), და ამ ნაწილს დავამატეთ Sysctl პარამეტრების ჩაწერა. პრობლემა მოგვარდა.

FragmentSmack/SegmentSmack. პირველი სისხლი 2

სანამ ჩვენ გვქონდა დრო, რომ გაგვეგო Workaround-ის გამოყენება ღრუბელში, მომხმარებელთაგან პირველი იშვიათი საჩივრები დაიწყო. იმ დროს რამდენიმე კვირა გავიდა პირველ სერვერებზე Workaround-ის გამოყენების დაწყებიდან. თავდაპირველმა გამოძიებამ აჩვენა, რომ საჩივრები მიიღეს ცალკეულ სერვისებზე და არა ამ სერვისების ყველა სერვერზე. პრობლემა კვლავ უკიდურესად გაურკვეველი გახდა.

პირველ რიგში, ვცადეთ Sysctl პარამეტრების უკან დაბრუნება, მაგრამ ამან შედეგი არ გამოიღო. სერვერისა და აპლიკაციის პარამეტრების სხვადასხვა მანიპულაციამაც არ უშველა. გადატვირთვამ უშველა. გადატვირთვა... Linux ისეთივე არაბუნებრივი, როგორც ნორმალური პირობა იყო მუშაობისთვის Windows ძველად. თუმცა, მუშაობდა და Sysctl-ის ახალი პარამეტრების გამოყენებისას ამას „ბირთვული შეცდომით“ მივაწერდით. რა სულელური იყო ჩვენი მხრიდან...

სამი კვირის შემდეგ პრობლემა განმეორდა. ამ სერვერების კონფიგურაცია საკმაოდ მარტივი იყო: Nginx პროქსი/ბალანსერის რეჟიმში. არ არის ბევრი ტრაფიკი. ახალი შესავალი შენიშვნა: კლიენტებზე 504 შეცდომის რიცხვი ყოველდღიურად იზრდება (კარიბჭის დროის ამოწურვა). გრაფიკი აჩვენებს 504 შეცდომის რაოდენობას დღეში ამ სერვისისთვის:

ყველა შეცდომა დაახლოებით ერთი და იგივე უკანა ნაწილია - დაახლოებით ის, რაც ღრუბელშია. მეხსიერების მოხმარების გრაფიკი პაკეტის ფრაგმენტებისთვის ამ backend-ზე ასე გამოიყურებოდა:

ეს არის პრობლემის ერთ-ერთი ყველაზე აშკარა გამოვლინება ოპერაციული სისტემის გრაფიკებში. ღრუბელში, ამავე დროს, მოგვარდა კიდევ ერთი ქსელის პრობლემა QoS (Traffic Control) პარამეტრებთან დაკავშირებით. პაკეტის ფრაგმენტებისთვის მეხსიერების მოხმარების გრაფიკზე ზუსტად იგივე ჩანდა:

ვარაუდი მარტივი იყო: თუ ისინი ერთნაირად გამოიყურებიან გრაფიკებზე, მაშინ მათ აქვთ იგივე მიზეზი. უფრო მეტიც, ამ ტიპის მეხსიერების პრობლემები ძალზე იშვიათია.

გამოსწორებული პრობლემის არსი ის იყო, რომ ჩვენ გამოვიყენეთ fq პაკეტის გრაფიკი ნაგულისხმევი პარამეტრებით QoS-ში. ნაგულისხმევად, ერთი კავშირისთვის, ის საშუალებას გაძლევთ დაამატოთ 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-ის გამოსწორება (გახსოვდეთ, აგვისტოს განცხადებაში მხოლოდ SegmentSmack-ის გამოსწორება გამოქვეყნდა), რამაც საშუალება მოგვცა, უარი გვეთქვა Workaround-ზე, რამაც საკმაოდ დიდი პრობლემები შეგვიქმნა. ამ დროის განმავლობაში ჩვენ უკვე გადავიტანეთ რამდენიმე სერვერი ახალ ბირთვზე და ახლა ნულიდან უნდა დაგვეწყო. რატომ განვაახლეთ ბირთვი FragmentSmack-ის გამოსწორების მოლოდინის გარეშე? ფაქტია, რომ ამ დაუცველობებისგან დაცვის პროცესი დაემთხვა (და შეერწყა) თავად Workaround-ის განახლების პროცესს. CentOS (რაც მხოლოდ ბირთვის განახლებაზე მეტ დროს მოითხოვს). გარდა ამისა, SegmentSmack უფრო საშიში დაუცველობაა და მისი გამოსწორება მაშინვე იყო ხელმისაწვდომი, ამიტომ ეს აზრიანი იყო. თუმცა, უბრალოდ ბირთვის განახლება CentOS ჩვენ არ შეგვეძლო FragmentSmack დაუცველობის გამო, რომელიც გამოჩნდა CentOS 7.5 ვერსია მხოლოდ 7.6-ში გამოსწორდა, ამიტომ 7.5 ვერსიაზე განახლების შეჩერება და 7.6-ზე განახლების თავიდან დაწყება მოგვიწია. ესეც ხდება.

მეორეც, მომხმარებელთა იშვიათი საჩივრები პრობლემების შესახებ დაგვიბრუნდა. ახლა უკვე დანამდვილებით ვიცით, რომ ეს ყველაფერი დაკავშირებულია კლიენტებიდან ფაილების ჩვენს ზოგიერთ სერვერზე ატვირთვასთან. უფრო მეტიც, ატვირთვების ძალიან მცირე რაოდენობა მთლიანი მასიდან გავიდა ამ სერვერებზე.

როგორც ზემოთ მოთხრობიდან გვახსოვს, Sysctl-ის უკან დაბრუნება არ უშველა. გადატვირთვა დაეხმარა, მაგრამ დროებით.
Sysctl-თან დაკავშირებით ეჭვი არ მოიხსნა, მაგრამ ამჯერად საჭირო იყო რაც შეიძლება მეტი ინფორმაციის შეგროვება. ასევე დიდი ნაკლებობა იყო კლიენტზე ატვირთვის პრობლემის რეპროდუცირების უნარი, რათა უფრო ზუსტად შეესწავლათ რა ხდებოდა.

ყველა არსებული სტატისტიკისა და ჟურნალის ანალიზმა არ მიგვიყვანა უფრო ახლოს იმის გაგებასთან, თუ რა ხდებოდა. იყო პრობლემის რეპროდუცირების უნარის მწვავე ნაკლებობა კონკრეტული კავშირის „შეგრძნების“ მიზნით. საბოლოოდ, დეველოპერებმა, აპლიკაციის სპეციალური ვერსიის გამოყენებით, შეძლეს მიაღწიონ პრობლემების სტაბილურ რეპროდუცირებას სატესტო მოწყობილობაზე Wi-Fi-ით დაკავშირებისას. ეს იყო გარღვევა გამოძიებაში. კლიენტი დაუკავშირდა Nginx-ს, რომელიც პროქსი იყო ბექენდთან, რომელიც იყო ჩვენი Java აპლიკაცია.

პრობლემების დიალოგი ასეთი იყო (დაფიქსირდა Nginx პროქსის მხარეს):

1. კლიენტი: მოითხოვეთ ინფორმაციის მიღება ფაილის ჩამოტვირთვის შესახებ.
2. Java სერვერი: პასუხი.
3. კლიენტი: POST ფაილით.
4. Java სერვერი: შეცდომა.

ამავდროულად, Java სერვერი წერს ჟურნალში, რომ კლიენტისგან მიღებულია 0 ბაიტი მონაცემები, ხოლო Nginx პროქსი წერს, რომ მოთხოვნას დასჭირდა 30 წამზე მეტი (30 წამი არის კლიენტის აპლიკაციის დრო). რატომ არის დრო და რატომ 0 ბაიტი? HTTP პერსპექტივიდან, ყველაფერი მუშაობს ისე, როგორც უნდა, მაგრამ POST ფაილთან ერთად, როგორც ჩანს, ქსელიდან ქრება. უფრო მეტიც, ის ქრება კლიენტსა და Nginx-ს შორის. დროა შეიარაღოთ Tcpdump-ით! მაგრამ ჯერ უნდა გესმოდეთ ქსელის კონფიგურაცია. Nginx პროქსი დგას L3 ბალანსერის უკან NFware. გვირაბი გამოიყენება პაკეტების გადასატანად L3 ბალანსერიდან სერვერზე, რომელიც ამატებს თავის სათაურებს პაკეტებს:

ამ შემთხვევაში, ქსელი მოდის ამ სერვერზე Vlan-ით მონიშნული ტრაფიკის სახით, რომელიც ასევე ამატებს საკუთარ ველებს პაკეტებს:

და ეს ტრაფიკი ასევე შეიძლება იყოს ფრაგმენტული (შემავალი ფრაგმენტული ტრაფიკის იგივე მცირე პროცენტი, რომელზეც ვისაუბრეთ Workaround-ის რისკების შეფასებისას), რაც ასევე ცვლის სათაურების შინაარსს:

კიდევ ერთხელ: პაკეტები ჩასმულია Vlan ტეგით, ჩაფლული გვირაბით, ფრაგმენტირებული. უკეთ რომ გავიგოთ, როგორ ხდება ეს, მოდით მივყვეთ პაკეტის მარშრუტს კლიენტიდან Nginx პროქსიმდე.

1. პაკეტი აღწევს L3 ბალანსერს. მონაცემთა ცენტრში სწორი მარშრუტირებისთვის, პაკეტი იკეტება გვირაბში და იგზავნება ქსელის ბარათზე.
2. ვინაიდან პაკეტი + გვირაბის სათაურები არ ჯდება MTU-ში, პაკეტი იჭრება ფრაგმენტებად და იგზავნება ქსელში.
3. Switch 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 მისამართი. თქვენ ასევე შეგიძლიათ შეხედოთ ერთ-ერთ პაკეტს hex-ში (-xx ან -XX პარამეტრი tcpdump-ში) და გამოთვალოთ თქვენთვის ცნობილი 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 .faEE.....@.2.m.
        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 00:de:ff:1a:94:11 ეთერტიპის IPv4 (0x0800), სიგრძე 62: (tos 0x0, ttl 63, ID 53652, ოფსეტი 1480, დროშები [არცერთი], პროტო IPIP (4), სიგრძე 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ..........ა....
        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”

ის ასევე არის snmpd-ში OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

”IP-ის ხელახალი შეკრების ალგორითმის მიერ გამოვლენილი წარუმატებლობების რაოდენობა (ნებისმიერი მიზეზის გამო: დრო ამოიწურა, შეცდომები და ა.შ.).”

სერვერების იმ ჯგუფს შორის, რომლებზეც პრობლემა შეისწავლეს, ორზე ეს მრიცხველი უფრო სწრაფად გაიზარდა, ორზე ნელა და ორზე საერთოდ არ გაიზარდა. ამ მრიცხველის დინამიკის შედარებამ Java სერვერზე HTTP შეცდომების დინამიკასთან გამოავლინა კორელაცია. ანუ მრიცხველის მონიტორინგი შეიძლებოდა.

პრობლემების საიმედო ინდიკატორის არსებობა ძალიან მნიშვნელოვანია, რათა ზუსტად განსაზღვროთ, ეხმარება თუ არა Sysctl-ის უკან დაბრუნება, რადგან წინა ისტორიიდან ვიცით, რომ ამის დაუყოვნებლივ გაგება შეუძლებელია აპლიკაციიდან. ეს მაჩვენებელი საშუალებას მოგვცემს გამოვავლინოთ წარმოების ყველა პრობლემური სფერო, სანამ მომხმარებლები აღმოაჩენენ მას.
Sysctl-ის უკან დაბრუნების შემდეგ, მონიტორინგის შეცდომები შეჩერდა, რითაც დადასტურდა პრობლემების მიზეზი, ასევე ის, რომ უკან დაბრუნება ეხმარება.

ჩვენ დავაბრუნეთ ფრაგმენტაციის პარამეტრები სხვა სერვერებზე, სადაც ამოქმედდა ახალი მონიტორინგი და სადღაც გამოვყავით კიდევ უფრო მეტი მეხსიერება ფრაგმენტებისთვის, ვიდრე ადრე იყო ნაგულისხმევი (ეს იყო UDP სტატისტიკა, რომლის ნაწილობრივი დაკარგვა არ იყო შესამჩნევი ზოგადი ფონზე) .

ყველაზე მნიშვნელოვანი კითხვები

რატომ არის პაკეტები ფრაგმენტირებული ჩვენს L3 ბალანსერზე? პაკეტების უმეტესობა, რომლებიც მომხმარებლებიდან ბალანსერამდე მიდის, არის SYN და ACK. ამ პაკეტების ზომები მცირეა. მაგრამ რადგან ასეთი პაკეტების წილი ძალიან დიდია, მათ ფონზე ჩვენ ვერ შევამჩნიეთ დიდი პაკეტების არსებობა, რომლებმაც დაიწყეს ფრაგმენტაცია.

მიზეზი გატეხილი კონფიგურაციის სკრიპტი იყო advmss სერვერებზე Vlan ინტერფეისით (მაშინ წარმოების დროს ძალიან ცოტა სერვერი იყო მონიშნული ტრაფიკით). Advmss საშუალებას გვაძლევს მივაწოდოთ კლიენტს ინფორმაცია, რომ ჩვენი მიმართულებით პაკეტები უფრო მცირე ზომის უნდა იყოს, რათა მათზე გვირაბის სათაურების მიმაგრების შემდეგ ისინი არ იყოს ფრაგმენტული.

რატომ არ დაეხმარა Sysctl-ის დაბრუნებას, მაგრამ გადატვირთვამ? Sysctl-ის უკან დაბრუნებამ შეცვალა პაკეტების გაერთიანებისთვის ხელმისაწვდომი მეხსიერების რაოდენობა. ამავდროულად, როგორც ჩანს, ფრაგმენტებისთვის მეხსიერების გადატვირთვის ფაქტმა გამოიწვია კავშირების შენელება, რამაც გამოიწვია ფრაგმენტების დიდი ხნით დაგვიანება რიგში. ანუ პროცესი ციკლურად მიმდინარეობდა.
გადატვირთვამ გაასუფთავა მეხსიერება და ყველაფერი წესრიგში დაბრუნდა.

შესაძლებელი იყო თუ არა Workaround-ის გარეშე? დიახ, მაგრამ თავდასხმის შემთხვევაში მომხმარებლების მომსახურების გარეშე დატოვების მაღალი რისკია. რა თქმა უნდა, Workaround-ის გამოყენებამ გამოიწვია სხვადასხვა პრობლემები, მათ შორის მომხმარებლებისთვის ერთ-ერთი სერვისის შენელება, მაგრამ მიუხედავად ამისა, ჩვენ მიგვაჩნია, რომ ქმედებები გამართლებული იყო.

დიდი მადლობა ანდრეი ტიმოფეევს (ატიმოფეევი) გამოძიების ჩატარებაში დახმარებისთვის, ასევე ალექსეი კრენევი (მოწყობილობაx) - განახლების ტიტანური შრომისთვის Centos და სერვერის ბირთვები. ამ შემთხვევაში, პროცესი რამდენჯერმე ხელახლა უნდა დაწყებულიყო, რის შედეგადაც მას რამდენიმე თვე დასჭირდა.

წყარო: www.habr.com