🥇 দুর্বলতা থেকে সাবধান থাকুন যা কাজের রাউন্ড নিয়ে আসে। পার্ট 1: FragmentSmack/SegmentSmack

হাই সব! আমার নাম দিমিত্রি স্যামসোনভ, আমি ওডনোক্লাসনিকিতে একজন প্রধান সিস্টেম প্রশাসক হিসাবে কাজ করি। আমাদের 7 হাজারেরও বেশি শারীরিক সার্ভার, আমাদের ক্লাউডে 11 হাজার কন্টেইনার এবং 200টি অ্যাপ্লিকেশন রয়েছে, যা বিভিন্ন কনফিগারেশনে 700টি বিভিন্ন ক্লাস্টার তৈরি করে। বেশিরভাগ সার্ভার CentOS 7 চালায়।
14 আগস্ট, 2018-এ, ফ্র্যাগমেন্টস্ম্যাক দুর্বলতা সম্পর্কে তথ্য প্রকাশিত হয়েছিল
(জন্য CVE-2018-5391) এবং সেগমেন্টস্ম্যাক (জন্য CVE-2018-5390) এগুলি হল নেটওয়ার্ক অ্যাটাক ভেক্টর এবং মোটামুটি উচ্চ স্কোর (7.5) সহ দুর্বলতা, যা রিসোর্স এক্সহাউসশন (CPU) এর কারণে পরিষেবা অস্বীকার করার (DoS) হুমকি দেয়। FragmentSmack-এর জন্য একটি কার্নেল ফিক্স সেই সময়ে প্রস্তাবিত ছিল না; অধিকন্তু, এটি দুর্বলতা সম্পর্কে তথ্য প্রকাশের চেয়ে অনেক পরে বেরিয়ে এসেছিল। SegmentSmack দূর করতে, কার্নেল আপডেট করার পরামর্শ দেওয়া হয়েছিল। আপডেট প্যাকেজটি নিজেই একই দিনে প্রকাশিত হয়েছিল, যা বাকি ছিল তা ইনস্টল করার জন্য।
না, আমরা মোটেই কার্নেল আপডেট করার বিপক্ষে নই! যাইহোক, সূক্ষ্মতা আছে ...

কিভাবে আমরা উৎপাদনে কার্নেল আপডেট করি

সাধারণভাবে, কিছুই জটিল নয়:

প্যাকেজ ডাউনলোড করুন;
এগুলিকে বেশ কয়েকটি সার্ভারে ইনস্টল করুন (আমাদের ক্লাউড হোস্ট করা সার্ভার সহ);
নিশ্চিত করুন যে কিছুই ভাঙ্গা হয় না;
নিশ্চিত করুন যে সমস্ত মানক কার্নেল সেটিংস ত্রুটি ছাড়াই প্রয়োগ করা হয়েছে;
কিছু দিন অপেক্ষা করুন;
সার্ভার কর্মক্ষমতা পরীক্ষা করুন;
নতুন কার্নেলে নতুন সার্ভারের স্থাপনার পরিবর্তন করুন;
ডেটা সেন্টার দ্বারা সমস্ত সার্ভার আপডেট করুন (সমস্যার ক্ষেত্রে ব্যবহারকারীদের উপর প্রভাব কমাতে এক সময়ে একটি ডেটা সেন্টার);
সমস্ত সার্ভার রিবুট করুন।

আমাদের কাছে থাকা কার্নেলের সমস্ত শাখার জন্য পুনরাবৃত্তি করুন। এই মুহূর্তে এটি হল:

স্টক CentOS 7 3.10 - বেশিরভাগ নিয়মিত সার্ভারের জন্য;
ভ্যানিলা 4.19 - আমাদের জন্য এক-মেঘ মেঘ, কারণ আমাদের BFQ, BBR, ইত্যাদি প্রয়োজন;
Elrepo kernel-ml 5.2 - এর জন্য অত্যন্ত লোড পরিবেশকদের, কারণ 4.19 অস্থির আচরণ করত, কিন্তু একই বৈশিষ্ট্য প্রয়োজন।

আপনি হয়তো অনুমান করেছেন, হাজার হাজার সার্ভার রিবুট করতে সবচেয়ে বেশি সময় লাগে। যেহেতু সমস্ত দুর্বলতা সমস্ত সার্ভারের জন্য গুরুত্বপূর্ণ নয়, তাই আমরা শুধুমাত্র সেগুলিই রিবুট করি যেগুলি ইন্টারনেট থেকে সরাসরি অ্যাক্সেসযোগ্য৷ ক্লাউডে, নমনীয়তা সীমাবদ্ধ না করার জন্য, আমরা একটি নতুন কার্নেল সহ পৃথক সার্ভারের সাথে বাহ্যিকভাবে অ্যাক্সেসযোগ্য পাত্রে বাঁধি না, তবে ব্যতিক্রম ছাড়াই সমস্ত হোস্ট রিবুট করি। সৌভাগ্যবশত, নিয়মিত সার্ভারের তুলনায় পদ্ধতিটি সহজ। উদাহরণস্বরূপ, স্টেটলেস কন্টেইনারগুলি রিবুট করার সময় অন্য সার্ভারে যেতে পারে।

যাইহোক, এখনও অনেক কাজ আছে, এবং এটি কয়েক সপ্তাহ সময় নিতে পারে, এবং যদি নতুন সংস্করণে কোন সমস্যা হয়, কয়েক মাস পর্যন্ত। আক্রমণকারীরা এটি খুব ভালভাবে বোঝে, তাই তাদের একটি পরিকল্পনা বি প্রয়োজন।

FragmentSmack/SegmentSmack. ওয়ার্কআউন্ড

সৌভাগ্যবশত, কিছু দুর্বলতার জন্য এই ধরনের একটি প্ল্যান বি বিদ্যমান, এবং এটিকে বলা হয় ওয়ার্করাউন্ড। প্রায়শই, এটি কার্নেল/অ্যাপ্লিকেশন সেটিংসের একটি পরিবর্তন যা সম্ভাব্য প্রভাবকে কমিয়ে দিতে পারে বা দুর্বলতার শোষণকে সম্পূর্ণরূপে দূর করতে পারে।

FragmentSmack/SegmentSmack এর ক্ষেত্রে প্রস্তাব করা হয়েছিল এই সমাধান:

«আপনি net.ipv4.ipfrag_high_thresh এবং net.ipv3.ipfrag_low_thresh (এবং ipv4 net.ipv4.ipfrag_high_thresh এবং net.ipv6.ipfrag_low_thresh এবং net.ipv6.ipfrag_low_thresh-এর জন্য তাদের প্রতিরূপ) 6MB এবং 256MB এর ডিফল্ট মানগুলি যথাক্রমে kB192 বা kB262144 kB64 তে পরিবর্তন করতে পারেন নিম্ন হার্ডওয়্যার, সেটিংস এবং অবস্থার উপর নির্ভর করে আক্রমণের সময় পরীক্ষাগুলি 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 এর মাধ্যমে ডকারে প্রেরণ করা হয়েছিল।
সংস্করণগুলির মাধ্যমে অনুসন্ধান করার সময়, দেখা গেল যে ডকার এপিআই সমস্ত ত্রুটি ফেরত দেয়নি (অন্তত সংস্করণ 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 ছিল, অর্থাৎ, উপরের সীমাটি কম ছিল নিম্ন সীমার চেয়ে, যা ত্রুটির দিকে পরিচালিত করে।

সেই সময়ে, আমরা ইতিমধ্যেই স্টার্টের পরে কন্টেইনার পুনরায় কনফিগার করার জন্য আমাদের নিজস্ব পদ্ধতি ব্যবহার করেছি (এর পরে কন্টেইনার হিমায়িত করা গ্রুপ ফ্রিজার এবং এর মাধ্যমে কন্টেইনারের নামস্থানে কমান্ড নির্বাহ করা ip netns), এবং আমরা এই অংশে Sysctl পরামিতি লেখা যোগ করেছি। সমস্যাটি সমাধান করা হয়েছে.

FragmentSmack/SegmentSmack. প্রথম রক্ত 2

ক্লাউডে ওয়ার্কঅ্যারাউন্ডের ব্যবহার বোঝার সময় পাওয়ার আগে, ব্যবহারকারীদের কাছ থেকে প্রথম বিরল অভিযোগ আসতে শুরু করে। সেই সময়ে, প্রথম সার্ভারে ওয়ার্কঅ্যারাউন্ড ব্যবহার শুরু করার পর বেশ কয়েক সপ্তাহ কেটে গেছে। প্রাথমিক তদন্তে দেখা গেছে যে পৃথক পরিষেবাগুলির বিরুদ্ধে অভিযোগ পাওয়া গেছে, এবং এই পরিষেবাগুলির সমস্ত সার্ভার নয়। সমস্যা আবার চরম অনিশ্চিত হয়ে পড়েছে।

প্রথমত, আমরা, অবশ্যই, 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" হল এই শিডিউলারের সমস্ত বাদ দেওয়া প্যাকেটের সমষ্টি৷ সারির দৈর্ঘ্য বাড়িয়ে ১ হাজারে উন্নীত করা এবং কন্টেইনারগুলি পুনরায় চালু করার পরে, সমস্যাটি বন্ধ হয়ে যায়। আপনি ফিরে বসে একটি স্মুদি পান করতে পারেন।

FragmentSmack/SegmentSmack. শেষ রক্ত

প্রথমত, কার্নেলে দুর্বলতা ঘোষণার বেশ কয়েক মাস পরে, অবশেষে ফ্র্যাগমেন্টস্ম্যাকের জন্য একটি ফিক্স উপস্থিত হয়েছিল (আমাকে মনে করিয়ে দিই যে আগস্টে ঘোষণার সাথে সাথে, শুধুমাত্র সেগমেন্টস্ম্যাকের জন্য একটি ফিক্স প্রকাশিত হয়েছিল), যা আমাদের ওয়ার্কঅ্যারাউন্ড পরিত্যাগ করার সুযোগ দিয়েছে, যা আমাদের বেশ ঝামেলার সৃষ্টি করেছে। এই সময়ের মধ্যে, আমরা ইতিমধ্যে কিছু সার্ভারকে নতুন কার্নেলে স্থানান্তর করতে পেরেছি এবং এখন আমাদের শুরু থেকে শুরু করতে হবে। কেন আমরা FragmentSmack ফিক্সের জন্য অপেক্ষা না করে কার্নেল আপডেট করেছি? আসল বিষয়টি হ'ল এই দুর্বলতার বিরুদ্ধে সুরক্ষার প্রক্রিয়াটি CentOS নিজেই আপডেট করার প্রক্রিয়ার সাথে মিলে গেছে (এবং একত্রিত হয়েছে) (যা কেবল কার্নেল আপডেট করার চেয়ে আরও বেশি সময় নেয়)। উপরন্তু, SegmentSmack একটি আরও বিপজ্জনক দুর্বলতা, এবং এটির জন্য একটি সমাধান অবিলম্বে উপস্থিত হয়েছে, তাই এটি যেভাবেই হোক তা বোঝা যায়। যাইহোক, আমরা কেবল সেন্টোসে কার্নেলটি আপডেট করতে পারিনি কারণ ফ্র্যাগমেন্টসম্যাক দুর্বলতা, যা CentOS 7.5 এর সময় উপস্থিত হয়েছিল, কেবলমাত্র 7.6 সংস্করণে স্থির করা হয়েছিল, তাই আমাদের 7.5-এ আপডেট বন্ধ করতে হয়েছিল এবং 7.6-এ আপডেটের সাথে আবার শুরু করতে হয়েছিল। এবং এটিও ঘটে।

দ্বিতীয়ত, সমস্যা সম্পর্কে বিরল ব্যবহারকারীর অভিযোগ আমাদের কাছে ফিরে এসেছে। এখন আমরা ইতিমধ্যেই নিশ্চিতভাবে জানি যে সেগুলি আমাদের কিছু সার্ভারে ক্লায়েন্ট থেকে ফাইল আপলোড করার সাথে সম্পর্কিত। অধিকন্তু, মোট ভর থেকে খুব কম সংখ্যক আপলোড এই সার্ভারগুলির মাধ্যমে গেছে।

আমরা উপরের গল্প থেকে মনে রাখি, Sysctl রোল ব্যাক করা সাহায্য করেনি। রিবুট সাহায্য করেছে, কিন্তু সাময়িকভাবে।
Sysctl সম্পর্কিত সন্দেহ দূর করা হয়নি, তবে এই সময় যতটা সম্ভব তথ্য সংগ্রহ করা প্রয়োজন ছিল। কি ঘটছে তা আরও সুনির্দিষ্টভাবে অধ্যয়ন করার জন্য ক্লায়েন্টে আপলোড সমস্যাটি পুনরুত্পাদন করার ক্ষমতার একটি বিশাল অভাব ছিল।

সমস্ত উপলব্ধ পরিসংখ্যান এবং লগগুলির বিশ্লেষণ আমাদেরকে কী ঘটছে তা বোঝার কাছাকাছি নিয়ে আসেনি। একটি নির্দিষ্ট সংযোগ "অনুভূত" করার জন্য সমস্যাটি পুনরুত্পাদন করার ক্ষমতার তীব্র অভাব ছিল। অবশেষে, বিকাশকারীরা, অ্যাপ্লিকেশনটির একটি বিশেষ সংস্করণ ব্যবহার করে, Wi-Fi এর মাধ্যমে সংযুক্ত থাকাকালীন একটি পরীক্ষা ডিভাইসে সমস্যার স্থিতিশীল প্রজনন অর্জন করতে সক্ষম হন। এটি তদন্তে একটি যুগান্তকারী ছিল। ক্লায়েন্ট Nginx-এর সাথে সংযুক্ত, যা ব্যাকএন্ডে প্রক্সি করে, যা ছিল আমাদের জাভা অ্যাপ্লিকেশন।

সমস্যার জন্য কথোপকথনটি এইরকম ছিল (এনগিনেক্স প্রক্সি সাইডে স্থির):

ক্লায়েন্ট: একটি ফাইল ডাউনলোড করার বিষয়ে তথ্য পাওয়ার অনুরোধ।
জাভা সার্ভার: প্রতিক্রিয়া।
ক্লায়েন্ট: ফাইল সহ পোস্ট করুন।
জাভা সার্ভার: ত্রুটি।

একই সময়ে, জাভা সার্ভার লগে লিখে যে ক্লায়েন্টের কাছ থেকে 0 বাইট ডেটা গৃহীত হয়েছে এবং Nginx প্রক্সি লিখেছে যে অনুরোধটি 30 সেকেন্ডের বেশি সময় নিয়েছে (30 সেকেন্ড হল ক্লায়েন্ট অ্যাপ্লিকেশনের সময়সীমা)। কেন টাইমআউট এবং কেন 0 বাইট? একটি HTTP দৃষ্টিকোণ থেকে, সবকিছু যেমন উচিত তেমন কাজ করে, কিন্তু ফাইল সহ POST নেটওয়ার্ক থেকে অদৃশ্য হয়ে গেছে বলে মনে হচ্ছে। অধিকন্তু, এটি ক্লায়েন্ট এবং Nginx এর মধ্যে অদৃশ্য হয়ে যায়। এটি Tcpdump এর সাথে নিজেকে সজ্জিত করার সময়! কিন্তু প্রথমে আপনাকে নেটওয়ার্ক কনফিগারেশন বুঝতে হবে। Nginx প্রক্সি L3 ব্যালেন্সারের পিছনে রয়েছে NFware. L3 ব্যালেন্সার থেকে সার্ভারে প্যাকেট সরবরাহ করতে টানেলিং ব্যবহার করা হয়, যা প্যাকেটগুলিতে এর হেডার যুক্ত করে:

এই ক্ষেত্রে, নেটওয়ার্কটি এই সার্ভারে Vlan-ট্যাগযুক্ত ট্র্যাফিকের আকারে আসে, যা প্যাকেটগুলিতে নিজস্ব ক্ষেত্র যুক্ত করে:

এবং এই ট্র্যাফিকটিও খণ্ডিত হতে পারে (আগত খণ্ডিত ট্র্যাফিকের একই ছোট শতাংশ যা আমরা ওয়ার্কঅ্যারাউন্ড থেকে ঝুঁকিগুলি মূল্যায়ন করার সময় বলেছিলাম), যা শিরোনামের বিষয়বস্তুকেও পরিবর্তন করে:

আবারও: প্যাকেটগুলি একটি ভ্লান ট্যাগ দিয়ে এনক্যাপসুলেট করা হয়, একটি টানেল দিয়ে এনক্যাপসুলেট করা হয়, খণ্ডিত। এটি কীভাবে ঘটে তা আরও ভালভাবে বোঝার জন্য, আসুন ক্লায়েন্ট থেকে Nginx প্রক্সিতে প্যাকেটের রুটটি ট্রেস করি।

প্যাকেটটি এল 3 ব্যালেন্সারে পৌঁছায়। ডাটা সেন্টারের মধ্যে সঠিক রাউটিং করার জন্য, প্যাকেটটি একটি টানেলের মধ্যে ক্যাপসুলেট করা হয় এবং নেটওয়ার্ক কার্ডে পাঠানো হয়।
যেহেতু প্যাকেট + টানেল হেডার MTU-তে ফিট হয় না, প্যাকেটটি টুকরো টুকরো করে নেটওয়ার্কে পাঠানো হয়।
L3 ব্যালেন্সারের পরে থাকা সুইচটি, যখন একটি প্যাকেট গ্রহণ করে, এটিতে একটি Vlan ট্যাগ যোগ করে এবং এটিকে প্রেরণ করে।
Nginx প্রক্সির সামনের সুইচটি দেখতে পায় (পোর্ট সেটিংসের উপর ভিত্তি করে) যে সার্ভারটি একটি Vlan-এনক্যাপসুলেটেড প্যাকেটের প্রত্যাশা করছে, তাই এটি Vlan ট্যাগটি না সরিয়েই এটিকে পাঠায়।
লিনাক্স পৃথক প্যাকেজগুলির টুকরোগুলি নেয় এবং সেগুলিকে একটি বড় প্যাকেজে একত্রিত করে।
এর পরে, প্যাকেটটি Vlan ইন্টারফেসে পৌঁছায়, যেখানে এটি থেকে প্রথম স্তরটি সরানো হয় - Vlan encapsulation।
লিনাক্স তারপর এটিকে টানেল ইন্টারফেসে পাঠায়, যেখানে এটি থেকে আরেকটি স্তর সরানো হয় - টানেল এনক্যাপসুলেশন।

অসুবিধা হল এই সবগুলিকে প্যারামিটার হিসাবে tcpdump এ পাস করা।
শেষ থেকে শুরু করা যাক: ক্লায়েন্টদের কাছ থেকে কি পরিষ্কার (অপ্রয়োজনীয় হেডার ছাড়া) আইপি প্যাকেট আছে, যেখানে ভ্লান এবং টানেল এনক্যাপসুলেশন সরানো হয়েছে?

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

না, সার্ভারে এমন কোনো প্যাকেজ ছিল না। তাই সমস্যাটা আগে থেকেই হতে হবে। শুধুমাত্র ভ্লান এনক্যাপসুলেশন মুছে ফেলা কোনো প্যাকেট আছে?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx হল হেক্স ফরম্যাটে ক্লায়েন্ট আইপি ঠিকানা।
32:4 — যে ক্ষেত্রের ঠিকানা এবং দৈর্ঘ্য টানেল প্যাকেটে SCR IP লেখা আছে।

ফিল্ড অ্যাড্রেসটি ব্রুট ফোর্স দ্বারা নির্বাচন করতে হয়েছিল, যেহেতু ইন্টারনেটে তারা 40, 44, 50, 54 লিখে, কিন্তু সেখানে কোনও আইপি ঠিকানা ছিল না। আপনি হেক্সের প্যাকেটগুলির মধ্যে একটি দেখতে পারেন (tcpdump-এ -xx বা -XX প্যারামিটার) এবং আপনি যে আইপি ঠিকানাটি জানেন তা গণনা করতে পারেন।

ভ্লান এবং টানেল এনক্যাপসুলেশন ছাড়াই কি প্যাকেটের টুকরো আছে?

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

এটি একটি ছবি সহ একটি প্যাকেজের দুটি টুকরো (একই আইডি 53652) (প্রথম প্যাকেজে Exif শব্দটি দৃশ্যমান)৷ এই স্তরে প্যাকেজ আছে যে কারণে, কিন্তু ডাম্পে একত্রিত আকারে নয়, সমস্যাটি স্পষ্টভাবে সমাবেশের সাথে। অবশেষে এর দালিলিক প্রমাণ পাওয়া গেল!

প্যাকেট ডিকোডার এমন কোনো সমস্যা প্রকাশ করেনি যা বিল্ডকে বাধা দেবে। এটি এখানে চেষ্টা করেছেন: hpd.gasmi.net. প্রথমে, যখন আপনি সেখানে কিছু স্টাফ করার চেষ্টা করেন, ডিকোডার প্যাকেট বিন্যাস পছন্দ করে না। দেখা গেল যে Srcmac এবং Ethertype এর মধ্যে কিছু অতিরিক্ত দুটি অক্টেট রয়েছে (খণ্ডিত তথ্যের সাথে সম্পর্কিত নয়)। তাদের অপসারণ করার পরে, ডিকোডার কাজ শুরু করে। যাইহোক, এটি কোন সমস্যা দেখায়.
যে যাই বলুক না কেন, সিসিক্টল ছাড়া আর কিছুই পাওয়া যায়নি। যা বাকি ছিল তা হল স্কেল বোঝার জন্য এবং পরবর্তী কর্মের বিষয়ে সিদ্ধান্ত নেওয়ার জন্য সমস্যা সার্ভারগুলি সনাক্ত করার উপায় খুঁজে বের করা। প্রয়োজনীয় কাউন্টারটি যথেষ্ট দ্রুত পাওয়া গেছে:

netstat -s | grep "packet reassembles failed”

এটি OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"আইপি রি-অ্যাসেম্বলি অ্যালগরিদম দ্বারা সনাক্ত করা ব্যর্থতার সংখ্যা (যে কোনো কারণেই হোক: সময় শেষ, ত্রুটি, ইত্যাদি)।"

যে সকল সার্ভারে সমস্যাটি অধ্যয়ন করা হয়েছিল তাদের মধ্যে দুটিতে এই কাউন্টারটি দ্রুত বৃদ্ধি পেয়েছে, আরও দুটিতে ধীরে ধীরে এবং আরও দুটিতে এটি মোটেও বাড়েনি। জাভা সার্ভারে এইচটিটিপি ত্রুটির গতিশীলতার সাথে এই কাউন্টারের গতিবিদ্যার তুলনা করলে একটি সম্পর্ক প্রকাশ পায়। অর্থাৎ মিটার পর্যবেক্ষণ করা যেত।

সমস্যার একটি নির্ভরযোগ্য সূচক থাকা খুবই গুরুত্বপূর্ণ যাতে আপনি সঠিকভাবে নির্ধারণ করতে পারেন যে Sysctl রোল ব্যাক করা সাহায্য করে কিনা, কারণ আগের গল্প থেকে আমরা জানি যে এটি অ্যাপ্লিকেশন থেকে অবিলম্বে বোঝা যাবে না। ব্যবহারকারীরা এটি আবিষ্কার করার আগে এই সূচকটি আমাদের উত্পাদনের সমস্ত সমস্যা ক্ষেত্রগুলি সনাক্ত করার অনুমতি দেবে।
Sysctl রোল ব্যাক করার পরে, পর্যবেক্ষণ ত্রুটিগুলি বন্ধ হয়ে গেছে, এইভাবে সমস্যার কারণ প্রমাণিত হয়েছে, সেইসাথে রোলব্যাক সাহায্য করে।

আমরা অন্যান্য সার্ভারে ফ্র্যাগমেন্টেশন সেটিংস ফিরিয়ে এনেছি, যেখানে নতুন মনিটরিং কার্যকর হয়েছে, এবং কোথাও আমরা আগের ডিফল্টের তুলনায় টুকরোগুলির জন্য আরও বেশি মেমরি বরাদ্দ করেছি (এটি ছিল UDP পরিসংখ্যান, যার আংশিক ক্ষতি সাধারণ পটভূমিতে লক্ষণীয় ছিল না) .

সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন

কেন আমাদের L3 ব্যালেন্সারে প্যাকেটগুলি খণ্ডিত হয়? ব্যবহারকারীদের থেকে ব্যালেন্সারের কাছে আসা বেশিরভাগ প্যাকেট হল SYN এবং ACK। এই প্যাকেজগুলির আকার ছোট। কিন্তু যেহেতু এই ধরনের প্যাকেটগুলির ভাগ খুব বড়, তাদের পটভূমিতে আমরা বড় প্যাকেটের উপস্থিতি লক্ষ্য করিনি যা খণ্ডিত হতে শুরু করে।

কারণ একটি ভাঙা কনফিগারেশন স্ক্রিপ্ট ছিল advmss ভ্লান ইন্টারফেস সহ সার্ভারগুলিতে (তখন উৎপাদনে ট্যাগযুক্ত ট্র্যাফিক সহ খুব কম সার্ভার ছিল)। Advmss আমাদের ক্লায়েন্টকে সেই তথ্য জানাতে দেয় যে আমাদের দিকের প্যাকেটগুলি আকারে ছোট হওয়া উচিত যাতে তাদের সাথে টানেল হেডার সংযুক্ত করার পরে সেগুলিকে খণ্ডিত হতে না হয়।

কেন Sysctl রোলব্যাক সাহায্য করেনি, কিন্তু রিবুট করেছিল? Sysctl রোল ব্যাক করা প্যাকেজ মার্জ করার জন্য উপলব্ধ মেমরির পরিমাণ পরিবর্তন করেছে। একই সময়ে, আপাতদৃষ্টিতে টুকরোগুলির জন্য মেমরি ওভারফ্লো হওয়ার ঘটনাটি সংযোগের গতি কমিয়ে দেয়, যার ফলে টুকরোগুলি সারিতে দীর্ঘ সময়ের জন্য বিলম্বিত হয়। অর্থাৎ প্রক্রিয়াটি চক্রাকারে চলছিল।
রিবুট মেমরি সাফ করে এবং সবকিছু অর্ডারে ফিরে আসে।

এটা কি workaround ছাড়া করা সম্ভব ছিল? হ্যাঁ, তবে আক্রমণের ক্ষেত্রে ব্যবহারকারীদের পরিষেবা ছাড়াই চলে যাওয়ার একটি উচ্চ ঝুঁকি রয়েছে। অবশ্যই, ওয়ার্কঅ্যারাউন্ড ব্যবহারের ফলে ব্যবহারকারীদের জন্য একটি পরিষেবার ধীরগতি সহ বিভিন্ন সমস্যা দেখা দিয়েছে, কিন্তু তবুও আমরা বিশ্বাস করি যে ক্রিয়াগুলি ন্যায়সঙ্গত ছিল৷

আন্দ্রে টিমোফিভকে অনেক ধন্যবাদ (atimofeyevতদন্ত পরিচালনায় সহায়তার জন্য, পাশাপাশি আলেক্সি ক্রেনেভ (ডিভাইসএক্স) - সার্ভারে সেন্টোস এবং কার্নেল আপডেট করার টাইটানিক কাজের জন্য। একটি প্রক্রিয়া যা এই ক্ষেত্রে প্রথম থেকেই শুরু করতে হয়েছিল বেশ কয়েকবার, যে কারণে এটি বহু মাস ধরে টানা যায়।

উত্স: www.habr.com

দুর্বলতা থেকে সাবধান থাকুন যা কাজের রাউন্ড নিয়ে আসে। পার্ট 1: FragmentSmack/SegmentSmack