Google Cloud තාක්ෂණික සහාය වෙතින් DNS පැකට් අතුරුදහන් වීම පිළිබඳ කතාවක්

Google Blog Editor වෙතින්: Google Cloud Technical Solutions (TSE) ඉංජිනේරුවන් ඔබගේ සහාය ඉල්ලීම් හසුරුවන්නේ කෙසේදැයි ඔබ කවදා හෝ කල්පනා කර තිබේද? පරිශීලක-වාර්තා කරන ලද ගැටළු මූලාශ්‍ර හඳුනා ගැනීම සහ නිවැරදි කිරීම සඳහා TSE තාක්ෂණික සහාය ඉංජිනේරුවන් වගකිව යුතුය. මෙම ගැටළු වලින් සමහරක් ඉතා සරල ය, නමුත් සමහර විට ඔබට එකවර ඉංජිනේරුවන් කිහිප දෙනෙකුගේ අවධානය අවශ්‍ය ප්‍රවේශ පත්‍රයක් හමු වේ. මෙම ලිපියෙන්, TSE සේවකයෙකු ඔහුගේ මෑතකාලීන පුහුණුවීම් වලින් ඉතා උපක්‍රමශීලී ගැටලුවක් ගැන අපට කියනු ඇත. DNS පැකට් අස්ථානගත වීමේ අවස්ථාව. මෙම කතාවේදී, ඉංජිනේරුවන් තත්වය විසඳීමට සමත් වූ ආකාරය සහ දෝෂය නිවැරදි කිරීමේදී ඔවුන් ඉගෙන ගත් අලුත් දේවල් මොනවාදැයි අපි බලමු. අපි මෙම කතාව ඔබව ගැඹුරු දෝෂයක් ගැන දැනුවත් කරනවා පමණක් නොව, Google Cloud සමඟ ආධාරක ටිකට් පතක් ගොනු කිරීමට යන ක්‍රියාවලීන් පිළිබඳ අවබෝධයක් ලබා දෙනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

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

Google Cloud යටතේ, එවැනි ක්‍රියාවලීන් ඝාතීය ලෙස වඩාත් සංකීර්ණ වේ, මන්ද Google Cloud එහි පරිශීලකයින්ගේ පෞද්ගලිකත්වය සහතික කිරීමට උපරිමයෙන් උත්සාහ කරයි. මේ නිසා, TSE ඉංජිනේරුවන්ට ඔබේ පද්ධති සංස්කරණය කිරීමට ප්‍රවේශයක් හෝ පරිශීලකයන් මෙන් පුළුල් ලෙස වින්‍යාස බැලීමේ හැකියාවක් නොමැත. එබැවින්, අපගේ උපකල්පන කිසිවක් පරීක්ෂා කිරීමට, අපට (ඉංජිනේරුවන්ට) පද්ධතිය ඉක්මනින් වෙනස් කළ නොහැක.

සමහර පරිශීලකයින් විශ්වාස කරන්නේ අපි මෝටර් රථ සේවාවක යාන්ත්‍රික විද්‍යාව වැනි සෑම දෙයක්ම නිවැරදි කර අථත්‍ය යන්ත්‍රයක හැඳුනුම්පත අපට එවන බවයි, නමුත් යථාර්ථයේ දී ක්‍රියාවලිය සංවාදාත්මක ආකෘතියකින් සිදු වේ: තොරතුරු රැස් කිරීම, උපකල්පන සැකසීම සහ තහවුරු කිරීම (හෝ ප්‍රතික්ෂේප කිරීම), සහ, අවසානයේ දී, තීරණයක් ගැටළු සේවාදායකයා සමඟ සන්නිවේදනය මත පදනම් වේ.

ප්රශ්නයේ ගැටලුව

අද අපිට හොඳ අවසානයක් තියෙන කතාවක් තියෙනවා. යෝජිත නඩුව සාර්ථක ලෙස විසඳීම සඳහා එක් හේතුවක් වන්නේ ගැටලුව පිළිබඳ ඉතා සවිස්තරාත්මක හා නිවැරදි විස්තරයකි. පහතින් ඔබට පළමු ප්‍රවේශ පත්‍රයේ පිටපතක් දැකිය හැක (රහස්‍ය තොරතුරු සැඟවීමට සංස්කරණය කර ඇත):

මෙම පණිවිඩයේ අපට ප්‍රයෝජනවත් තොරතුරු රාශියක් අඩංගු වේ:

• නිශ්චිත VM නිශ්චිතව දක්වා ඇත
• ගැටලුව ම පෙන්වා දී ඇත - DNS ක්රියා නොකරයි
• ගැටලුව පෙන්නුම් කරන්නේ කොතැනද යන්න පෙන්වා ඇත - VM සහ බහාලුම්
• ගැටළුව හඳුනා ගැනීමට පරිශීලකයා ගත් පියවර පෙන්වා ඇත.

ඉල්ලීම "P1: Critical Impact - Service Unusable in production" ලෙස ලියාපදිංචි කර ඇත, එයින් අදහස් වන්නේ "Sun Follow the Sun" යෝජනා ක්‍රමයට අනුව 24/7 තත්ත්වය නිරන්තරයෙන් අධීක්ෂණය කිරීමයි (ඔබට මේ ගැන වැඩිදුර කියවිය හැක. පරිශීලක ඉල්ලීම්වල ප්රමුඛතා), එක් එක් කාල කලාප මාරුව සමඟ එක් තාක්ෂණික සහායක කණ්ඩායමකින් තවත් කණ්ඩායමකට එය මාරු කිරීමත් සමඟ. ඇත්ත වශයෙන්ම, ගැටලුව සූරිච් හි අපගේ කණ්ඩායම වෙත ළඟා වන විට, එය දැනටමත් ලෝකය වටා ගමන් කර තිබුණි. මෙම කාලය වන විට, පරිශීලකයා අවම කිරීමේ ක්‍රියාමාර්ග ගෙන ඇති නමුත්, මූල හේතුව තවමත් සොයාගෙන නොමැති බැවින්, නිෂ්පාදනයේ තත්වය නැවත සිදුවනු ඇතැයි බිය විය.

ටිකට් පත සූරිච් වෙත ළඟා වන විට, අප සතුව පහත තොරතුරු දැනටමත් තිබුණි:

• අන්තර්ගතය /etc/hosts
• අන්තර්ගතය /etc/resolv.conf
• නිගමනය iptables-save
• කණ්ඩායම විසින් රැස් කරන ලදී ngrep pcap ගොනුව

මෙම දත්ත සමඟ, අපි "පරීක්ෂණ" සහ දෝශ නිරාකරණ අදියර ආරම්භ කිරීමට සූදානම්ව සිටියෙමු.

අපගේ පළමු පියවර

පළමුවෙන්ම, අපි පාරදත්ත සේවාදායකයේ ලඝු-සටහන් සහ තත්ත්වය පරීක්ෂා කර එය නිවැරදිව ක්‍රියා කරන බවට වග බලා ගත්තෙමු. පාරදත්ත සේවාදායකය 169.254.169.254 IP ලිපිනයට ප්‍රතිචාර දක්වන අතර, වෙනත් දේ අතර, වසම් නාම පාලනය කිරීම සඳහා වගකීම දරයි. ෆයර්වෝලය 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(), කෙසේ වෙතත් දෙවැන්න කල් ඉකුත්වීමකින් බාධා වේ

අවාසනාවන්ත ලෙස, මාරුවේ අවසානය පැමිණෙන අතර ඊළඟ කාල කලාපයට ගැටලුව උත්සන්න කිරීමට අපට බල කෙරෙයි. කෙසේ වෙතත්, ඉල්ලීම අපගේ කණ්ඩායම තුළ උනන්දුවක් ඇති කළ අතර, සගයකු යෝජනා කරන්නේ scrapy Python මොඩියුලය භාවිතයෙන් මූලික 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 ප්රතිචාරය ආපසු ලබා දෙයි, සහ යෙදුම එය ලබා ගනී, ජාල මට්ටමේ කිසිදු ගැටළුවක් නොමැති බව තහවුරු කරයි.

තවත් “ලොව වටා සංචාරයකින්” පසුව, ඉල්ලීම අපගේ කණ්ඩායම වෙත නැවත පැමිණෙන අතර, ඉල්ලීම තැනින් තැනට යාම නතර කළහොත් පරිශීලකයාට වඩාත් පහසු වනු ඇතැයි සිතමින් මම එය සම්පූර්ණයෙන්ම මා වෙත මාරු කරමි.

මේ අතරතුර, පද්ධති රූපයේ සැණරුවක් ලබා දීමට පරිශීලකයා කාරුණිකව එකඟ වේ. මෙය ඉතා ශුභ ආරංචියකි: පද්ධතිය මා විසින්ම පරීක්ෂා කිරීමේ හැකියාව දෝශ නිරාකරණය වඩා වේගවත් කරයි, මන්ද මට තවදුරටත් විධාන ක්‍රියාත්මක කිරීමට, ප්‍රති results ල මට එවීමට සහ ඒවා විශ්ලේෂණය කිරීමට පරිශීලකයාගෙන් ඉල්ලා සිටිය යුතු නැති නිසා, මට සියල්ල තනිවම කළ හැකිය!

මගේ සගයන් මට ටිකක් ඊර්ෂ්‍යා කිරීමට පටන් ගනී. දිවා ආහාරය අතරතුර අපි පරිවර්තනය ගැන සාකච්ඡා කරමු, නමුත් සිදුවන්නේ කුමක්දැයි කිසිවෙකුට අදහසක් නැත. වාසනාවකට මෙන්, පරිශීලකයා විසින්ම ප්‍රතිවිපාක අවම කිරීමට දැනටමත් පියවර ගෙන ඇති අතර ඉක්මන් නොවේ, එබැවින් අපට ගැටලුව විසුරුවා හැරීමට කාලය තිබේ. තවද අපට රූපයක් ඇති බැවින්, අපට උනන්දුවක් දක්වන ඕනෑම පරීක්ෂණයක් සිදු කළ හැකිය. මහා!

අඩියක් පස්සට ගන්නවා

පද්ධති ඉංජිනේරු තනතුරු සඳහා වඩාත් ජනප්‍රිය සම්මුඛ පරීක්ෂණ ප්‍රශ්නවලින් එකක් වන්නේ: “ඔබ ping කරන විට කුමක් සිදුවේද? www.google.com? ප්‍රශ්නය විශිෂ්ටයි, මන්ද අපේක්ෂකයාට කවචයේ සිට පරිශීලක අවකාශය දක්වා, පද්ධති කර්නලය දක්වා සහ පසුව ජාලය දක්වා සෑම දෙයක්ම විස්තර කිරීමට අවශ්‍ය වේ. මම සිනාසෙමි: සමහර විට සම්මුඛ පරීක්ෂණ ප්‍රශ්න සැබෑ ජීවිතයේදී ප්‍රයෝජනවත් වේ ...

මම මෙම මානව සම්පත් ප්‍රශ්නය වත්මන් ගැටලුවකට යෙදීමට තීරණය කරමි. දළ වශයෙන්, ඔබ DNS නමක් තීරණය කිරීමට උත්සාහ කරන විට, පහත සඳහන් දේ සිදු වේ:

1. යෙදුම libdns වැනි පද්ධති පුස්තකාලයක් කැඳවයි
2. libdns එය සම්බන්ධ විය යුතු DNS සේවාදායකයට පද්ධති වින්‍යාසය පරීක්ෂා කරයි (රූප සටහනේ මෙය 169.254.169.254, පාරදත්ත සේවාදායකය)
3. UDP සොකට් (SOKET_DGRAM) නිර්මාණය කිරීමට සහ UDP පැකට් DNS විමසුමක් සමඟ දෙපැත්තටම යැවීමට libdns පද්ධති ඇමතුම් භාවිතා කරයි.
4. sysctl අතුරුමුහුණත හරහා ඔබට UDP තොගය කර්නල් මට්ටමින් වින්‍යාසගත කළ හැක.
5. ජාල අතුරුමුහුණත හරහා ජාලය හරහා පැකට් සම්ප්‍රේෂණය කිරීමට කර්නලය දෘඩාංග සමඟ අන්තර්ක්‍රියා කරයි
6. හයිපර්වයිසර් එය සමඟ සම්බන්ධ වූ විට පැකට්ටුව පාර-දත්ත සේවාදායකයට අල්ලා සම්ප්‍රේෂණය කරයි
7. පාරදත්ත සේවාදායකය, එහි මැජික් මගින්, DNS නම තීරණය කර එම ක්‍රමයම භාවිතා කරමින් ප්‍රතිචාරයක් ලබා දෙයි

අප දැනටමත් සලකා බැලූ උපකල්පන මොනවාදැයි මම ඔබට මතක් කරමි:

උපකල්පනය: කැඩුණු පුස්තකාල

• පරීක්ෂණය 1: පද්ධතිය තුළ ස්ට්‍රේස් ධාවනය කරන්න, නිවැරදි පද්ධති ඇමතුම් ලබා ගන්නේ දැයි පරීක්ෂා කරන්න
• ප්රතිඵලය: නිවැරදි පද්ධති ඇමතුම් කැඳවනු ලැබේ
• පරීක්ෂණය 2: පද්ධති පුස්තකාල මඟහැර අපට නම් තීරණය කළ හැකිද යන්න පරීක්ෂා කිරීමට srapy භාවිතා කිරීම
• ප්රතිඵලය: අපට පුළුවන්
• පරීක්ෂණය 3: libdns පැකේජය සහ md5sum පුස්තකාල ගොනු මත rpm –V ධාවනය කරන්න
• ප්රතිඵලය: පුස්තකාල කේතය වැඩ කරන මෙහෙයුම් පද්ධතියේ කේතයට සම්පූර්ණයෙන්ම සමාන වේ
• පරීක්ෂණය 4: මෙම හැසිරීමෙන් තොරව පරිශීලකයාගේ මූල පද්ධති රූපය VM මත සවි කරන්න, chroot ධාවනය කරන්න, DNS ක්‍රියා කරන්නේ දැයි බලන්න
• ප්රතිඵලය: DNS නිවැරදිව ක්රියා කරයි

පරීක්ෂණ මත පදනම්ව නිගමනය: ප්‍රශ්නය ඇත්තේ පුස්තකාලවල නොවේ

උපකල්පනය: DNS සැකසුම් වල දෝෂයක් ඇත

• පරීක්ෂණය 1: tcpdump පරීක්ෂා කර DNS පැකට් යවා ඩිග් ධාවනය කිරීමෙන් පසු නිවැරදිව ආපසු ලබා දෙන්නේ දැයි බලන්න
• ප්රතිඵලය: පැකට් නිවැරදිව සම්ප්රේෂණය වේ
• පරීක්ෂණය 2: සේවාදායකයේ දෙවරක් පරීක්ෂා කරන්න /etc/nsswitch.conf и /etc/resolv.conf
• ප්රතිඵලය: සියල්ල නිවැරදියි

පරීක්ෂණ මත පදනම්ව නිගමනය: ගැටළුව DNS වින්‍යාසය සමඟ නොවේ

උපකල්පනය: හරයට හානි විය

• පරීක්ෂණය: නව කර්නලය ස්ථාපනය කරන්න, අත්සන පරීක්ෂා කරන්න, නැවත ආරම්භ කරන්න
• ප්රතිඵලය: සමාන හැසිරීම්

පරීක්ෂණ මත පදනම්ව නිගමනය: කර්නලය හානි නොවේ

උපකල්පනය: පරිශීලක ජාලයේ වැරදි හැසිරීම (හෝ හයිපර්වයිසර් ජාල අතුරුමුහුණත)

• පරීක්ෂණය 1: ඔබගේ ෆයර්වෝල් සැකසුම් පරීක්ෂා කරන්න
• ප්‍රතිඵලය: ෆයර්වෝලය සත්කාරක සහ GCP යන දෙකෙහිම DNS පැකට් පසුකරයි
• පරීක්ෂණය 2: ගමනාගමනය බාධා කිරීම සහ DNS ඉල්ලීම් සම්ප්‍රේෂණය සහ ආපසු පැමිණීමේ නිරවද්‍යතාවය නිරීක්ෂණය කිරීම
• ප්රතිඵලය: tcpdump ධාරකයට ආපසු පැකට් ලැබී ඇති බව තහවුරු කරයි

පරීක්ෂණ මත පදනම්ව නිගමනය: ගැටලුව ජාලය තුළ නොවේ

උපකල්පනය: පාරදත්ත සේවාදායකය ක්‍රියා නොකරයි

• පරීක්ෂණය 1: විෂමතා සඳහා පාරදත්ත සේවාදායක ලොග පරීක්ෂා කරන්න
• ප්රතිඵලය: ලඝු-සටහන් වල විෂමතා නොමැත
• පරීක්ෂණය 2: පාරදත්ත සේවාදායකය මගහැර යන්න dig @8.8.8.8
• ප්‍රතිඵලය: පාරදත්ත සේවාදායකයක් භාවිතා නොකර පවා විභේදනය කැඩී ඇත

පරීක්ෂණ මත පදනම්ව නිගමනය: ගැටළුව ඇත්තේ පාරදත්ත සේවාදායකයේ නොවේ

නිගමනය: අපි හැර අනෙකුත් සියලුම උප පද්ධති පරීක්ෂා කළෙමු ධාවන කාල සැකසුම්!

කර්නල් ධාවන කාල සැකසීම් වෙත කිමිදීම

කර්නල් ක්‍රියාත්මක පරිසරය වින්‍යාස කිරීම සඳහා, ඔබට විධාන රේඛා විකල්ප (grub) හෝ sysctl අතුරුමුහුණත භාවිතා කළ හැක. මම ඇතුලට බැලුවා /etc/sysctl.conf සහ සිතන්න, මම අභිරුචි සැකසුම් කිහිපයක් සොයා ගත්තෙමි. මම යම් දෙයක් අල්ලා ගත්තාක් මෙන් හැඟී, මම කඳු සැකසුම් සමඟ ඉතිරිව ඇති ජාල නොවන හෝ tcp නොවන සියලු සැකසුම් ඉවත දැමුවෙමි. net.core. ඊට පස්සේ මම VM එකේ ධාරක අවසර තියෙන තැනට ගිහින් කැඩුනු VM එකත් එක්ක එකින් එක settings දාගන්න පටන් ගත්තා වැරදිකාරයා හොයාගන්නකම්:

net.core.rmem_default = 2147483647

මෙන්න එය, DNS බිඳීමේ වින්‍යාසයක්! මම මිනීමැරුම් ආයුධය සොයාගත්තා. නමුත් මෙය සිදු වන්නේ ඇයි? මට තවමත් චේතනාවක් අවශ්‍ය විය.

මූලික 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 සමඟ ක්‍රියා කළ නමුත් වෙනත් වසම් සමඟ දෝෂයක් ඇති බැවින් මම මගේ පරීක්ෂණය දිගටම කරගෙන ගිය බවයි.

මම ස්ථාපනය කර ඇත dropwatch, කලින් භාවිතා කළ යුතු මෙවලමක්: කර්නලයේ පැකට්ටුවක් අවසන් වන්නේ කොතැනද යන්න එය හරියටම පෙන්වයි. වරදකරු කාර්යය විය 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. මම නිවැරදි කිරීම යොදවා පද්ධතිය නැවත ආරම්භ කළ අතර DNS නැවත ක්‍රියා කළේය.

ජයග්රහණයේ රසය

මම මගේ සොයාගැනීම් සේවාදායකයාට යොමු කර යැව්වෙමි LKML කර්නල් පැච්. මම සතුටු වෙමි: ප්‍රහේලිකාවේ සෑම කැබැල්ලක්ම එකට ගැලපේ, අප නිරීක්ෂණය කළ දේ හරියටම නිරීක්ෂණය කළේ මන්දැයි මට පැහැදිලි කළ හැකිය, වඩාත්ම වැදගත් දෙය නම්, අපගේ කණ්ඩායම් ක්‍රියාකාරිත්වයට ස්තූතිවන්ත වෙමින් ගැටලුවට විසඳුමක් සොයා ගැනීමට අපට හැකි විය!

නඩුව දුර්ලභ බව හඳුනා ගැනීම වටී, වාසනාවකට මෙන් අපට පරිශීලකයින්ගෙන් එවැනි සංකීර්ණ ඉල්ලීම් ලැබෙන්නේ කලාතුරකිනි.

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