Google ക്ലൗഡ് സാങ്കേതിക പിന്തുണയിൽ നിന്ന് നഷ്‌ടമായ DNS പാക്കറ്റുകളെക്കുറിച്ചുള്ള ഒരു സ്റ്റോറി

Google ബ്ലോഗ് എഡിറ്ററിൽ നിന്ന്: Google ക്ലൗഡ് ടെക്നിക്കൽ സൊല്യൂഷൻസ് (TSE) എഞ്ചിനീയർമാർ നിങ്ങളുടെ പിന്തുണാ അഭ്യർത്ഥനകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് നിങ്ങൾ എപ്പോഴെങ്കിലും ചിന്തിച്ചിട്ടുണ്ടോ? ഉപയോക്താക്കൾ റിപ്പോർട്ട് ചെയ്ത പ്രശ്നങ്ങളുടെ ഉറവിടങ്ങൾ തിരിച്ചറിയുന്നതിനും ശരിയാക്കുന്നതിനും TSE സാങ്കേതിക പിന്തുണാ എഞ്ചിനീയർമാർ ഉത്തരവാദികളാണ്. ഈ പ്രശ്നങ്ങളിൽ ചിലത് വളരെ ലളിതമാണ്, എന്നാൽ ചിലപ്പോൾ നിങ്ങൾ ഒരു ടിക്കറ്റ് കാണും, അത് ഒരേസമയം നിരവധി എഞ്ചിനീയർമാരുടെ ശ്രദ്ധ ആവശ്യമാണ്. ഈ ലേഖനത്തിൽ, TSE ജീവനക്കാരിലൊരാൾ തൻ്റെ സമീപകാല പരിശീലനത്തിൽ നിന്ന് വളരെ ബുദ്ധിമുട്ടുള്ള ഒരു പ്രശ്നത്തെക്കുറിച്ച് ഞങ്ങളോട് പറയും - ഡിഎൻഎസ് പാക്കറ്റുകൾ നഷ്ടപ്പെട്ട കേസ്. ഈ കഥയിൽ, എഞ്ചിനീയർമാർ എങ്ങനെ സാഹചര്യം പരിഹരിക്കാൻ കഴിഞ്ഞുവെന്നും പിശക് പരിഹരിക്കുമ്പോൾ അവർ എന്ത് പുതിയ കാര്യങ്ങൾ പഠിച്ചുവെന്നും നമ്മൾ കാണും. ആഴത്തിലുള്ള ഒരു ബഗിനെക്കുറിച്ച് ഈ സ്റ്റോറി നിങ്ങളെ ബോധവൽക്കരിക്കുക മാത്രമല്ല, Google ക്ലൗഡിൽ ഒരു പിന്തുണാ ടിക്കറ്റ് ഫയൽ ചെയ്യുന്ന പ്രക്രിയകളെക്കുറിച്ചുള്ള ഉൾക്കാഴ്ചയും നൽകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

ട്രബിൾഷൂട്ടിംഗ് ഒരു ശാസ്ത്രവും കലയുമാണ്. സിസ്റ്റത്തിൻ്റെ നിലവാരമില്ലാത്ത സ്വഭാവത്തിൻ്റെ കാരണത്തെക്കുറിച്ച് ഒരു സിദ്ധാന്തം കെട്ടിപ്പടുക്കുന്നതിലൂടെയാണ് ഇതെല്ലാം ആരംഭിക്കുന്നത്, അതിനുശേഷം അത് ശക്തിക്കായി പരീക്ഷിക്കപ്പെടുന്നു. എന്നിരുന്നാലും, ഞങ്ങൾ ഒരു സിദ്ധാന്തം രൂപപ്പെടുത്തുന്നതിന് മുമ്പ്, പ്രശ്നം വ്യക്തമായി നിർവചിക്കുകയും കൃത്യമായി രൂപപ്പെടുത്തുകയും വേണം. ചോദ്യം വളരെ അവ്യക്തമാണെന്ന് തോന്നുന്നുവെങ്കിൽ, നിങ്ങൾ എല്ലാം ശ്രദ്ധാപൂർവ്വം വിശകലനം ചെയ്യേണ്ടിവരും; ഇതാണ് ട്രബിൾഷൂട്ടിങ്ങിൻ്റെ "കല".

ഗൂഗിൾ ക്ലൗഡിന് കീഴിൽ, ഗൂഗിൾ ക്ലൗഡ് അതിൻ്റെ ഉപയോക്താക്കളുടെ സ്വകാര്യത ഉറപ്പുനൽകാൻ പരമാവധി ശ്രമിക്കുന്നതിനാൽ, അത്തരം പ്രക്രിയകൾ കൂടുതൽ സങ്കീർണമാകുന്നു. ഇക്കാരണത്താൽ, TSE എഞ്ചിനീയർമാർക്ക് നിങ്ങളുടെ സിസ്റ്റങ്ങൾ എഡിറ്റുചെയ്യാനുള്ള ആക്‌സസ് ഇല്ല, അല്ലെങ്കിൽ ഉപയോക്താക്കൾ ചെയ്യുന്നതുപോലെ കോൺഫിഗറേഷനുകൾ വിശാലമായി കാണാനുള്ള കഴിവും ഇല്ല. അതിനാൽ, ഞങ്ങളുടെ ഏതെങ്കിലും അനുമാനങ്ങൾ പരിശോധിക്കുന്നതിന്, ഞങ്ങൾക്ക് (എഞ്ചിനീയർമാർ) സിസ്റ്റം വേഗത്തിൽ പരിഷ്കരിക്കാൻ കഴിയില്ല.

ചില ഉപയോക്താക്കൾ വിശ്വസിക്കുന്നത് ഞങ്ങൾ ഒരു കാർ സേവനത്തിലെ മെക്കാനിക്‌സ് പോലെയുള്ള എല്ലാം ശരിയാക്കുകയും ഒരു വെർച്വൽ മെഷീൻ്റെ ഐഡി ഞങ്ങൾക്ക് അയയ്‌ക്കുകയും ചെയ്യും, എന്നാൽ വാസ്തവത്തിൽ ഈ പ്രക്രിയ ഒരു സംഭാഷണ ഫോർമാറ്റിലാണ് നടക്കുന്നത്: വിവരങ്ങൾ ശേഖരിക്കുക, രൂപീകരിക്കുകയും സ്ഥിരീകരിക്കുകയും ചെയ്യുക (അല്ലെങ്കിൽ നിരാകരിക്കുക), കൂടാതെ, അവസാനം, ക്ലയൻ്റുമായുള്ള ആശയവിനിമയത്തെ അടിസ്ഥാനമാക്കിയുള്ള തീരുമാനത്തിലെ പ്രശ്നങ്ങൾ.

ചോദ്യത്തിൽ പ്രശ്നം

ഇന്ന് നമുക്ക് ഒരു നല്ല അവസാനം ഉള്ള ഒരു കഥയുണ്ട്. നിർദ്ദിഷ്ട കേസിൻ്റെ വിജയകരമായ പരിഹാരത്തിനുള്ള ഒരു കാരണം പ്രശ്നത്തിൻ്റെ വളരെ വിശദമായതും കൃത്യവുമായ വിവരണമാണ്. ആദ്യ ടിക്കറ്റിൻ്റെ ഒരു പകർപ്പ് നിങ്ങൾക്ക് ചുവടെ കാണാം (രഹസ്യ വിവരങ്ങൾ മറയ്ക്കാൻ എഡിറ്റ് ചെയ്തത്):

ഈ സന്ദേശത്തിൽ ഞങ്ങൾക്ക് ഉപയോഗപ്രദമായ ധാരാളം വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

• നിർദ്ദിഷ്ട VM വ്യക്തമാക്കി
• പ്രശ്നം തന്നെ സൂചിപ്പിച്ചിരിക്കുന്നു - DNS പ്രവർത്തിക്കുന്നില്ല
• പ്രശ്നം എവിടെയാണ് പ്രത്യക്ഷപ്പെടുന്നതെന്ന് സൂചിപ്പിച്ചിരിക്കുന്നു - വിഎമ്മും കണ്ടെയ്നറും
• പ്രശ്നം തിരിച്ചറിയാൻ ഉപയോക്താവ് സ്വീകരിച്ച നടപടികൾ സൂചിപ്പിച്ചിരിക്കുന്നു.

"P1: Critical Impact - Service Unusable in production" എന്ന പേരിലാണ് അഭ്യർത്ഥന രജിസ്റ്റർ ചെയ്തിരിക്കുന്നത്, അതിനർത്ഥം "സൂര്യനെ പിന്തുടരുക" സ്കീം അനുസരിച്ച് സാഹചര്യം 24/7 നിരന്തരം നിരീക്ഷിക്കുക എന്നാണ് (നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം ഉപയോക്തൃ അഭ്യർത്ഥനകളുടെ മുൻഗണനകൾ), ഓരോ സമയ മേഖല ഷിഫ്റ്റിലും ഒരു സാങ്കേതിക പിന്തുണാ ടീമിൽ നിന്ന് മറ്റൊന്നിലേക്ക് അതിൻ്റെ കൈമാറ്റം. വാസ്‌തവത്തിൽ, പ്രശ്‌നം സൂറിച്ചിലെ ഞങ്ങളുടെ ടീമിൽ എത്തിയപ്പോഴേക്കും അത് ലോകം ചുറ്റിക്കഴിഞ്ഞിരുന്നു. ഈ സമയമായപ്പോഴേക്കും, ഉപയോക്താവ് ലഘൂകരണ നടപടികൾ സ്വീകരിച്ചിരുന്നു, പക്ഷേ മൂലകാരണം ഇതുവരെ കണ്ടെത്തിയിട്ടില്ലാത്തതിനാൽ, ഉൽപാദനത്തിലെ സാഹചര്യം ആവർത്തിക്കുമെന്ന് ഭയപ്പെട്ടു.

ടിക്കറ്റ് സൂറിച്ചിൽ എത്തിയപ്പോഴേക്കും, താഴെപ്പറയുന്ന വിവരങ്ങൾ ഞങ്ങളുടെ കയ്യിൽ ഉണ്ടായിരുന്നു:

• ഉള്ളടക്കം /etc/hosts
• ഉള്ളടക്കം /etc/resolv.conf
• തീരുമാനം iptables-save
• സംഘം ഒത്തുകൂടി ngrep pcap ഫയൽ

ഈ ഡാറ്റ ഉപയോഗിച്ച്, "അന്വേഷണവും" ട്രബിൾഷൂട്ടിംഗ് ഘട്ടവും ആരംഭിക്കാൻ ഞങ്ങൾ തയ്യാറായി.

ഞങ്ങളുടെ ആദ്യ പടികൾ

ഒന്നാമതായി, ഞങ്ങൾ മെറ്റാഡാറ്റ സെർവറിൻ്റെ ലോഗുകളും സ്റ്റാറ്റസും പരിശോധിച്ച് അത് ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തി. മെറ്റാഡാറ്റ സെർവർ 169.254.169.254 എന്ന IP വിലാസത്തോട് പ്രതികരിക്കുന്നു, മറ്റ് കാര്യങ്ങളിൽ, ഡൊമെയ്ൻ നാമങ്ങൾ നിയന്ത്രിക്കുന്നതിനുള്ള ഉത്തരവാദിത്തവും ഉണ്ട്. VM-ൽ ഫയർവാൾ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്നും പാക്കറ്റുകൾ തടയുന്നില്ലെന്നും ഞങ്ങൾ രണ്ടുതവണ പരിശോധിച്ചു.

ഇത് ഒരുതരം വിചിത്രമായ പ്രശ്‌നമായിരുന്നു: യുഡിപി പാക്കറ്റുകളുടെ നഷ്ടത്തെക്കുറിച്ചുള്ള ഞങ്ങളുടെ പ്രധാന അനുമാനത്തെ nmap പരിശോധന നിരാകരിച്ചു, അതിനാൽ അവ പരിശോധിക്കുന്നതിനുള്ള നിരവധി ഓപ്ഷനുകളും വഴികളും ഞങ്ങൾ മാനസികമായി കൊണ്ടുവന്നു:

• പാക്കറ്റുകൾ തിരഞ്ഞെടുത്ത് ഉപേക്ഷിക്കുന്നുണ്ടോ? => iptables നിയമങ്ങൾ പരിശോധിക്കുക
• വളരെ ചെറുതല്ലേ? എം.ടി.യു? => ഔട്ട്പുട്ട് പരിശോധിക്കുക ip a show
• പ്രശ്നം യുഡിപി പാക്കറ്റുകളെയോ ടിസിപിയെയോ മാത്രം ബാധിക്കുമോ? => ഓടിക്കുക 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 സിസ്റ്റം കോൺഫിഗറേഷൻ പരിശോധിക്കുന്നു (ഡയഗ്രാമിൽ ഇത് 169.254.169.254 ആണ്, മെറ്റാഡാറ്റ സെർവർ)
3. ഒരു UDP സോക്കറ്റ് (SOKET_DGRAM) സൃഷ്ടിക്കുന്നതിനും രണ്ട് ദിശകളിലേക്കും ഒരു DNS അന്വേഷണത്തോടെ UDP പാക്കറ്റുകൾ അയയ്ക്കുന്നതിനും libdns സിസ്റ്റം കോളുകൾ ഉപയോഗിക്കുന്നു.
4. sysctl ഇൻ്റർഫേസിലൂടെ നിങ്ങൾക്ക് UDP സ്റ്റാക്ക് കേർണൽ തലത്തിൽ ക്രമീകരിക്കാം.
5. നെറ്റ്‌വർക്ക് ഇൻ്റർഫേസ് വഴി നെറ്റ്‌വർക്കിലൂടെ പാക്കറ്റുകൾ കൈമാറാൻ കേർണൽ ഹാർഡ്‌വെയറുമായി സംവദിക്കുന്നു
6. പാക്കറ്റുമായി സമ്പർക്കം പുലർത്തുമ്പോൾ, ഹൈപ്പർവൈസർ അത് മെറ്റാഡാറ്റ സെർവറിലേക്ക് ക്യാച്ച് ചെയ്യുകയും ട്രാൻസ്മിറ്റ് ചെയ്യുകയും ചെയ്യുന്നു
7. മെറ്റാഡാറ്റ സെർവർ, അതിൻ്റെ മാജിക് ഉപയോഗിച്ച്, DNS നാമം നിർണ്ണയിക്കുകയും അതേ രീതി ഉപയോഗിച്ച് ഒരു പ്രതികരണം നൽകുകയും ചെയ്യുന്നു

ഞങ്ങൾ ഇതിനകം പരിഗണിച്ച അനുമാനങ്ങൾ ഏതൊക്കെയാണെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ:

അനുമാനം: തകർന്ന ലൈബ്രറികൾ

• ടെസ്റ്റ് 1: സിസ്റ്റത്തിൽ സ്‌ട്രേസ് പ്രവർത്തിപ്പിക്കുക, ഡിഗ് കോളുകൾ ശരിയായ സിസ്റ്റം കോളുകൾ ആണോ എന്ന് പരിശോധിക്കുക
• ഫലം: ശരിയായ സിസ്റ്റം കോളുകൾ വിളിക്കുന്നു
• ടെസ്റ്റ് 2: സിസ്റ്റം ലൈബ്രറികളെ മറികടന്ന് പേരുകൾ നിർണ്ണയിക്കാൻ കഴിയുമോ എന്ന് പരിശോധിക്കാൻ സ്റാപ്പി ഉപയോഗിക്കുന്നു
• ഫലം: നമുക്ക് കഴിയും
• ടെസ്റ്റ് 3: libdns പാക്കേജിലും md5sum ലൈബ്രറി ഫയലുകളിലും rpm –V പ്രവർത്തിപ്പിക്കുക
• ഫലം: ലൈബ്രറി കോഡ് പ്രവർത്തിക്കുന്ന ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലെ കോഡിന് പൂർണ്ണമായും സമാനമാണ്
• ടെസ്റ്റ് 4: ഈ സ്വഭാവമില്ലാതെ ഉപയോക്താവിൻ്റെ റൂട്ട് സിസ്റ്റം ഇമേജ് VM-ൽ മൗണ്ട് ചെയ്യുക, chroot പ്രവർത്തിപ്പിക്കുക, DNS പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് കാണുക
• ഫലം: DNS ശരിയായി പ്രവർത്തിക്കുന്നു

പരിശോധനകളെ അടിസ്ഥാനമാക്കിയുള്ള നിഗമനം: പ്രശ്നം ലൈബ്രറിയിലല്ല

അനുമാനം: DNS ക്രമീകരണങ്ങളിൽ ഒരു പിശക് ഉണ്ട്

• ടെസ്റ്റ് 1: tcpdump പരിശോധിച്ച്, ഡിഗ് പ്രവർത്തിപ്പിച്ചതിന് ശേഷം DNS പാക്കറ്റുകൾ അയച്ച് കൃത്യമായി തിരിച്ചയച്ചിട്ടുണ്ടോ എന്ന് നോക്കുക
• ഫലം: പാക്കറ്റുകൾ ശരിയായി കൈമാറ്റം ചെയ്യപ്പെടുന്നു
• ടെസ്റ്റ് 2: സെർവറിൽ രണ്ടുതവണ പരിശോധിക്കുക /etc/nsswitch.conf и /etc/resolv.conf
• ഫലം: എല്ലാം ശരിയാണ്

പരിശോധനകളെ അടിസ്ഥാനമാക്കിയുള്ള നിഗമനം: പ്രശ്നം DNS കോൺഫിഗറേഷനിൽ അല്ല

അനുമാനം: കാമ്പ് കേടായി

• ടെസ്റ്റ്: പുതിയ കേർണൽ ഇൻസ്റ്റാൾ ചെയ്യുക, ഒപ്പ് പരിശോധിക്കുക, പുനരാരംഭിക്കുക
• ഫലം: സമാനമായ പെരുമാറ്റം

പരിശോധനകളെ അടിസ്ഥാനമാക്കിയുള്ള നിഗമനം: കേർണലിന് കേടുപാടുകൾ സംഭവിച്ചിട്ടില്ല

അനുമാനം: ഉപയോക്തൃ നെറ്റ്‌വർക്കിൻ്റെ തെറ്റായ പെരുമാറ്റം (അല്ലെങ്കിൽ ഹൈപ്പർവൈസർ നെറ്റ്‌വർക്ക് ഇൻ്റർഫേസ്)

• ടെസ്റ്റ് 1: നിങ്ങളുടെ ഫയർവാൾ ക്രമീകരണങ്ങൾ പരിശോധിക്കുക
• ഫലം: ഹോസ്റ്റിലും ജിസിപിയിലും ഫയർവാൾ ഡിഎൻഎസ് പാക്കറ്റുകൾ കൈമാറുന്നു
• ടെസ്റ്റ് 2: ട്രാഫിക് തടസ്സപ്പെടുത്തുകയും ഡിഎൻഎസ് അഭ്യർത്ഥനകളുടെ പ്രക്ഷേപണത്തിൻ്റെയും റിട്ടേണിൻ്റെയും കൃത്യത നിരീക്ഷിക്കുകയും ചെയ്യുക
• ഫലം: ഹോസ്റ്റിന് റിട്ടേൺ പാക്കറ്റുകൾ ലഭിച്ചുവെന്ന് tcpdump സ്ഥിരീകരിക്കുന്നു

പരിശോധനകളെ അടിസ്ഥാനമാക്കിയുള്ള നിഗമനം: പ്രശ്നം നെറ്റ്വർക്കിൽ അല്ല

അനുമാനം: മെറ്റാഡാറ്റ സെർവർ പ്രവർത്തിക്കുന്നില്ല

• ടെസ്റ്റ് 1: അപാകതകൾക്കായി മെറ്റാഡാറ്റ സെർവർ ലോഗുകൾ പരിശോധിക്കുക
• ഫലം: ലോഗുകളിൽ അപാകതകളൊന്നുമില്ല
• ടെസ്റ്റ് 2: മെറ്റാഡാറ്റ സെർവർ വഴി കടന്നുപോകുക dig @8.8.8.8
• ഫലം: ഒരു മെറ്റാഡാറ്റ സെർവർ ഉപയോഗിക്കാതെ പോലും റെസല്യൂഷൻ തകർന്നിരിക്കുന്നു

പരിശോധനകളെ അടിസ്ഥാനമാക്കിയുള്ള നിഗമനം: പ്രശ്നം മെറ്റാഡാറ്റ സെർവറിലല്ല

താഴത്തെ വരി: ഒഴികെയുള്ള എല്ലാ സബ്സിസ്റ്റങ്ങളും ഞങ്ങൾ പരീക്ഷിച്ചു റൺടൈം ക്രമീകരണങ്ങൾ!

കേർണൽ റൺടൈം ക്രമീകരണങ്ങളിലേക്ക് ഡൈവിംഗ്

കേർണൽ എക്സിക്യൂഷൻ എൻവയോൺമെൻ്റ് ക്രമീകരിക്കുന്നതിന്, നിങ്ങൾക്ക് കമാൻഡ് ലൈൻ ഓപ്ഷനുകൾ (ഗ്രബ്) അല്ലെങ്കിൽ sysctl ഇൻ്റർഫേസ് ഉപയോഗിക്കാം. ഞാൻ അകത്തേക്ക് നോക്കി /etc/sysctl.conf ചിന്തിക്കൂ, ഞാൻ നിരവധി ഇഷ്‌ടാനുസൃത ക്രമീകരണങ്ങൾ കണ്ടെത്തി. എനിക്ക് എന്തോ പിടികിട്ടിയെന്ന തോന്നൽ, മൗണ്ടൻ സെറ്റിംഗ്‌സിനൊപ്പം ശേഷിക്കുന്ന നെറ്റ്‌വർക്ക് അല്ലാത്തതോ ടിസിപി അല്ലാത്തതോ ആയ എല്ലാ ക്രമീകരണങ്ങളും ഞാൻ ഉപേക്ഷിച്ചു. net.core. തുടർന്ന് ഞാൻ VM-ൽ ഹോസ്റ്റ് അനുമതികൾ ഉള്ളിടത്തേക്ക് പോയി, കുറ്റവാളിയെ കണ്ടെത്തുന്നതുവരെ തകർന്ന VM ഉപയോഗിച്ച് ക്രമീകരണങ്ങൾ ഓരോന്നായി പ്രയോഗിക്കാൻ തുടങ്ങി:

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-ൽ പ്രവർത്തിക്കുന്നുവെന്ന് അദ്ദേഹം മറുപടി നൽകി, പക്ഷേ മറ്റ് ഡൊമെയ്‌നുകളിൽ ഒരു പിശക് തുടർന്നു, അതിനാൽ ഞാൻ എൻ്റെ അന്വേഷണം തുടർന്നു.

ഞാൻ ഇൻസ്റ്റാൾ ചെയ്തു ഡ്രോപ്പ് വാച്ച്, നേരത്തെ ഉപയോഗിക്കേണ്ടിയിരുന്ന ഒരു ഉപകരണം: കേർണലിൽ ഒരു പാക്കറ്റ് എവിടെയാണ് അവസാനിക്കുന്നതെന്ന് ഇത് കൃത്യമായി കാണിക്കുന്നു. ചടങ്ങായിരുന്നു കുറ്റം 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 ആണ് (ഒപ്പ് ചെയ്യാത്ത പതിനാറ്-ബിറ്റ് ഇൻറ്റ്) കൂടാതെ പാക്കറ്റ് വലുപ്പം സംഭരിക്കുന്നു
• sk->sk_rcybuf int എന്ന തരത്തിലുള്ളതാണ്, നിർവചനം അനുസരിച്ച്, മൂല്യത്തിന് തുല്യമായ ബഫർ വലുപ്പം സംഭരിക്കുന്നു net.core.rmem_default

എപ്പോൾ sk_rcvbuf 231-നെ സമീപിക്കുന്നു, പാക്കറ്റ് വലുപ്പം സംഗ്രഹിച്ചാൽ ഫലമുണ്ടാകാം പൂർണ്ണസംഖ്യ ഓവർഫ്ലോ. ഇത് ഒരു സംഖ്യയായതിനാൽ, അതിൻ്റെ മൂല്യം നെഗറ്റീവ് ആയിത്തീരുന്നു, അതിനാൽ അത് തെറ്റായിരിക്കുമ്പോൾ വ്യവസ്ഥ ശരിയാകും (ഇതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഇവിടെ കൂടുതൽ വായിക്കാം ലിങ്ക്).

പിശക് നിസ്സാരമായ രീതിയിൽ ശരിയാക്കാം: കാസ്റ്റിംഗ് വഴി unsigned int. ഞാൻ ഫിക്സ് പ്രയോഗിച്ച് സിസ്റ്റം റീസ്റ്റാർട്ട് ചെയ്തു, DNS വീണ്ടും പ്രവർത്തിച്ചു.

വിജയത്തിൻ്റെ രുചി

ഞാൻ എൻ്റെ കണ്ടെത്തലുകൾ ക്ലയൻ്റിന് കൈമാറുകയും അയച്ചു LKML കേർണൽ പാച്ച്. എനിക്ക് സന്തോഷമുണ്ട്: പസിലിൻ്റെ ഓരോ ഭാഗവും പരസ്പരം യോജിക്കുന്നു, എന്തുകൊണ്ടാണ് ഞങ്ങൾ നിരീക്ഷിച്ചതെന്ന് എനിക്ക് കൃത്യമായി വിശദീകരിക്കാൻ കഴിയും, ഏറ്റവും പ്രധാനമായി, ഞങ്ങളുടെ ടീം വർക്കിന് നന്ദി, പ്രശ്നത്തിന് ഒരു പരിഹാരം കണ്ടെത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു!

കേസ് അപൂർവമായി മാറിയെന്ന് തിരിച്ചറിയുന്നത് മൂല്യവത്താണ്, ഭാഗ്യവശാൽ ഉപയോക്താക്കളിൽ നിന്ന് അത്തരം സങ്കീർണ്ണമായ അഭ്യർത്ഥനകൾ ഞങ്ങൾക്ക് വളരെ അപൂർവമായി മാത്രമേ ലഭിക്കൂ.

അവലംബം: www.habr.com