ከጎግል ክላውድ የቴክኒክ ድጋፍ ስለጠፉ የዲ ኤን ኤስ ፓኬቶች ታሪክ

ከጎግል ብሎግ አርታዒ፡ የጎግል ክላውድ ቴክኒካል ሶሉሽንስ (TSE) መሐንዲሶች የድጋፍ ጥያቄዎችን እንዴት እንደሚይዙ አስበህ ታውቃለህ? የ TSE የቴክኒክ ድጋፍ መሐንዲሶች በተጠቃሚ ሪፖርት የተደረጉ የችግር ምንጮችን የመለየት እና የማረም ኃላፊነት አለባቸው። ከእነዚህ ችግሮች መካከል አንዳንዶቹ በጣም ቀላል ናቸው, ነገር ግን አንዳንድ ጊዜ በአንድ ጊዜ የበርካታ መሐንዲሶችን ትኩረት የሚፈልግ ትኬት ያጋጥምዎታል. በዚህ ጽሑፍ ውስጥ ከ TSE ሰራተኞች አንዱ ከቅርብ ጊዜ ልምምዱ ስለ አንድ በጣም አስቸጋሪ ችግር ይነግረናል - የጎደሉ የዲ ኤን ኤስ ፓኬቶች ጉዳይ. በዚህ ታሪክ ውስጥ, መሐንዲሶች ሁኔታውን እንዴት መፍታት እንደቻሉ እና ስህተቱን ሲያስተካክሉ ምን አዲስ ነገር እንደተማሩ እንመለከታለን. ይህ ታሪክ ስለ ስር የሰደደ ሳንካ እንደሚያስተምር ብቻ ሳይሆን የድጋፍ ትኬት በጎግል ክላውድ ስለማስገባት ሂደቶች ግንዛቤን እንደሚሰጥ ተስፋ እናደርጋለን።

መላ መፈለግ ሳይንስ እና ጥበብ ነው። ሁሉም ነገር የሚጀምረው ለስርዓቱ መደበኛ ያልሆነ ባህሪ ምክንያት መላምት በመገንባት ነው, ከዚያ በኋላ ለጥንካሬ ይሞከራል. ሆኖም፣ መላምት ከመቅረባችን በፊት፣ ችግሩን በግልፅ መግለፅ እና በትክክል መቅረጽ አለብን። ጥያቄው በጣም ግልጽ ያልሆነ ከሆነ ሁሉንም ነገር በጥንቃቄ መመርመር ይኖርብዎታል. ይህ የመላ ፍለጋ “ጥበብ” ነው።

በጎግል ክላውድ ስር፣ ጉግል ክላውድ የተጠቃሚዎቹን ግላዊነት ለማረጋገጥ የተቻለውን ሁሉ ስለሚጥር እንደዚህ ያሉ ሂደቶች በጣም ውስብስብ ይሆናሉ። በዚህ ምክንያት የቲኤስኢ መሐንዲሶች የእርስዎን ስርዓቶች የማርትዕ መዳረሻ ወይም ተጠቃሚዎች እንደሚያደርጉት ውቅሮችን በስፋት የመመልከት ችሎታ የላቸውም። ስለዚህ ማናቸውንም መላምቶቻችንን ለመፈተሽ እኛ (መሐንዲሶች) ስርዓቱን በፍጥነት ማሻሻል አንችልም።

አንዳንድ ተጠቃሚዎች በመኪና አገልግሎት ውስጥ እንደ መካኒኮች ሁሉንም ነገር እንደምናስተካክል ያምናሉ እና በቀላሉ የቨርቹዋል ማሽን መታወቂያ እንልካለን ፣ በእውነቱ ግን ሂደቱ በንግግር ቅርጸት ይከናወናል-መረጃ መሰብሰብ ፣ መመስረት እና ማረጋገጥ (ወይም ውድቅ) መላምቶች ፣ እና, በመጨረሻም, የውሳኔ ችግሮች ከደንበኛው ጋር በመገናኘት ላይ የተመሰረቱ ናቸው.

በጥያቄ ውስጥ ያለ ችግር

ዛሬ ጥሩ ፍጻሜ ያለው ታሪክ አለን። የታቀደው ጉዳይ በተሳካ ሁኔታ እንዲፈታ ከሚያደርጉት ምክንያቶች አንዱ ለችግሩ በጣም ዝርዝር እና ትክክለኛ መግለጫ ነው. ከዚህ በታች የመጀመሪያውን ትኬት ቅጂ ማየት ይችላሉ (ሚስጥራዊ መረጃን ለመደበቅ የተስተካከለ)

ይህ መልእክት ለእኛ ብዙ ጠቃሚ መረጃዎችን ይዟል፡-

• የተወሰነ ቪኤም ተለይቷል።
• ችግሩ ራሱ ተጠቁሟል - ዲ ኤን ኤስ አይሰራም
• ችግሩ እራሱን የሚገለጥበት ቦታ ይጠቁማል - ቪኤም እና መያዣ
• ችግሩን ለመለየት ተጠቃሚው የወሰደው እርምጃ ተጠቁሟል።

ጥያቄው የተመዘገበው "P1: Critical Impact - አገልግሎት በምርት ላይ የማይውል" ሲሆን ይህም ማለት ሁኔታውን 24/7 የማያቋርጥ ክትትል በ "ፀሐይን ተከተል" መርሃግብር (በተጨማሪ ማንበብ ይችላሉ) የተጠቃሚ ጥያቄዎች ቅድሚያ የሚሰጡዋቸውን), በእያንዳንዱ የጊዜ ሰቅ ለውጥ ከአንድ የቴክኒክ ድጋፍ ቡድን ወደ ሌላ በማስተላለፍ. እንደውም ችግሩ ዙሪክ ወደሚገኘው ቡድናችን በደረሰ ጊዜ ዓለሙን ዞሮ ነበር። በዚህ ጊዜ ተጠቃሚው የመቀነስ እርምጃዎችን ወስዶ ነበር, ነገር ግን ዋናው መንስኤ ገና ስላልተገኘ, በምርት ውስጥ ያለው ሁኔታ መድገም ፈራ.

ትኬቱ ዙሪክ በደረሰ ጊዜ፣እጃችን ላይ የሚከተለውን መረጃ አግኝተናል።

• ይዘት /etc/hosts
• ይዘት /etc/resolv.conf
• መደምደሚያ iptables-save
• በቡድኑ ተሰብስቧል ngrep pcap ፋይል

በዚህ መረጃ፣ “ምርመራውን” እና የመላ መፈለጊያውን ደረጃ ለመጀመር ተዘጋጅተናል።

የእኛ የመጀመሪያ እርምጃዎች

በመጀመሪያ ደረጃ የሜታዳታ አገልጋይ ምዝግብ ማስታወሻዎችን እና ሁኔታን አረጋግጠናል እና በትክክል እየሰራ መሆኑን አረጋግጠናል. የሜታዳታ አገልጋዩ ለአይ ፒ አድራሻ 169.254.169.254 ምላሽ ይሰጣል እና ከሌሎች ነገሮች በተጨማሪ የጎራ ስሞችን የመቆጣጠር ሃላፊነት አለበት። በተጨማሪም ፋየርዎል ከቪኤም ጋር በትክክል መስራቱን እና እሽጎችን እንደማይከለክል ደግመን አረጋግጠናል።

አንድ ዓይነት እንግዳ ችግር ነበር፡ የ 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()ሆኖም ሁለተኛው በጊዜ ማብቂያ ይቋረጣል

እንደ አለመታደል ሆኖ የፈረቃው መጨረሻ ደርሷል እና ችግሩን ወደሚቀጥለው የሰዓት ዞን ለማሸጋገር እንገደዳለን። ይሁን እንጂ ጥያቄው ለቡድናችን ፍላጎት ቀስቅሷል, እና አንድ የስራ ባልደረባዬ የፒቲን ሞጁሉን በመጠቀም የመጀመሪያውን የዲ ኤን ኤስ ፓኬጅ ለመፍጠር ሐሳብ አቅርቧል.

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())

ይህ ቁራጭ የዲ ኤን ኤስ ፓኬት ይፈጥራል እና ጥያቄውን ወደ ሜታዳታ አገልጋይ ይልካል።

ተጠቃሚው ኮዱን ያካሂዳል, የዲ ኤን ኤስ ምላሽ ይመለሳል, እና አፕሊኬሽኑ ይቀበላል, በኔትወርክ ደረጃ ምንም ችግር እንደሌለ ያረጋግጣል.

ከሌላ "የአለም ዙርያ ጉዞ" በኋላ ጥያቄው ወደ ቡድናችን ይመለሳል እና ጥያቄው ከቦታ ወደ ቦታ መዞር ካቆመ ለተጠቃሚው የበለጠ ምቹ እንደሚሆን በማሰብ ሙሉ በሙሉ ወደ ራሴ አስተላልፋለሁ።

እስከዚያው ድረስ ተጠቃሚው የስርዓቱን ምስል ቅጽበታዊ ገጽ እይታ ለማቅረብ በአክብሮት ይስማማል። ይህ በጣም ጥሩ ዜና ነው: ስርዓቱን እራሴ የመሞከር ችሎታ መላ መፈለግን በጣም ፈጣን ያደርገዋል, ምክንያቱም ተጠቃሚው ትዕዛዞችን እንዲያካሂድ መጠየቅ, ውጤቱን መላክ እና መተንተን ስለሌብኝ, ሁሉንም ነገር እራሴ ማድረግ እችላለሁ!

ባልደረቦቼ ትንሽ ይቀናኛሉኝ ጀመር። ከምሳ በኋላ ስለ ልወጣ እንወያያለን፣ ነገር ግን ምን እየተደረገ እንዳለ ማንም አያውቅም። እንደ እድል ሆኖ, ተጠቃሚው ራሱ ውጤቶቹን ለማቃለል እርምጃዎችን ወስዷል እና አይቸኩልም, ስለዚህ ችግሩን ለመፍታት ጊዜ አለን. እና ምስል ስላለን, እኛን የሚስቡን ማንኛውንም ፈተናዎች ማካሄድ እንችላለን. በጣም ጥሩ!

አንድ እርምጃ ወደኋላ በመመለስ ላይ

ለሲስተም መሐንዲስ የስራ መደቦች በጣም ታዋቂ ከሆኑ የቃለ መጠይቅ ጥያቄዎች አንዱ፡- “በፒንግ ጊዜ ምን ይከሰታል Www.google.com? እጩው ሁሉንም ነገር ከሼል እስከ የተጠቃሚ ቦታ፣ ወደ ስርዓቱ ከርነል እና ከዚያም ወደ አውታረ መረቡ መግለጽ ስለሚያስፈልገው ጥያቄው በጣም ጥሩ ነው። ፈገግ እላለሁ፡ አንዳንድ ጊዜ የቃለ መጠይቅ ጥያቄዎች በእውነተኛ ህይወት ጠቃሚ ይሆናሉ...

ይህንን የሰው ሃይል ጥያቄ አሁን ላለው ችግር ተግባራዊ ለማድረግ ወስኛለሁ። በግምት፣ የዲ ኤን ኤስ ስም ለመወሰን ሲሞክሩ፣ የሚከተለው ይከሰታል።

1. አፕሊኬሽኑ እንደ libdns ያሉ የስርዓት ቤተ-መጽሐፍትን ይጠራል
2. libdns የዲኤንኤስ አገልጋይ ማግኘት ያለበትን የስርዓት ውቅር ይፈትሻል (በሥዕሉ ላይ ይህ 169.254.169.254፣ ሜታዳታ አገልጋይ ነው)
3. libdns የ UDP ሶኬት (SOKET_DGRAM) ለመፍጠር የስርዓት ጥሪዎችን ይጠቀማል እና የ UDP ፓኬቶችን ከዲኤንኤስ ጋር በሁለቱም አቅጣጫዎች ለመላክ
4. በ sysctl በይነገጽ በኩል የ UDP ቁልል በከርነል ደረጃ ማዋቀር ይችላሉ።
5. ከርነል ከሃርድዌር ጋር በመገናኘት ፓኬጆችን በአውታረ መረቡ በአውታረመረብ በይነገጽ በኩል ለማስተላለፍ
6. ሃይፐርቫይዘር ፓኬጁን ያዘ እና ከእሱ ጋር ሲገናኝ ወደ ሜታዳታ አገልጋይ ያስተላልፋል
7. የሜታዳታ አገልጋዩ በአስማት የዲ ኤን ኤስ ስም ይወስናል እና መልሱን በተመሳሳይ ዘዴ ይመልሳል

አስቀድመን የተመለከትናቸውን መላምቶች ላስታውስህ፡-

መላምት፡ የተሰበረ ቤተ መጻሕፍት

• ሙከራ 1፡ በሲስተሙ ውስጥ ስክሪን ያሂዱ፣ ትክክለኛውን የስርዓት ጥሪ የሚጠራውን ቁፋሮ ያረጋግጡ
• ውጤት፡ ትክክለኛ የስርዓት ጥሪዎች ተጠርተዋል።
• ሙከራ 2፡ የስርዓት ቤተ-መጻሕፍትን በማለፍ ስሞችን መወሰን መቻልን ለማረጋገጥ srapyን በመጠቀም
• ውጤት፡ እንችላለን
• ሙከራ 3፡ በlibdns ጥቅል እና md5sum ቤተ-መጽሐፍት ፋይሎች ላይ rpm –V አሂድ
• ውጤት፡ የቤተ መፃህፍቱ ኮድ በስራ ስርዓተ ክወናው ውስጥ ካለው ኮድ ጋር ሙሉ ለሙሉ ተመሳሳይ ነው።
• ሙከራ 4፡ ያለዚህ ባህሪ የተጠቃሚውን ስርወ ስርዓት ምስል በVM ላይ ይጫኑ፣ chroot ን ያሂዱ፣ ዲ ኤን ኤስ የሚሰራ መሆኑን ይመልከቱ።
• ውጤት፡ ዲ ኤን ኤስ በትክክል ይሰራል

በፈተናዎች ላይ የተመሰረተ መደምደሚያ፡- ችግሩ በቤተ መጻሕፍት ውስጥ አይደለም

መላምት፡ በዲኤንኤስ መቼቶች ውስጥ ስህተት አለ።

• ሙከራ 1፡ tcpdumpን ፈትሽ እና ዲ ኤን ኤስ ፓኬጆች ተልከዋል እና ዲግ ከሮጡ በኋላ በትክክል እንደተመለሱ ይመልከቱ
• ውጤት: ፓኬቶች በትክክል ይተላለፋሉ
• ሙከራ 2፡ በአገልጋዩ ላይ ሁለቴ ያረጋግጡ /etc/nsswitch.conf и /etc/resolv.conf
• ውጤት: ሁሉም ነገር ትክክል ነው

በፈተናዎች ላይ የተመሰረተ መደምደሚያ፡- ችግሩ በዲ ኤን ኤስ ውቅር ላይ አይደለም።

መላምት፡ ኮር ተጎድቷል።

• ሙከራ፡ አዲስ ከርነል ጫን፣ ፊርማውን አረጋግጥ፣ እንደገና አስጀምር
• ውጤት: ተመሳሳይ ባህሪ

በፈተናዎች ላይ የተመሰረተ መደምደሚያ፡- ከርነል አልተጎዳም

መላምት፡ የተጠቃሚው አውታረ መረብ የተሳሳተ ባህሪ (ወይም ሃይፐርቫይዘር አውታረ መረብ በይነገጽ)

• ሙከራ 1፡ የፋየርዎል መቼቶችዎን ያረጋግጡ
• ውጤት፡ ፋየርዎል በሁለቱም አስተናጋጅ እና በጂሲፒ ላይ የዲ ኤን ኤስ ፓኬቶችን ያልፋል
• ሙከራ 2፡ ትራፊክን ማቋረጥ እና የዲ ኤን ኤስ ጥያቄዎችን ማስተላለፍ እና መመለስን ትክክለኛነት ይቆጣጠሩ
• ውጤት፡ tcpdump አስተናጋጁ የመመለሻ ጥቅሎችን መቀበሉን ያረጋግጣል

በፈተናዎች ላይ የተመሰረተ መደምደሚያ፡- ችግሩ በአውታረ መረቡ ውስጥ አይደለም

መላምት፡ የሜታዳታ አገልጋዩ እየሰራ አይደለም።

• ሙከራ 1፡ የሜታዳታ አገልጋይ ምዝግብ ማስታወሻዎችን ለስህተት ያረጋግጡ
• ውጤት: በምዝግብ ማስታወሻዎች ውስጥ ምንም ያልተለመዱ ነገሮች የሉም
• ሙከራ 2፡ የሜታዳታ አገልጋይን በ በኩል ማለፍ dig @8.8.8.8
• ውጤት፡ የሜታዳታ አገልጋይ ሳይጠቀሙ እንኳን ውሣኔው ተሰብሯል።

በፈተናዎች ላይ የተመሰረተ መደምደሚያ፡- ችግሩ ከሜታዳታ አገልጋይ ጋር አይደለም።

ዋናው ነጥብ: በስተቀር ሁሉንም ንዑስ ስርዓቶችን ሞክረናል። የሩጫ ጊዜ ቅንብሮች!

ወደ የከርነል የአሂድ ጊዜ ቅንብሮች ጠልቆ መግባት

የከርነል ማስፈጸሚያ አካባቢን ለማዋቀር የትእዛዝ መስመር አማራጮችን (ግሩብ) ወይም የ sysctl በይነገጽን መጠቀም ይችላሉ። ወደ ውስጥ ተመለከትኩ። /etc/sysctl.conf እና እስቲ አስበው፣ ብዙ ብጁ ቅንብሮችን አግኝቻለሁ። የሆነ ነገር ላይ እንደያዝኩ እየተሰማኝ፣ ሁሉንም አውታረ መረብ ያልሆኑ ወይም tcp ያልሆኑ ቅንብሮችን ጣልኩ፣ ከተራራው መቼቶች ጋር ቀረሁ። net.core. ከዚያም የአስተናጋጁ ፈቃዶች በVM ውስጥ ወደነበሩበት ሄድኩ እና ጥፋተኛውን እስካገኝ ድረስ ቅንብሮቹን አንድ በአንድ ፣ አንድ በአንድ ፣ ከተሰበረው ቪኤም ጋር መተግበር ጀመርኩ ።

net.core.rmem_default = 2147483647

እዚህ ነው፣ ዲ ኤን ኤስ የሚሰብር ውቅር! የግድያ መሳሪያውን አገኘሁ። ግን ይህ ለምን እየሆነ ነው? አሁንም ተነሳሽነት ያስፈልገኝ ነበር።

መሰረታዊ የዲ ኤን ኤስ ፓኬት ቋት መጠን የተዋቀረው በ በኩል ነው። net.core.rmem_default. የተለመደው እሴት በ200ኪቢ አካባቢ ነው፣ ነገር ግን አገልጋይዎ ብዙ የዲ ኤን ኤስ ፓኬቶችን ከተቀበለ፣ የቋት መጠኑን መጨመር ይፈልጉ ይሆናል። አዲስ ፓኬት ሲመጣ ማስቀመጫው ሞልቶ ከሆነ፣ ለምሳሌ አፕሊኬሽኑ በበቂ ፍጥነት ስለማይሰራ፣ ከዚያ ፓኬጆችን ማጣት ይጀምራሉ። ደንበኛው በዲ ኤን ኤስ ፓኬቶች ውስጥ መለኪያዎችን ለመሰብሰብ መተግበሪያን ይጠቀም ስለነበር የውሂብ መጥፋትን ስለፈራ የማከማቻውን መጠን በትክክል ጨምሯል። እሱ ያስቀመጠው እሴት ከፍተኛው የሚቻለው ነበር፡ 231-1 (ወደ 231 ከተዋቀረ ከርነሉ "የተሳሳተ ክርክር" ይመለሳል)።

በድንገት nmap እና scapy ለምን በትክክል እንደሰሩ ተገነዘብኩ: ጥሬ ሶኬቶችን እየተጠቀሙ ነበር! ጥሬ ሶኬቶች ከመደበኛ ሶኬቶች ይለያያሉ፡ iptablesን ያልፋሉ፣ እና አልተከለከሉም!

ግን ለምን "ማቆያ በጣም ትልቅ" ችግር ይፈጥራል? እንደታሰበው አይሰራም።

በዚህ ጊዜ ችግሩን በበርካታ ከርነሎች እና በበርካታ ስርጭቶች ላይ እንደገና ማባዛት እችላለሁ. ችግሩ ቀድሞውኑ በ 3.x kernel ላይ ታይቷል እና አሁን ደግሞ በ 5.x ከርነል ላይ ታይቷል.

በእርግጥ ፣ ሲጀመር

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

ዲ ኤን ኤስ መስራት አቁሟል።

የስራ እሴቶችን በቀላል ሁለትዮሽ ፍለጋ ስልተ ቀመር መፈለግ ጀመርኩ እና ስርዓቱ ከ 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. ጥገናውን ተግባራዊ አድርጌ ስርዓቱን እንደገና አስጀምረው እና ዲ ኤን ኤስ እንደገና ሰርቷል።

የድል ጣዕም

ግኝቶቼን ለደንበኛው አስተላልፌ ላክሁ LKML የከርነል ጠጋኝ. ደስ ብሎኛል: እያንዳንዱ የእንቆቅልሽ ክፍል አንድ ላይ ይጣጣማል, የተመለከትነውን ለምን እንደተመለከትን በትክክል ማብራራት እችላለሁ, እና ከሁሉም በላይ, ለቡድን ስራችን ምስጋና ይግባው ለችግሩ መፍትሄ ማግኘት ችለናል!

ጉዳዩ ብርቅ ሆኖ እንደተገኘ ማወቁ ጠቃሚ ነው፣ እና እንደ እድል ሆኖ ከተጠቃሚዎች እንደዚህ ያሉ ውስብስብ ጥያቄዎችን ብዙም አናገኝም።

ምንጭ: hab.com