Google Cloud laguntza teknikotik DNS paketeen faltari buruzko istorio bat

Google Blog Editor-etik: Galdetu al zara inoiz Google Cloud Technical Solutions (TSE) ingeniariek zure laguntza eskaerak nola kudeatzen dituzten? TSEko laguntza teknikoko ingeniariak erabiltzaileek jakinarazitako arazo-iturriak identifikatu eta zuzentzeaz arduratzen dira. Arazo horietako batzuk nahiko sinpleak dira, baina batzuetan hainbat ingeniariren arreta eskatzen duen txartel batekin egiten duzu topo. Artikulu honetan, TSEko langile batek bere azken praktikako arazo larri bati buruz hitz egingo digu - DNS paketeak falta diren kasua. Istorio honetan, ingeniariek egoera konpontzea nola lortu duten ikusiko dugu, eta akatsa konpondu bitartean zer berri ikasi duten. Espero dugu istorio honek sakoneko akats bati buruz hezitzeaz gain, Google Cloud-en laguntza-txartel bat aurkezteko prozesuei buruzko ikuspegia ere ematea espero dugu.

Arazoak konpontzea zientzia eta artea da. Dena sistemaren portaera ez-estandarraren arrazoiari buruzko hipotesi bat eraikitzen hasten da, eta ondoren indarra probatzen da. Hala ere, hipotesi bat formulatu baino lehen, arazoa argi eta garbi definitu eta zehatz formulatu behar dugu. Galdera lausoegia bada, orduan dena arretaz aztertu beharko duzu; Hau da arazoak konpontzeko "artea".

Google Cloud-en, prozesu horiek esponentzialki konplexuagoak bihurtzen dira, Google Cloud bere erabiltzaileen pribatutasuna bermatzen ahalegintzen baita. Horregatik, TSEko ingeniariek ez dute sarbiderik zure sistemak editatzeko, ezta konfigurazioak erabiltzaileek bezain zabal ikusteko aukerarik ere. Horregatik, gure hipotesiren bat probatzeko, guk (ingeniariek) ezin dugu sistema azkar aldatu.

Erabiltzaile batzuek uste dute dena konponduko dugula kotxe-zerbitzu batean mekanika bezala, eta besterik gabe makina birtual baten id-a bidaliko digutela, errealitatean prozesua elkarrizketa formatuan gertatzen den bitartean: informazioa bildu, hipotesiak osatu eta baieztatu (edo ezeztatu). eta, azkenean, erabaki-arazoak bezeroarekiko komunikazioan oinarritzen dira.

Arazoa zalantzan

Gaur amaiera ona duen istorio bat dugu. Proposatutako kasua arrakastaz konpontzeko arrazoietako bat arazoaren deskribapen oso zehatza eta zehatza da. Jarraian lehen txartelaren kopia bat ikus dezakezu (isilpeko informazioa ezkutatzeko editatua):

Mezu honek informazio baliagarri asko dauka guretzat:

• VM espezifikoa zehaztuta
• Arazoa bera adierazten da - DNS-k ez du funtzionatzen
• Arazoa non agertzen den adierazten da: VM eta edukiontzia
• Erabiltzaileak arazoa identifikatzeko eman dituen urratsak adierazten dira.

Eskaera "P1: Eragin Kritikoa - Zerbitzua Produkzioan erabilezinak" gisa erregistratu zen, hau da, egoeraren etengabeko jarraipena 24/7 "Follow the Sun" eskemaren arabera (gehiago irakurri dezakezu erabiltzaileen eskaeren lehentasunak), ordu-eremu aldaketa bakoitzean laguntza teknikoko talde batetik bestera igarotzearekin. Izan ere, arazoa Zuricheko gure taldera iritsi zenerako, jada mundua inguratu zuen. Ordurako, erabiltzaileak arintzeko neurriak hartu zituen, baina ekoizpenean egoera errepikatzearen beldur zen, arrazoia oraindik aurkitu ez zelako.

Txartela Zurichera iritsi zenerako, informazio hau geneukan esku artean:

• edukien /etc/hosts
• edukien /etc/resolv.conf
• Irteera iptables-save
• Taldeak muntatua ngrep pcap fitxategia

Datu hauekin, “ikerketa” eta arazoak konpontzeko fasea hasteko prest geunden.

Gure lehen urratsak

Lehenik eta behin, metadatuen zerbitzariaren erregistroak eta egoera egiaztatu eta behar bezala funtzionatzen zuela ziurtatu genuen. Metadatu zerbitzariak 169.254.169.254 IP helbideari erantzuten dio eta, besteak beste, domeinu-izenak kontrolatzeaz arduratzen da. Suebakiak VMrekin behar bezala funtzionatzen duela eta paketeak blokeatzen ez dituela ere egiaztatu dugu.

Arazo arraro bat izan zen: nmap egiaztapenak UDP paketeen galerari buruzko gure hipotesi nagusia gezurtatu zuen, beraz, mentalki beste hainbat aukera eta modu aurkitu genituen egiaztatzeko:

• Paketeak selektiboki botatzen al dira? => Egiaztatu iptables arauak
• Ez al da txikiegia? MTU? => Egiaztatu irteera ip a show
• Arazoak UDP paketeei edo TCPri ere eragiten al die? => Alde egin dig +tcp
• Dig sortutako paketeak itzultzen al dira? => Alde egin tcpdump
• libdns-ak behar bezala funtzionatzen al du? => Alde egin strace paketeen transmisioa bi noranzkoetan egiaztatzeko

Hemen erabakitzen dugu erabiltzaileari deitzea arazoak zuzenean konpontzeko.

Deian zehar hainbat gauza egiaztatu ahal izango ditugu:

• Hainbat egiaztapen egin ondoren, iptables arauak arrazoien zerrendatik baztertzen ditugu
• Sareko interfazeak eta bideratze-taulak egiaztatzen ditugu, eta MTU zuzena dela egiaztatzen dugu
• Hori deskubritzen dugu dig +tcp google.com (TCP) behar bezala funtzionatzen du, baina dig google.com (UDP) ez du funtzionatzen
• Alde eginda tcpdump oraindik lanean ari da dig, UDP paketeak itzultzen ari direla aurkitzen dugu
• Gu urruntzen gara strace dig google.com eta ikusten dugu nola zulatu behar bezala deiak sendmsg() и recvms(), ordea, bigarrena denbora-muga batek eten egiten du

Zoritxarrez, txandaren amaiera iristen da eta arazoa hurrengo ordu-eremura igotzera behartuta gaude. Eskaerak, ordea, interesa piztu zuen gure taldean, eta lankide batek hasierako DNS paketea sortzea iradokitzen du scrapy Python modulua erabiliz.

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

Zati honek DNS pakete bat sortzen du eta eskaera metadatuen zerbitzarira bidaltzen du.

Erabiltzaileak kodea exekutatzen du, DNS erantzuna itzultzen da eta aplikazioak jasotzen du, sare mailan arazorik ez dagoela baieztatuz.

Beste “munduari bira” baten ondoren, eskaera gure taldera itzultzen da, eta guztiz transferitzen diot neure buruari, erabiltzailearentzat erosoagoa izango dela pentsatuz eskaera leku batetik bestera ibiltzeari uzten badio.

Bitartean, erabiltzaileak sistemaren irudiaren argazki bat ematea onartzen du. Oso albiste ona da hau: sistema neuk probatzeko gaitasunak arazoak konpontzea askoz azkarrago egiten du, jada ez diodalako erabiltzaileari aginduak exekuta ditzan eskatu behar, emaitzak bidali eta aztertzeko, dena egin dezaket nik!

Nire lankideak inbidia pixka bat ematen hasiak dira. Bazkalondoan konbertsioaz eztabaidatzen dugu, baina inork ez du zer gertatzen ari den ideiarik. Zorionez, erabiltzaileak berak dagoeneko hartu ditu ondorioak arintzeko neurriak eta ez du presarik, beraz, arazoa aztertzeko denbora dugu. Eta irudi bat daukagunez, interesatzen zaizkigun probak egin ditzakegu. Bikaina!

Pauso bat atzera ematea

Sistema-ingeniari postuetarako elkarrizketa-galdera ezagunenetako bat honakoa da: "Zer gertatzen da ping-a egiten duzunean www.google.com? Galdera bikaina da, hautagaiak dena deskribatu behar baitu shell-etik erabiltzailearen espaziora, sistema-kernelera eta gero sarera. Irribarre egiten dut: batzuetan elkarrizketa-galderak bizitza errealean erabilgarriak izaten dira...

HR galdera hau egungo arazo bati aplikatzea erabakitzen dut. Gutxi gorabehera, DNS izena zehazten saiatzen zarenean, hau gertatzen da:

1. Aplikazioak sistemaren liburutegi bati deitzen dio, hala nola libdns
2. libdns-ek sistemaren konfigurazioa zein DNS zerbitzariarekin harremanetan jarri behar duen egiaztatzen du (diagraman hau 169.254.169.254 da, metadatuen zerbitzaria)
3. libdns-ek sistema-deiak erabiltzen ditu UDP socket bat sortzeko (SOKET_DGRAM) eta UDP paketeak bi norabideetan DNS kontsulta batekin bidaltzeko.
4. Sysctl interfazearen bidez UDP pila konfigura dezakezu nukleo mailan
5. Nukleoak hardwarearekin elkarreragiten du sarearen bidez paketeak transmititzeko sareko interfazearen bidez
6. Hipervisoreak paketea harrapatzen eta metadatuen zerbitzariari igortzen dio harekin kontaktuan dagoenean
7. Metadatuen zerbitzariak, bere magiaz, DNS izena zehazten du eta erantzun bat itzultzen du metodo bera erabiliz

Gogora dezadan zer hipotesi kontuan hartu ditugun:

Hipotesia: Hautsitako liburutegiak

• 1. proba: exekutatu strace sisteman, egiaztatu dig-ek sistema dei zuzenak deitzen dituela
• Emaitza: sistema-dei zuzenak deitzen dira
• 2. proba: srapy erabiltzea sistemaren liburutegiak alde batera utziz izenak zehaztu ditzakegun egiaztatzeko
• Emaitza: ahal dugu
• 3. proba: exekutatu rpm –V libdns paketean eta md5sum liburutegiko fitxategietan
• Emaitza: liburutegiaren kodea laneko sistema eragileko kodearen guztiz berdina da
• 4. proba: muntatu erabiltzailearen erro sistemaren irudia VM batean portaera hori gabe, exekutatu chroot, ikusi DNS-k funtzionatzen duen
• Emaitza: DNS-k behar bezala funtzionatzen du

Probetan oinarritutako ondorioa: arazoa ez dago liburutegietan

Hipotesia: errore bat dago DNS ezarpenetan

• 1. proba: egiaztatu tcpdump eta ikusi DNS paketeak behar bezala bidaltzen eta itzultzen diren dig exekutatu ondoren
• Emaitza: paketeak behar bezala transmititzen dira
• 2. proba: egiaztatu zerbitzarian /etc/nsswitch.conf и /etc/resolv.conf
• Emaitza: dena zuzena da

Probetan oinarritutako ondorioa: arazoa ez dago DNS konfigurazioan

Hipotesia: muina kaltetuta

• Proba: instalatu kernel berria, egiaztatu sinadura, berrabiarazi
• Emaitza: antzeko portaera

Probetan oinarritutako ondorioa: nukleoa ez dago kaltetuta

Hipotesia: erabiltzailearen sarearen (edo hipervisor sarearen interfazearen) portaera okerra.

• 1. proba: egiaztatu zure suebakiaren ezarpenak
• Emaitza: suebakiak DNS paketeak pasatzen ditu ostalarian eta GCPan
• 2. proba: trafikoa atzeman eta DNS eskaeren transmisioa eta itzulera zuzena kontrolatu
• Emaitza: tcpdump-ek ostalariak itzultzeko paketeak jaso dituela baieztatzen du

Probetan oinarritutako ondorioa: arazoa ez dago sarean

Hipotesia: metadatuen zerbitzariak ez du funtzionatzen

• 1. proba: egiaztatu metadatuen zerbitzariaren erregistroetan anomaliak dauden
• Emaitza: erregistroetan ez dago anomaliarik
• 2. proba: Saihestu metadatuen zerbitzaria bidez dig @8.8.8.8
• Emaitza: Ebazpena apurtzen da metadatuen zerbitzaririk erabili gabe ere

Probetan oinarritutako ondorioa: arazoa ez dago metadatu zerbitzariarekin

Beheko lerroa: azpisistema guztiak probatu ditugu izan ezik exekuzio-ezarpenak!

Kernel Exekuzio-ezarpenetan murgiltzea

Kernelaren exekuzio ingurunea konfiguratzeko, komando-lerroko aukerak (grub) edo sysctl interfazea erabil ditzakezu. barrura begiratu nuen /etc/sysctl.conf eta pentsa, hainbat ezarpen pertsonalizatu aurkitu ditut. Zerbait heldu izan banintz bezala, sarekoak ez diren edo tcp ez diren ezarpen guztiak baztertu ditut, mendiko ezarpenekin geratuz net.core. Gero, ostalariaren baimenak VMn zeuden tokira joan nintzen eta ezarpenak banan-banan aplikatzen hasi nintzen, bata bestearen atzetik, hautsitako VM-arekin, erruduna aurkitu nuen arte:

net.core.rmem_default = 2147483647

Hona hemen, DNS hausteko konfigurazioa! Hilketa-arma aurkitu nuen. Baina zergatik gertatzen da hau? Motibo bat behar nuen oraindik.

Oinarrizko DNS paketeen buffer-aren tamaina honen bidez konfiguratzen da net.core.rmem_default. Balio arrunta 200 KiB ingurukoa da, baina zure zerbitzariak DNS pakete asko jasotzen baditu, baliteke buffer-aren tamaina handitzea nahi izatea. Buffer-a beteta badago pakete berri bat iristen denean, adibidez, aplikazioak ez duelako behar bezain azkar prozesatzen, orduan paketeak galtzen hasiko zara. Gure bezeroak behar bezala handitu zuen buffer-aren tamaina, datuak galtzearen beldur zelako, DNS paketeen bidez metrikak biltzeko aplikazio bat erabiltzen baitzuen. Ezarri zuen balioa ahalik eta gehien izan zen: 231-1 (231ean ezarriz gero, nukleoak "ARGUMENTO EZ BALIOA") itzuliko du.

Bat-batean konturatu nintzen zergatik funtzionatzen zuten nmap eta scapy behar bezala: socket gordinak erabiltzen ari ziren! Entxufe gordinak socket arruntetatik desberdinak dira: iptableak saihesten dituzte eta ez daude buffer-a!

Baina zergatik sortzen ditu "buffer handiegiak" arazoak? Argi dago ez duela nahi bezala funtzionatzen.

Une honetan arazoa nukleo eta banaketa anitzetan erreproduzitu nezake. Arazoa jada 3.x nukleoan agertu zen eta orain 5.x nukleoan ere agertu da.

Izan ere, martxan jartzean

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

DNS funtzionatzeari utzi zion.

Bilaketa-algoritmo bitar sinple baten bidez lan-balioak bilatzen hasi nintzen eta sistemak 2147481343-rekin funtzionatzen zuela ikusi nuen, baina zenbaki hori zentzurik gabeko zenbaki multzo bat zen niretzat. Bezeroari zenbaki hau probatzea proposatu nion, eta sistemak google.com-ekin funtzionatzen zuela erantzun zidan, baina hala ere beste domeinu batzuekin errore bat eman zuela eta, beraz, ikerketa jarraitu nuen.

Instalatu dut dropwatch, lehenago erabili behar zen tresna: pakete bat nukleoan zehazki non amaitzen den erakusten du. Erruduna funtzioa zen udp_queue_rcv_skb. Nukleoaren iturriak deskargatu eta batzuk gehitu nituen funtzioak printk paketea zehazki non amaitzen den jarraitzeko. Azkar aurkitu nuen baldintza egokia if, eta besterik gabe, denbora batez begira geratu zen, orduantxe batu baitzen azkenean dena argazki oso batean: 231-1, zentzurik gabeko zenbaki bat, funtzionatzen ez duen domeinu bat... Kode zati bat zen. __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

Kontuan izan:

• rmem int motakoa da
• size u16 motakoa da (unsigned seen-bit int) eta paketearen tamaina gordetzen du
• sk->sk_rcybuf int motakoa da eta, definizioz, in balioaren berdina den buffer tamaina gordetzen du net.core.rmem_default

Noiz sk_rcvbuf 231ra hurbiltzen da, paketearen tamainaren batuketak eragin dezake osoko gainezka egitea. Eta int bat denez, bere balioa negatibo bihurtzen da, beraz, baldintza egia bihurtzen da faltsua izan behar denean (honi buruz gehiago irakur dezakezu hemen: link).

Akatsa modu hutsal batean zuzendu daiteke: casting bidez unsigned int. Konponketa aplikatu eta sistema berrabiarazi nuen eta DNS-k berriro funtzionatu zuen.

Garaipenaren zaporea

Nire aurkikuntzak bezeroari bidali eta bidali nizkion LKML nukleoaren adabakia. Pozik nago: puzzlearen pieza guztiak bat egiten dute, zehatz-mehatz azaldu dezaket zergatik ikusi genuen ikusi genuena, eta, batez ere, arazoari irtenbidea aurkitu ahal izan genion talde-lanari esker!

Merezi du aintzat hartzea kasua arraroa izan zela eta, zorionez, oso gutxitan jasotzen ditugu erabiltzaileen eskaera konplexuak.

Iturria: www.habr.com