Google క్లౌడ్ సాంకేతిక మద్దతు నుండి మిస్ అయిన DNS ప్యాకెట్ల గురించిన కథనం

Google బ్లాగ్ ఎడిటర్ నుండి: Google క్లౌడ్ టెక్నికల్ సొల్యూషన్స్ (TSE) ఇంజనీర్లు మీ మద్దతు అభ్యర్థనలను ఎలా నిర్వహిస్తారని మీరు ఎప్పుడైనా ఆలోచిస్తున్నారా? TSE టెక్నికల్ సపోర్ట్ ఇంజనీర్లు వినియోగదారు నివేదించిన సమస్యల మూలాలను గుర్తించడం మరియు సరిదిద్దడం బాధ్యత వహిస్తారు. ఈ సమస్యలలో కొన్ని చాలా సరళమైనవి, కానీ కొన్నిసార్లు మీరు ఒకేసారి అనేక ఇంజనీర్ల దృష్టిని కోరే టిక్కెట్‌ను చూడవచ్చు. ఈ ఆర్టికల్‌లో, TSE ఉద్యోగులలో ఒకరు తన ఇటీవలి ప్రాక్టీస్ నుండి చాలా గమ్మత్తైన సమస్య గురించి మాకు చెబుతారు - DNS ప్యాకెట్లు తప్పిపోయిన సందర్భం. ఈ కథనంలో, ఇంజనీర్లు పరిస్థితిని ఎలా పరిష్కరించగలిగారు మరియు లోపాన్ని పరిష్కరించేటప్పుడు వారు ఏ కొత్త విషయాలను నేర్చుకున్నారో చూద్దాం. ఈ కథనం లోతైన బగ్ గురించి మీకు అవగాహన కల్పించడమే కాకుండా, Google క్లౌడ్‌తో సపోర్ట్ టిక్కెట్‌ను ఫైల్ చేయడంలో జరిగే ప్రక్రియల గురించి మీకు అంతర్దృష్టిని ఇస్తుందని మేము ఆశిస్తున్నాము.

ట్రబుల్షూటింగ్ అనేది సైన్స్ మరియు ఆర్ట్ రెండూ. సిస్టమ్ యొక్క ప్రామాణికం కాని ప్రవర్తనకు కారణం గురించి ఒక పరికల్పనను నిర్మించడంతో ఇది మొదలవుతుంది, దాని తర్వాత అది బలం కోసం పరీక్షించబడుతుంది. అయితే, మేము ఒక పరికల్పనను రూపొందించే ముందు, సమస్యను స్పష్టంగా నిర్వచించాలి మరియు ఖచ్చితంగా రూపొందించాలి. ప్రశ్న చాలా అస్పష్టంగా అనిపిస్తే, మీరు ప్రతిదీ జాగ్రత్తగా విశ్లేషించాలి; ఇది ట్రబుల్షూటింగ్ యొక్క "కళ".

Google క్లౌడ్ కింద, అటువంటి ప్రక్రియలు విపరీతంగా మరింత క్లిష్టంగా మారతాయి, ఎందుకంటే Google క్లౌడ్ దాని వినియోగదారుల గోప్యతకు హామీ ఇవ్వడానికి ఉత్తమంగా ప్రయత్నిస్తుంది. దీని కారణంగా, TSE ఇంజనీర్‌లకు మీ సిస్టమ్‌లను సవరించడానికి యాక్సెస్ లేదు, లేదా వినియోగదారులు చేసేంత విస్తృతంగా కాన్ఫిగరేషన్‌లను వీక్షించే సామర్థ్యం లేదు. అందువల్ల, మా పరికల్పనలలో దేనినైనా పరీక్షించడానికి, మేము (ఇంజనీర్లు) వ్యవస్థను త్వరగా సవరించలేము.

కొంతమంది వినియోగదారులు మేము కార్ సర్వీస్‌లో మెకానిక్స్ వంటి ప్రతిదాన్ని సరిచేస్తాము మరియు మాకు వర్చువల్ మెషీన్ యొక్క idని పంపుతామని నమ్ముతారు, అయితే వాస్తవానికి ఈ ప్రక్రియ సంభాషణ ఆకృతిలో జరుగుతుంది: సమాచారాన్ని సేకరించడం, రూపొందించడం మరియు నిర్ధారించడం (లేదా తిరస్కరించడం) పరికల్పనలు, మరియు, చివరికి, నిర్ణయం సమస్యలు క్లయింట్‌తో కమ్యూనికేషన్‌పై ఆధారపడి ఉంటాయి.

ప్రశ్నలో సమస్య

ఈ రోజు మనకు మంచి ముగింపుతో కూడిన కథ ఉంది. ప్రతిపాదిత కేసు యొక్క విజయవంతమైన పరిష్కారానికి కారణాలలో ఒకటి సమస్య యొక్క చాలా వివరణాత్మక మరియు ఖచ్చితమైన వివరణ. దిగువన మీరు మొదటి టిక్కెట్ కాపీని చూడవచ్చు (గోప్య సమాచారాన్ని దాచడానికి సవరించబడింది):

ఈ సందేశం మాకు చాలా ఉపయోగకరమైన సమాచారాన్ని కలిగి ఉంది:

• నిర్దిష్ట 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)ని సృష్టించడానికి సిస్టమ్ కాల్‌లను ఉపయోగిస్తుంది మరియు UDP ప్యాకెట్‌లను DNS ప్రశ్నతో రెండు దిశలలో పంపుతుంది.
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: మీ ఫైర్‌వాల్ సెట్టింగ్‌లను తనిఖీ చేయండి
• ఫలితం: ఫైర్‌వాల్ హోస్ట్ మరియు GCP రెండింటిలోనూ DNS ప్యాకెట్‌లను పంపుతుంది
• పరీక్ష 2: ట్రాఫిక్‌ను అడ్డగించండి మరియు DNS అభ్యర్థనల ప్రసారం మరియు వాపసు యొక్క ఖచ్చితత్వాన్ని పర్యవేక్షించండి
• ఫలితం: హోస్ట్ రిటర్న్ ప్యాకెట్‌లను స్వీకరించినట్లు tcpdump నిర్ధారిస్తుంది

పరీక్షల ఆధారంగా తీర్మానం: సమస్య నెట్‌వర్క్‌లో లేదు

పరికల్పన: మెటాడేటా సర్వర్ పని చేయడం లేదు

• పరీక్ష 1: క్రమరాహిత్యాల కోసం మెటాడేటా సర్వర్ లాగ్‌లను తనిఖీ చేయండి
• ఫలితం: లాగ్‌లలో క్రమరాహిత్యాలు లేవు
• పరీక్ష 2: మెటాడేటా సర్వర్‌ని బైపాస్ చేయండి dig @8.8.8.8
• ఫలితం: మెటాడేటా సర్వర్‌ని ఉపయోగించకుండా కూడా రిజల్యూషన్ విచ్ఛిన్నమైంది

పరీక్షల ఆధారంగా తీర్మానం: సమస్య మెటాడేటా సర్వర్‌తో లేదు

బాటమ్ లైన్: మేము మినహా అన్ని సబ్‌సిస్టమ్‌లను పరీక్షించాము రన్‌టైమ్ సెట్టింగ్‌లు!

కెర్నల్ రన్‌టైమ్ సెట్టింగ్‌లలోకి ప్రవేశించడం

కెర్నల్ ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్ను కాన్ఫిగర్ చేయడానికి, మీరు కమాండ్ లైన్ ఎంపికలు (grub) లేదా sysctl ఇంటర్ఫేస్ను ఉపయోగించవచ్చు. నేను లోకి చూసాను /etc/sysctl.conf మరియు ఆలోచించండి, నేను అనేక అనుకూల సెట్టింగ్‌లను కనుగొన్నాను. నేను ఏదో పట్టుకున్నట్లుగా భావించి, నేను నెట్‌వర్క్ కాని లేదా tcp కాని సెట్టింగ్‌లన్నింటినీ విస్మరించాను, పర్వత సెట్టింగ్‌లతో మిగిలి ఉన్నాయి net.core. ఆపై నేను VMలో హోస్ట్ అనుమతులు ఉన్న చోటికి వెళ్లి, నేను అపరాధిని కనుగొనే వరకు, విరిగిన VMతో సెట్టింగ్‌లను ఒక్కొక్కటిగా వర్తింపజేయడం ప్రారంభించాను:

net.core.rmem_default = 2147483647

ఇదిగో, DNS-బ్రేకింగ్ కాన్ఫిగరేషన్! నాకు హత్యాయుధం దొరికింది. అయితే ఇలా ఎందుకు జరుగుతోంది? నాకు ఇంకా ప్రేరణ అవసరం.

ప్రాథమిక DNS ప్యాకెట్ బఫర్ పరిమాణం దీని ద్వారా కాన్ఫిగర్ చేయబడింది net.core.rmem_default. ఒక సాధారణ విలువ ఎక్కడో 200KiB ఉంటుంది, కానీ మీ సర్వర్ చాలా DNS ప్యాకెట్‌లను స్వీకరిస్తే, మీరు బఫర్ పరిమాణాన్ని పెంచుకోవచ్చు. కొత్త ప్యాకెట్ వచ్చినప్పుడు బఫర్ నిండి ఉంటే, ఉదాహరణకు అప్లికేషన్ తగినంత వేగంగా ప్రాసెస్ చేయనందున, మీరు ప్యాకెట్‌లను కోల్పోవడం ప్రారంభిస్తారు. మా క్లయింట్ బఫర్ పరిమాణాన్ని సరిగ్గా పెంచాడు ఎందుకంటే అతను డేటా నష్టానికి భయపడతాడు, ఎందుకంటే అతను DNS ప్యాకెట్ల ద్వారా కొలమానాలను సేకరించడానికి ఒక అప్లికేషన్‌ను ఉపయోగిస్తున్నాడు. అతను సెట్ చేసిన విలువ గరిష్టంగా సాధ్యమయ్యేది: 231-1 (231కి సెట్ చేస్తే, కెర్నల్ “చెల్లని వాదన”ని అందిస్తుంది).

nmap మరియు స్కేపీ ఎందుకు సరిగ్గా పని చేస్తున్నాయో అకస్మాత్తుగా నేను గ్రహించాను: అవి ముడి సాకెట్లను ఉపయోగిస్తున్నాయి! ముడి సాకెట్లు సాధారణ సాకెట్ల నుండి భిన్నంగా ఉంటాయి: అవి 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 పూర్ణాంకానికి చెందినది
• size u16 రకం (సంతకం చేయని పదహారు-బిట్ పూర్ణం) మరియు ప్యాకెట్ పరిమాణాన్ని నిల్వ చేస్తుంది
• sk->sk_rcybuf int రకం మరియు బఫర్ పరిమాణాన్ని నిల్వ చేస్తుంది, ఇది నిర్వచనం ప్రకారం, విలువకు సమానం net.core.rmem_default

ఉన్నప్పుడు sk_rcvbuf 231కి చేరుకుంటుంది, ప్యాకెట్ పరిమాణాన్ని సంగ్రహించడం వలన సంభవించవచ్చు పూర్ణాంకం ఓవర్‌ఫ్లో. మరియు అది ఒక పూర్ణాంకం కాబట్టి, దాని విలువ ప్రతికూలంగా మారుతుంది, కనుక ఇది తప్పు అయినప్పుడు పరిస్థితి నిజం అవుతుంది (మీరు దీని గురించి మరింత చదవగలరు లింక్).

లోపం ఒక పనికిమాలిన మార్గంలో సరిదిద్దవచ్చు: కాస్టింగ్ ద్వారా unsigned int. నేను పరిష్కారాన్ని వర్తింపజేసి, సిస్టమ్‌ను పునఃప్రారంభించాను మరియు DNS మళ్లీ పని చేసింది.

విజయం యొక్క రుచి

నేను నా పరిశోధనలను క్లయింట్‌కు ఫార్వార్డ్ చేసి పంపాను LKML కెర్నల్ ప్యాచ్. నేను సంతోషిస్తున్నాను: పజిల్ యొక్క ప్రతి భాగం ఒకదానికొకటి సరిపోతుంది, మేము గమనించిన వాటిని ఎందుకు గమనించామో నేను ఖచ్చితంగా వివరించగలను మరియు ముఖ్యంగా, మా జట్టుకృషికి ధన్యవాదాలు మేము సమస్యకు పరిష్కారాన్ని కనుగొనగలిగాము!

కేసు చాలా అరుదుగా మారిందని గుర్తించడం విలువ, మరియు అదృష్టవశాత్తూ మేము వినియోగదారుల నుండి ఇటువంటి సంక్లిష్ట అభ్యర్థనలను చాలా అరుదుగా స్వీకరిస్తాము.

మూలం: www.habr.com