Google ક્લાઉડ ટેક્નિકલ સપોર્ટમાંથી ગુમ થયેલ DNS પેકેટ વિશેની વાર્તા

Google બ્લોગ સંપાદક તરફથી: શું તમે ક્યારેય વિચાર્યું છે કે Google ક્લાઉડ ટેકનિકલ સોલ્યુશન્સ (TSE) એન્જિનિયરો તમારી સપોર્ટ વિનંતીઓને કેવી રીતે હેન્ડલ કરે છે? TSE ટેકનિકલ સપોર્ટ એન્જિનિયર્સ સમસ્યાના વપરાશકર્તા દ્વારા જાણ કરાયેલા સ્ત્રોતોને ઓળખવા અને સુધારવા માટે જવાબદાર છે. આમાંની કેટલીક સમસ્યાઓ એકદમ સરળ છે, પરંતુ કેટલીકવાર તમને એવી ટિકિટ મળે છે કે જેના પર એક સાથે અનેક એન્જિનિયરોનું ધ્યાન જરૂરી હોય છે. આ લેખમાં, TSE કર્મચારીમાંથી એક અમને તેની તાજેતરની પ્રેક્ટિસમાંથી એક ખૂબ જ મુશ્કેલ સમસ્યા વિશે જણાવશે - ગુમ થયેલ DNS પેકેટનો કેસ. આ વાર્તામાં, આપણે જોઈશું કે એન્જિનિયરો કેવી રીતે પરિસ્થિતિને ઉકેલવામાં વ્યવસ્થાપિત થયા, અને ભૂલ સુધારતી વખતે તેઓએ કઈ નવી વસ્તુઓ શીખી. અમે આશા રાખીએ છીએ કે આ વાર્તા તમને માત્ર ઊંડા બેઠેલા બગ વિશે જ નહીં, પણ Google Cloud સાથે સપોર્ટ ટિકિટ ફાઇલ કરવા માટેની પ્રક્રિયાઓની સમજ પણ આપે છે.

મુશ્કેલીનિવારણ એ વિજ્ઞાન અને કલા બંને છે. તે બધું સિસ્ટમના બિન-માનક વર્તન માટેના કારણ વિશે એક પૂર્વધારણા બાંધવાથી શરૂ થાય છે, જેના પછી તેની શક્તિ માટે પરીક્ષણ કરવામાં આવે છે. જો કે, આપણે કોઈ પૂર્વધારણા ઘડીએ તે પહેલાં, આપણે સમસ્યાને સ્પષ્ટપણે વ્યાખ્યાયિત કરવી જોઈએ અને ચોક્કસ રીતે ઘડવી જોઈએ. જો પ્રશ્ન ખૂબ અસ્પષ્ટ લાગે છે, તો તમારે દરેક વસ્તુનું કાળજીપૂર્વક વિશ્લેષણ કરવું પડશે; આ મુશ્કેલીનિવારણની "કળા" છે.

ગૂગલ ક્લાઉડ હેઠળ, આવી પ્રક્રિયાઓ ઝડપથી વધુ જટિલ બની જાય છે, કારણ કે ગૂગલ ક્લાઉડ તેના વપરાશકર્તાઓની ગોપનીયતાની ખાતરી આપવા માટે શ્રેષ્ઠ પ્રયાસ કરે છે. આને કારણે, TSE એન્જિનિયરોને તમારી સિસ્ટમમાં ફેરફાર કરવાની ઍક્સેસ નથી, કે વપરાશકર્તાઓની જેમ રૂપરેખાંકનોને વ્યાપક રીતે જોવાની ક્ષમતા નથી. તેથી, અમારી કોઈપણ પૂર્વધારણાને ચકાસવા માટે, અમે (એન્જિનિયરો) સિસ્ટમમાં ઝડપથી ફેરફાર કરી શકતા નથી.

કેટલાક વપરાશકર્તાઓ માને છે કે અમે કાર સેવામાં મિકેનિક્સની જેમ બધું ઠીક કરીશું, અને અમને ફક્ત વર્ચ્યુઅલ મશીનની આઈડી મોકલીશું, જ્યારે વાસ્તવમાં પ્રક્રિયા વાતચીતના ફોર્મેટમાં થાય છે: માહિતી એકત્રિત કરવી, રચના કરવી અને પુષ્ટિ કરવી (અથવા રદિયો) પૂર્વધારણાઓ, અને, અંતે, નિર્ણયની સમસ્યાઓ ક્લાયંટ સાથે વાતચીત પર આધારિત છે.

પ્રશ્નમાં સમસ્યા

આજે અમારી પાસે એક સારા અંત સાથે વાર્તા છે. સૂચિત કેસના સફળ નિરાકરણ માટેનું એક કારણ સમસ્યાનું ખૂબ વિગતવાર અને સચોટ વર્ણન છે. નીચે તમે પ્રથમ ટિકિટની નકલ જોઈ શકો છો (ગોપનીય માહિતી છુપાવવા માટે સંપાદિત):

આ સંદેશમાં અમારા માટે ઘણી ઉપયોગી માહિતી છે:

• ચોક્કસ VM ઉલ્લેખિત
• સમસ્યા પોતે જ દર્શાવેલ છે - DNS કામ કરતું નથી
• તે સૂચવવામાં આવે છે કે જ્યાં સમસ્યા પોતાને મેનીફેસ્ટ કરે છે - VM અને કન્ટેનર
• સમસ્યાને ઓળખવા માટે વપરાશકર્તાએ લીધેલા પગલાં સૂચવવામાં આવ્યા છે.

વિનંતી "P1: જટિલ અસર - ઉત્પાદનમાં બિનઉપયોગી સેવા" તરીકે નોંધવામાં આવી હતી, જેનો અર્થ થાય છે "સૂર્યને અનુસરો" યોજના અનુસાર 24/7 પરિસ્થિતિનું સતત નિરીક્ષણ (તમે આ વિશે વધુ વાંચી શકો છો. વપરાશકર્તા વિનંતીઓની પ્રાથમિકતાઓ), દરેક ટાઈમ ઝોન શિફ્ટ સાથે એક ટેક્નિકલ સપોર્ટ ટીમમાંથી બીજી ટીમમાં ટ્રાન્સફર સાથે. વાસ્તવમાં, ઝુરિચમાં અમારી ટીમ સુધી સમસ્યા પહોંચી ત્યાં સુધીમાં, તે વિશ્વભરમાં પરિક્રમા કરી ચૂકી હતી. આ સમય સુધીમાં, વપરાશકર્તાએ ઘટાડાનાં પગલાં લીધાં હતાં, પરંતુ ઉત્પાદનમાં પરિસ્થિતિના પુનરાવર્તનનો ડર હતો, કારણ કે મૂળ કારણ હજુ સુધી શોધાયું ન હતું.

ટિકિટ ઝુરિચ પહોંચી ત્યાં સુધીમાં, અમારી પાસે નીચેની માહિતી પહેલેથી જ હતી:

• સામગ્રી /etc/hosts
• સામગ્રી /etc/resolv.conf
• નિષ્કર્ષ iptables-save
• ટીમ દ્વારા એસેમ્બલ ngrep pcap ફાઇલ

આ ડેટા સાથે, અમે "તપાસ" અને મુશ્કેલીનિવારણનો તબક્કો શરૂ કરવા માટે તૈયાર હતા.

અમારા પ્રથમ પગલાં

સૌ પ્રથમ, અમે મેટાડેટા સર્વરના લોગ અને સ્થિતિ તપાસી અને ખાતરી કરી કે તે યોગ્ય રીતે કાર્ય કરી રહ્યું છે. મેટાડેટા સર્વર IP એડ્રેસ 169.254.169.254 ને પ્રતિસાદ આપે છે અને અન્ય વસ્તુઓની સાથે, ડોમેન નામોને નિયંત્રિત કરવા માટે જવાબદાર છે. અમે બે વાર તપાસ પણ કરી છે કે ફાયરવોલ VM સાથે યોગ્ય રીતે કામ કરે છે અને પેકેટોને અવરોધિત કરતું નથી.

તે એક પ્રકારની વિચિત્ર સમસ્યા હતી: nmap ચેકે UDP પેકેટોના નુકશાન વિશેની અમારી મુખ્ય ધારણાને રદિયો આપ્યો, તેથી અમે માનસિક રીતે ઘણા વધુ વિકલ્પો અને તેને તપાસવાની રીતો સાથે આવ્યા:

• શું પેકેટો પસંદગીપૂર્વક છોડવામાં આવે છે? => iptables નિયમો તપાસો
• શું તે ખૂબ નાનું નથી? એમટીયુ? => આઉટપુટ તપાસો 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? પ્રશ્ન મહાન છે, કારણ કે ઉમેદવારે શેલથી યુઝર સ્પેસ, સિસ્ટમ કર્નલ અને પછી નેટવર્ક સુધી દરેક વસ્તુનું વર્ણન કરવાની જરૂર છે. હું સ્મિત કરું છું: ક્યારેક ઇન્ટરવ્યુના પ્રશ્નો વાસ્તવિક જીવનમાં ઉપયોગી થાય છે...

હું આ HR પ્રશ્નને વર્તમાન સમસ્યા પર લાગુ કરવાનું નક્કી કરું છું. આશરે કહીએ તો, જ્યારે તમે 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: આ વર્તણૂક વિના 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
• પરિણામ: મેટાડેટા સર્વરનો ઉપયોગ કર્યા વિના પણ રિઝોલ્યુશન તૂટી ગયું છે

પરીક્ષણો પર આધારિત નિષ્કર્ષ: સમસ્યા મેટાડેટા સર્વર સાથે નથી

બોટમ લાઇન: અમે સિવાય તમામ સબસિસ્ટમનું પરીક્ષણ કર્યું રનટાઇમ સેટિંગ્સ!

કર્નલ રનટાઇમ સેટિંગ્સમાં ડાઇવિંગ

કર્નલ એક્ઝેક્યુશન પર્યાવરણને રૂપરેખાંકિત કરવા માટે, તમે આદેશ વાક્ય વિકલ્પો (ગ્રુબ) અથવા 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 પ્રકારનું છે અને બફર કદને સંગ્રહિત કરે છે જે, વ્યાખ્યા પ્રમાણે, in ની કિંમતની બરાબર છે net.core.rmem_default

જ્યારે sk_rcvbuf 231 સુધી પહોંચે છે, પેકેટના કદનો સરવાળો કરવાથી પરિણમી શકે છે પૂર્ણાંક ઓવરફ્લો. અને તે પૂર્ણાંક હોવાથી, તેનું મૂલ્ય નકારાત્મક બને છે, તેથી જ્યારે તે ખોટું હોવું જોઈએ ત્યારે સ્થિતિ સાચી બને છે (તમે આ વિશે વધુ વાંચી શકો છો કડી).

ભૂલને તુચ્છ રીતે સુધારી શકાય છે: કાસ્ટિંગ દ્વારા unsigned int. મેં ફિક્સ લાગુ કર્યું અને સિસ્ટમ ફરીથી શરૂ કરી અને DNS ફરીથી કામ કર્યું.

વિજયનો સ્વાદ

મેં મારા તારણો ક્લાયન્ટને ફોરવર્ડ કર્યા અને મોકલ્યા એલકેએમએલ કર્નલ પેચ. હું ખુશ છું: પઝલનો દરેક ભાગ એક સાથે બંધબેસે છે, હું બરાબર સમજાવી શકું છું કે અમે જે અવલોકન કર્યું તે શા માટે અમે જોયું અને સૌથી અગત્યનું, અમે અમારી ટીમ વર્કને આભારી સમસ્યાનો ઉકેલ શોધવામાં સક્ષમ છીએ!

તે ઓળખવા યોગ્ય છે કે કેસ દુર્લભ બન્યો, અને સદભાગ્યે અમને વપરાશકર્તાઓ તરફથી આવી જટિલ વિનંતીઓ ભાગ્યે જ મળે છે.

સોર્સ: www.habr.com