Google ক্লাউড প্রযুক্তিগত সহায়তা থেকে অনুপস্থিত DNS প্যাকেট সম্পর্কে একটি গল্প

গুগল ব্লগ এডিটর থেকে: আপনি কি কখনও ভেবে দেখেছেন যে কীভাবে Google ক্লাউড টেকনিক্যাল সলিউশন (TSE) ইঞ্জিনিয়াররা আপনার সহায়তার অনুরোধগুলি পরিচালনা করে? TSE টেকনিক্যাল সাপোর্ট ইঞ্জিনিয়াররা ব্যবহারকারী-প্রতিবেদিত সমস্যাগুলির উত্স সনাক্তকরণ এবং সংশোধন করার জন্য দায়ী। এই সমস্যাগুলির মধ্যে কিছু বেশ সহজ, কিন্তু কখনও কখনও আপনি এমন একটি টিকিটের সম্মুখীন হন যার জন্য একবারে একাধিক প্রকৌশলীর মনোযোগ প্রয়োজন। এই নিবন্ধে, TSE কর্মচারীদের একজন তার সাম্প্রতিক অনুশীলন থেকে একটি খুব জটিল সমস্যা সম্পর্কে আমাদের বলবেন - অনুপস্থিত DNS প্যাকেটের ক্ষেত্রে. এই গল্পে, আমরা দেখব যে প্রকৌশলীরা কীভাবে পরিস্থিতি সমাধান করতে পেরেছিল এবং ত্রুটিটি ঠিক করার সময় তারা কী নতুন জিনিস শিখেছিল। আমরা আশা করি যে এই গল্পটি আপনাকে কেবল একটি গভীর-সিটেড বাগ সম্পর্কে শিক্ষিত করবে না, তবে Google ক্লাউডের সাথে একটি সমর্থন টিকিট ফাইল করার প্রক্রিয়াগুলির অন্তর্দৃষ্টিও দেবে৷

সমস্যা সমাধান একটি বিজ্ঞান এবং একটি শিল্প উভয়ই। এটি সমস্ত সিস্টেমের অ-মানক আচরণের কারণ সম্পর্কে একটি হাইপোথিসিস তৈরির সাথে শুরু হয়, যার পরে এটি শক্তির জন্য পরীক্ষা করা হয়। যাইহোক, আমরা একটি হাইপোথিসিস প্রণয়ন করার আগে, আমাদের অবশ্যই সমস্যাটিকে স্পষ্টভাবে সংজ্ঞায়িত করতে হবে এবং সুনির্দিষ্টভাবে প্রণয়ন করতে হবে। যদি প্রশ্নটি খুব অস্পষ্ট মনে হয়, তবে আপনাকে সবকিছু সাবধানে বিশ্লেষণ করতে হবে; এটি সমস্যা সমাধানের "শিল্প"।

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

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

প্রশ্নে সমস্যা

আজ আমরা একটি ভাল সমাপ্তি সঙ্গে একটি গল্প আছে. প্রস্তাবিত মামলার সফল সমাধানের একটি কারণ হল সমস্যাটির একটি অত্যন্ত বিশদ এবং সঠিক বর্ণনা। নীচে আপনি প্রথম টিকিটের একটি অনুলিপি দেখতে পারেন (গোপনীয় তথ্য লুকানোর জন্য সম্পাদিত):

এই বার্তাটিতে আমাদের জন্য অনেক দরকারী তথ্য রয়েছে:

• নির্দিষ্ট VM উল্লেখ করা হয়েছে
• সমস্যা নিজেই নির্দেশিত - DNS কাজ করে না
• এটি নির্দেশিত হয় যেখানে সমস্যাটি নিজেকে প্রকাশ করে - VM এবং ধারক
• সমস্যা চিহ্নিত করার জন্য ব্যবহারকারীর নেওয়া পদক্ষেপগুলি নির্দেশিত হয়েছে৷

অনুরোধটি "P1: ক্রিটিক্যাল ইমপ্যাক্ট - পরিষেবা উৎপাদনে অব্যবহারযোগ্য" হিসাবে নিবন্ধিত হয়েছিল, যার মানে হল "ফলো দ্য সান" স্কিম অনুসারে পরিস্থিতি 24/7 অবিরাম পর্যবেক্ষণ করা (আপনি সম্পর্কে আরও পড়তে পারেন ব্যবহারকারীর অনুরোধের অগ্রাধিকার), প্রতিটি টাইম জোন স্থানান্তরের সাথে একটি প্রযুক্তিগত সহায়তা দল থেকে অন্যটিতে স্থানান্তর সহ। প্রকৃতপক্ষে, জুরিখে আমাদের টিমের কাছে সমস্যাটি পৌঁছানোর সময়, এটি ইতিমধ্যে বিশ্বকে প্রদক্ষিণ করেছে। এই সময়ের মধ্যে, ব্যবহারকারী প্রশমনের ব্যবস্থা গ্রহণ করেছিল, কিন্তু উৎপাদনে পরিস্থিতির পুনরাবৃত্তির ভয় ছিল, যেহেতু মূল কারণটি এখনও আবিষ্কৃত হয়নি।

টিকিট জুরিখ পৌঁছানোর সময়, আমাদের কাছে ইতিমধ্যেই নিম্নলিখিত তথ্য ছিল:

• সামগ্রী /etc/hosts
• সামগ্রী /etc/resolv.conf
• উপসংহার iptables-save
• দল দ্বারা একত্রিত ngrep pcap ফাইল

এই ডেটা দিয়ে, আমরা "তদন্ত" এবং সমস্যা সমাধানের পর্যায় শুরু করতে প্রস্তুত ছিলাম।

আমাদের প্রথম পদক্ষেপ

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

এটি এক ধরণের অদ্ভুত সমস্যা ছিল: nmap চেক UDP প্যাকেটের ক্ষতি সম্পর্কে আমাদের মূল অনুমানকে খণ্ডন করেছে, তাই আমরা মানসিকভাবে আরও কয়েকটি বিকল্প এবং সেগুলি পরীক্ষা করার উপায় নিয়ে এসেছি:

• প্যাকেট কি বেছে বেছে ড্রপ করা হয়? => iptables নিয়ম চেক করুন
• খুব ছোট তাই না? MTU? => আউটপুট পরীক্ষা করুন ip a show
• সমস্যাটি কি শুধুমাত্র UDP প্যাকেট বা TCP কেও প্রভাবিত করে? => তাড়িয়ে দাও dig +tcp
• খনন উৎপন্ন প্যাকেট ফিরে? => তাড়িয়ে দাও tcpdump
• libdns সঠিকভাবে কাজ করছে? => তাড়িয়ে দাও strace উভয় দিকে প্যাকেটের সংক্রমণ পরীক্ষা করতে

এখানে আমরা লাইভ সমস্যা সমাধানের জন্য ব্যবহারকারীকে কল করার সিদ্ধান্ত নিয়েছি।

কল চলাকালীন আমরা বেশ কিছু জিনিস পরীক্ষা করতে পারি:

• বেশ কয়েকটি চেক করার পরে আমরা কারণগুলির তালিকা থেকে iptables নিয়মগুলি বাদ দিই
• আমরা নেটওয়ার্ক ইন্টারফেস এবং রাউটিং টেবিল পরীক্ষা করি এবং MTU সঠিক কিনা তা দুবার চেক করি
• আমরা সেটা আবিষ্কার করি dig +tcp google.com (TCP) কাজ করে যেমনটা উচিত, কিন্তু dig google.com (UDP) কাজ করে না
• তাড়িয়ে দিয়ে tcpdump কাজ করার সময় dig, আমরা দেখতে পাই যে UDP প্যাকেট ফেরত দেওয়া হচ্ছে
• আমরা তাড়িয়ে দেই strace dig google.com এবং আমরা কিভাবে সঠিকভাবে কল খনন দেখতে sendmsg() и recvms(), তবে দ্বিতীয়টি একটি টাইমআউট দ্বারা বাধাপ্রাপ্ত হয়৷

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

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

এই খণ্ডটি একটি DNS প্যাকেট তৈরি করে এবং মেটাডেটা সার্ভারে অনুরোধ পাঠায়।

ব্যবহারকারী কোড চালায়, DNS প্রতিক্রিয়া ফেরত দেওয়া হয় এবং অ্যাপ্লিকেশনটি এটি গ্রহণ করে, নিশ্চিত করে যে নেটওয়ার্ক স্তরে কোন সমস্যা নেই।

অন্য একটি "বিশ্ব-বিশ্ব ভ্রমণের" পরে, অনুরোধটি আমাদের দলের কাছে ফিরে আসে এবং আমি এটি সম্পূর্ণরূপে নিজের কাছে স্থানান্তর করি, এই ভেবে যে অনুরোধটি জায়গায় জায়গায় ঘুরা বন্ধ হলে ব্যবহারকারীর পক্ষে এটি আরও সুবিধাজনক হবে৷

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

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

একধাপ পিছিয়ে নিচ্ছে

সিস্টেম ইঞ্জিনিয়ার পদের জন্য সবচেয়ে জনপ্রিয় ইন্টারভিউ প্রশ্নগুলির মধ্যে একটি হল: “আপনি যখন পিং করেন তখন কী হয় www.google.com? প্রশ্নটি দুর্দান্ত, যেহেতু প্রার্থীকে শেল থেকে ব্যবহারকারীর স্থান, সিস্টেম কার্নেল এবং তারপরে নেটওয়ার্কে সবকিছু বর্ণনা করতে হবে। আমি হাসি: মাঝে মাঝে সাক্ষাত্কারের প্রশ্ন বাস্তব জীবনে কাজে লাগে...

আমি এই এইচআর প্রশ্নটি বর্তমান সমস্যায় প্রয়োগ করার সিদ্ধান্ত নিয়েছি। মোটামুটিভাবে বলতে গেলে, আপনি যখন একটি DNS নাম নির্ধারণ করার চেষ্টা করেন, নিম্নলিখিতগুলি ঘটে:

1. অ্যাপ্লিকেশনটি একটি সিস্টেম লাইব্রেরি যেমন libdns কল করে
2. libdns সিস্টেম কনফিগারেশন পরীক্ষা করে যে DNS সার্ভারের সাথে এটি যোগাযোগ করবে (ডায়াগ্রামে এটি 169.254.169.254, মেটাডেটা সার্ভার)
3. libdns একটি UDP সকেট (SOKET_DGRAM) তৈরি করতে সিস্টেম কল ব্যবহার করে এবং উভয় দিকে একটি DNS ক্যোয়ারী সহ UDP প্যাকেট পাঠায়
4. sysctl ইন্টারফেসের মাধ্যমে আপনি কার্নেল স্তরে UDP স্ট্যাক কনফিগার করতে পারেন
5. কার্নেল নেটওয়ার্ক ইন্টারফেসের মাধ্যমে নেটওয়ার্কে প্যাকেট প্রেরণ করতে হার্ডওয়্যারের সাথে যোগাযোগ করে
6. হাইপারভাইজার প্যাকেটটিকে মেটাডেটা সার্ভারের সাথে যোগাযোগ করার পরে ক্যাচ করে এবং প্রেরণ করে
7. মেটাডেটা সার্ভার, তার জাদু দ্বারা, DNS নাম নির্ধারণ করে এবং একই পদ্ধতি ব্যবহার করে একটি প্রতিক্রিয়া প্রদান করে

আমি আপনাকে মনে করিয়ে দিই যে আমরা ইতিমধ্যে কোন অনুমানগুলি বিবেচনা করেছি:

হাইপোথিসিস: ভাঙ্গা লাইব্রেরি

• পরীক্ষা 1: সিস্টেমে স্ট্রেস চালান, পরীক্ষা করুন যে ডিগ সঠিক সিস্টেম কল কল করছে
• ফলাফল: সঠিক সিস্টেম কল বলা হয়
• পরীক্ষা 2: আমরা সিস্টেম লাইব্রেরি বাইপাস করে নাম নির্ধারণ করতে পারি কিনা তা পরীক্ষা করতে srapy ব্যবহার করে
• ফলাফল: আমরা পারি
• পরীক্ষা 3: libdns প্যাকেজ এবং md5sum লাইব্রেরি ফাইলগুলিতে rpm –V চালান
• ফলাফল: লাইব্রেরি কোডটি কার্যকারী অপারেটিং সিস্টেমের কোডের সাথে সম্পূর্ণ অভিন্ন
• পরীক্ষা 4: এই আচরণ ছাড়াই ভিএম-এ ব্যবহারকারীর রুট সিস্টেম ইমেজ মাউন্ট করুন, ক্রুট চালান, দেখুন DNS কাজ করে কিনা
• ফলাফল: DNS সঠিকভাবে কাজ করে

পরীক্ষার উপর ভিত্তি করে উপসংহার: সমস্যাটি লাইব্রেরিতে নেই

হাইপোথিসিস: DNS সেটিংসে একটি ত্রুটি রয়েছে

• পরীক্ষা 1: tcpdump চেক করুন এবং দেখুন DNS প্যাকেটগুলি পাঠানো হয়েছে এবং ডিগ চালানোর পরে সঠিকভাবে ফিরে এসেছে কিনা
• ফলাফল: প্যাকেট সঠিকভাবে প্রেরণ করা হয়
• পরীক্ষা 2: সার্ভারে দুবার চেক করুন /etc/nsswitch.conf и /etc/resolv.conf
• ফলাফল: সবকিছু সঠিক

পরীক্ষার উপর ভিত্তি করে উপসংহার: সমস্যাটি DNS কনফিগারেশনের সাথে নয়

হাইপোথিসিস: মূল ক্ষতিগ্রস্ত

• পরীক্ষা: নতুন কার্নেল ইনস্টল করুন, স্বাক্ষর পরীক্ষা করুন, পুনরায় চালু করুন
• ফলাফল: অনুরূপ আচরণ

পরীক্ষার উপর ভিত্তি করে উপসংহার: কার্নেল ক্ষতিগ্রস্ত হয় না

হাইপোথিসিস: ব্যবহারকারী নেটওয়ার্কের ভুল আচরণ (বা হাইপারভাইজার নেটওয়ার্ক ইন্টারফেস)

• পরীক্ষা 1: আপনার ফায়ারওয়াল সেটিংস পরীক্ষা করুন
• ফলাফল: ফায়ারওয়াল হোস্ট এবং জিসিপি উভয়ের উপর ডিএনএস প্যাকেট পাস করে
• পরীক্ষা 2: ট্র্যাফিক আটকান এবং DNS অনুরোধের ট্রান্সমিশন এবং রিটার্নের সঠিকতা নিরীক্ষণ করুন
• ফলাফল: tcpdump নিশ্চিত করে যে হোস্ট রিটার্ন প্যাকেট পেয়েছে

পরীক্ষার উপর ভিত্তি করে উপসংহার: সমস্যা নেটওয়ার্কে নেই

হাইপোথিসিস: মেটাডেটা সার্ভার কাজ করছে না

• পরীক্ষা 1: অসঙ্গতির জন্য মেটাডেটা সার্ভার লগ পরীক্ষা করুন
• ফলাফল: লগগুলিতে কোন অসঙ্গতি নেই
• পরীক্ষা 2: এর মাধ্যমে মেটাডেটা সার্ভার বাইপাস করুন dig @8.8.8.8
• ফলাফল: মেটাডেটা সার্ভার ব্যবহার না করেও রেজোলিউশন ভেঙে গেছে

পরীক্ষার উপর ভিত্তি করে উপসংহার: সমস্যা মেটাডেটা সার্ভারের সাথে নয়

বটম লাইন: আমরা ব্যতীত সমস্ত সাবসিস্টেম পরীক্ষা করেছি রানটাইম সেটিংস!

কার্নেল রানটাইম সেটিংসে ডাইভিং

কার্নেল এক্সিকিউশন এনভায়রনমেন্ট কনফিগার করতে, আপনি কমান্ড লাইন অপশন (grub) বা sysctl ইন্টারফেস ব্যবহার করতে পারেন। আমি ভিতরে তাকালাম /etc/sysctl.conf এবং শুধু মনে করুন, আমি বেশ কয়েকটি কাস্টম সেটিংস আবিষ্কার করেছি। মনে হচ্ছে যেন আমি কিছু একটা ধরে ফেলেছি, আমি সমস্ত নন-নেটওয়ার্ক বা নন-টিসিপি সেটিংস বাতিল করে দিয়েছি, পাহাড়ের সেটিংসের সাথে অবশিষ্ট আছে net.core. তারপরে আমি যেখানে VM-এ হোস্টের অনুমতিগুলি ছিল সেখানে গিয়েছিলাম এবং ভাঙা VM দিয়ে একের পর এক সেটিংস প্রয়োগ করতে শুরু করি, যতক্ষণ না আমি অপরাধীকে খুঁজে পাই:

net.core.rmem_default = 2147483647

এখানে এটি একটি ডিএনএস-ব্রেকিং কনফিগারেশন! খুনের অস্ত্র খুঁজে পেয়েছি। কিন্তু কেন এমন হচ্ছে? আমি এখনও একটি উদ্দেশ্য প্রয়োজন.

মৌলিক DNS প্যাকেট বাফার আকার এর মাধ্যমে কনফিগার করা হয় net.core.rmem_default. একটি সাধারণ মান প্রায় 200KiB হয়, কিন্তু যদি আপনার সার্ভার প্রচুর DNS প্যাকেট পায়, তাহলে আপনি বাফারের আকার বাড়াতে চাইতে পারেন। একটি নতুন প্যাকেট আসার সময় যদি বাফারটি পূর্ণ হয়, উদাহরণস্বরূপ কারণ অ্যাপ্লিকেশনটি যথেষ্ট দ্রুত প্রক্রিয়া করছে না, তাহলে আপনি প্যাকেটগুলি হারাতে শুরু করবেন। আমাদের ক্লায়েন্ট সঠিকভাবে বাফারের আকার বাড়িয়েছে কারণ তিনি ডেটা হারানোর ভয় পেয়েছিলেন, যেহেতু তিনি DNS প্যাকেটের মাধ্যমে মেট্রিক্স সংগ্রহের জন্য একটি অ্যাপ্লিকেশন ব্যবহার করছেন। তিনি যে মানটি সেট করেছিলেন তা সর্বাধিক সম্ভাব্য ছিল: 231-1 (যদি 231 তে সেট করা হয়, কার্নেলটি "অবৈধ যুক্তি" প্রদান করবে)।

হঠাৎ আমি বুঝতে পারলাম কেন nmap এবং scapy সঠিকভাবে কাজ করেছে: তারা কাঁচা সকেট ব্যবহার করছে! কাঁচা সকেট নিয়মিত সকেট থেকে আলাদা: তারা iptables বাইপাস, এবং তারা বাফার করা হয় না!

কিন্তু কেন "বাফার খুব বড়" সমস্যা সৃষ্টি করে? এটা স্পষ্টভাবে উদ্দেশ্য হিসাবে কাজ করে না.

এই মুহুর্তে আমি একাধিক কার্নেল এবং একাধিক বিতরণে সমস্যাটি পুনরুত্পাদন করতে পারি। সমস্যাটি ইতিমধ্যে 3.x কার্নেলে উপস্থিত হয়েছে এবং এখন এটি 5.x কার্নেলেও উপস্থিত হয়েছে।

প্রকৃতপক্ষে, স্টার্টআপের উপর

sysctl -w net.core.rmem_default=$((2**31-1))

DNS কাজ করা বন্ধ করে দিয়েছে।

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

আমি ইন্সটল করেছি ড্রপওয়াচ, একটি টুল যা আগে ব্যবহার করা উচিত ছিল: এটি দেখায় ঠিক কোথায় কার্নেলে একটি প্যাকেট শেষ হবে। অপরাধী ফাংশন ছিল udp_queue_rcv_skb. আমি কার্নেল উত্সগুলি ডাউনলোড করেছি এবং কয়েকটি যোগ করেছি ক্রিয়া printk প্যাকেটটি ঠিক কোথায় শেষ হয়েছে তা ট্র্যাক করতে। আমি দ্রুত সঠিক অবস্থা খুঁজে পেয়েছি if, এবং কিছু সময়ের জন্য কেবল এটির দিকে তাকিয়ে রইলো, কারণ তখনই অবশেষে সবকিছু মিলে একটি সম্পূর্ণ চিত্রে পরিণত হয়েছিল: 231-1, একটি অর্থহীন সংখ্যা, একটি নন-ওয়ার্কিং ডোমেন... এটি ছিল কোডের একটি অংশ __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

দয়া করে নোট করুন:

• rmem int ধরনের হয়
• size u16 টাইপের (আনসাইন করা ষোল-বিট int) এবং প্যাকেটের আকার সংরক্ষণ করে
• sk->sk_rcybuf int টাইপের এবং বাফার সাইজ সংরক্ষণ করে যা সংজ্ঞা অনুসারে, এর মানের সমান net.core.rmem_default

যখন sk_rcvbuf 231 এ পৌঁছায়, প্যাকেটের আকারের যোগফল হতে পারে পূর্ণসংখ্যা ওভারফ্লো. এবং যেহেতু এটি একটি int, এর মান নেতিবাচক হয়ে যায়, তাই শর্তটি সত্য হয়ে যায় যখন এটি মিথ্যা হওয়া উচিত (আপনি এটি সম্পর্কে আরও পড়তে পারেন লিংক).

ত্রুটি একটি তুচ্ছ উপায়ে সংশোধন করা যেতে পারে: ঢালাই দ্বারা unsigned int. আমি ফিক্স প্রয়োগ করেছি এবং সিস্টেমটি পুনরায় চালু করেছি এবং ডিএনএস আবার কাজ করেছে।

বিজয়ের স্বাদ

আমি আমার অনুসন্ধানগুলি ক্লায়েন্টের কাছে প্রেরণ করেছি এবং প্রেরণ করেছি LKML কার্নেল প্যাচ। আমি সন্তুষ্ট: ধাঁধার প্রতিটি অংশ একসাথে ফিট করে, আমি ঠিক ব্যাখ্যা করতে পারি কেন আমরা যা পর্যবেক্ষণ করেছি তা আমরা পর্যবেক্ষণ করেছি এবং সবচেয়ে গুরুত্বপূর্ণভাবে, আমরা আমাদের টিমওয়ার্কের জন্য ধন্যবাদ সমস্যার সমাধান খুঁজে পেতে সক্ষম হয়েছি!

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

উত্স: www.habr.com