Usa ka istorya bahin sa nawala nga mga DNS packet gikan sa teknikal nga suporta sa Google Cloud

Gikan sa Google Blog Editor: Nakahunahuna ka na ba kung giunsa pagdumala sa mga inhenyero sa Google Cloud Technical Solutions (TSE) ang imong mga hangyo sa suporta? TSE Technical Support Engineers ang responsable sa pag-ila ug pagtul-id sa gi-report sa user nga mga tinubdan sa mga problema. Ang pila sa kini nga mga problema yano ra, apan usahay makit-an nimo ang usa ka tiket nga nanginahanglan atensyon sa daghang mga inhenyero sa usa ka higayon. Niini nga artikulo, usa sa mga empleyado sa TSE ang magsulti kanamo bahin sa usa ka lisud kaayo nga problema gikan sa iyang bag-ong praktis - kaso sa nawala nga DNS packets. Niini nga istorya, atong makita kung giunsa ang mga inhenyero nakahimo sa pagsulbad sa sitwasyon, ug unsa nga bag-ong mga butang ang ilang nakat-unan samtang giayo ang sayup. Kami nanghinaut nga kini nga istorya dili lamang magtudlo kanimo bahin sa usa ka lawom nga bug, apan naghatag usab kanimo og panabut sa mga proseso nga moadto sa pag-file sa usa ka tiket sa suporta sa Google Cloud.

Ang pag-troubleshoot kay siyensya ug arte. Nagsugod ang tanan sa pagtukod sa usa ka pangagpas bahin sa hinungdan sa dili standard nga pamatasan sa sistema, pagkahuman gisulayan kini alang sa kusog. Bisan pa, sa dili pa kita maghimo usa ka hypothesis, kinahanglan naton nga tin-aw nga mahibal-an ug tukma nga maporma ang problema. Kung ang pangutana morag dili klaro, nan kinahanglan nimo nga analisahon pag-ayo ang tanan; Kini ang "arte" sa pag-troubleshoot.

Ubos sa Google Cloud, ang maong mga proseso nahimong mas komplikado, tungod kay ang Google Cloud naningkamot kutob sa mahimo aron magarantiya ang pribasiya sa mga tiggamit niini. Tungod niini, ang mga inhenyero sa TSE walay access sa pag-edit sa imong mga sistema, ni ang abilidad sa pagtan-aw sa mga configuration sama ka lapad sa gibuhat sa mga tiggamit. Busa, aron sulayan ang bisan unsa sa among mga pangagpas, kami (mga inhenyero) dili dali nga makausab sa sistema.

Ang ubang mga tiggamit nagtuo nga among ayohon ang tanan sama sa mekaniko sa usa ka serbisyo sa sakyanan, ug ipadala lang kanamo ang id sa usa ka virtual machine, samtang sa pagkatinuod ang proseso mahitabo sa usa ka panag-istoryahanay nga format: pagkolekta sa impormasyon, pagporma ug pagkumpirma (o pagpanghimakak) mga pangagpas, ug, sa katapusan, ang mga problema sa desisyon gibase sa komunikasyon sa kliyente.

Problema nga gipangutana

Karon kita adunay usa ka istorya nga adunay maayong katapusan. Usa sa mga hinungdan sa malampuson nga pagsulbad sa gisugyot nga kaso mao ang usa ka detalyado kaayo ug tukma nga paghulagway sa problema. Sa ubos makita nimo ang kopya sa unang tiket (gi-edit aron itago ang kompidensyal nga impormasyon):

Kini nga mensahe adunay daghang mapuslanon nga kasayuran alang kanamo:

• Piho nga VM gipiho
• Ang problema mismo gipakita - ang DNS wala molihok
• Gipakita kung diin ang problema nagpakita sa iyang kaugalingon - VM ug sudlanan
• Ang mga lakang nga gihimo sa tiggamit aron mahibal-an ang problema gipakita.

Ang hangyo girehistro isip "P1: Kritikal nga Epekto - Serbisyo Dili Magamit sa produksiyon", nga nagpasabot sa kanunay nga pagmonitor sa sitwasyon 24/7 sumala sa "Sunda ang Adlaw" nga pamaagi (mahimo nimong basahon ang dugang mahitungod sa mga prayoridad sa mga hangyo sa tiggamit), uban sa pagbalhin niini gikan sa usa ka technical support team ngadto sa lain sa matag time zone shift. Sa tinuud, sa panahon nga ang problema nakaabot sa among team sa Zurich, kini nakalibot na sa kalibutan. Niini nga panahon, ang tiggamit mihimo sa mga lakang sa pagpagaan, apan nahadlok nga masubli ang sitwasyon sa produksyon, tungod kay ang hinungdan nga hinungdan wala pa madiskobrehi.

Sa pag-abot sa tiket sa Zurich, aduna na kami sa mosunod nga impormasyon:

• Kontento /etc/hosts
• Kontento /etc/resolv.conf
• konklusyon iptables-save
• Gitigom sa team ngrep pcap file

Uban niini nga datos, andam na kami sa pagsugod sa "imbistigasyon" ug hugna sa pag-troubleshoot.

Ang atong unang mga lakang

Una sa tanan, among gisusi ang mga log ug status sa metadata server ug gisiguro nga kini nagtrabaho sa husto. Ang metadata server motubag sa IP address 169.254.169.254 ug, lakip sa ubang mga butang, maoy responsable sa pagkontrolar sa mga ngalan sa domain. Gisusi usab namo nga ang firewall naglihok sa husto sa VM ug wala mag-block sa mga packet.

Usa kadto ka matang sa katingad-an nga problema: ang pagsusi sa nmap mibalibad sa among nag-unang pangagpas mahitungod sa pagkawala sa mga pakete sa UDP, mao nga kami naghunahuna nga adunay daghang mga kapilian ug mga paagi sa pagsusi niini:

• Ang mga pakete ba gipili nga gihulog? => Susiha ang mga lagda sa iptables
• Dili ba kini gamay kaayo? MTU? => Susihon ang output ip a show
• Ang problema ba makaapekto lamang sa mga pakete sa UDP o TCP usab? => Pagpalayo dig +tcp
• Gibalik ba ang pagkalot nga mga pakete? => Pagpalayo tcpdump
• Nagtrabaho ba ang libdns sa husto? => Pagpalayo strace aron masusi ang pagpasa sa mga pakete sa duha ka direksyon

Dinhi nakahukom kami nga tawagan ang tiggamit aron masulbad ang mga problema nga buhi.

Atol sa tawag kita makahimo sa pagsusi sa pipila ka mga butang:

• Pagkahuman sa daghang mga pagsusi wala namon iapil ang mga lagda sa iptables gikan sa lista sa mga hinungdan
• Gisusi namo ang mga interface sa network ug mga routing table, ug doble-check nga husto ang MTU
• Atong nadiskobrehan kana dig +tcp google.com (TCP) nagtrabaho ingon nga kini kinahanglan, apan dig google.com (UDP) dili molihok
• Gipalayas tcpdump nagtrabaho gihapon dig, among nakita nga ang mga pakete sa UDP gibalik
• Nagdrayb mi strace dig google.com ug atong makita kung giunsa pagkalot sa husto nga pagtawag sendmsg() и recvms(), apan ang ikaduha nabalda sa usa ka timeout

Ikasubo, ang katapusan sa pagbalhin moabut ug napugos kami sa pagpadako sa problema sa sunod nga time zone. Ang hangyo, bisan pa, nakapukaw sa interes sa among team, ug ang usa ka kauban nagsugyot sa paghimo sa inisyal nga DNS package gamit ang scrapy Python module.

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

Kini nga tipik nagmugna og DNS packet ug nagpadala sa hangyo ngadto sa metadata server.

Gipadagan sa user ang code, gibalik ang tubag sa DNS, ug nadawat kini sa aplikasyon, nga nagpamatuod nga wala’y problema sa lebel sa network.

Human sa lain nga "round-the-world trip," ang hangyo mibalik sa among team, ug ako hingpit nga gibalhin kini sa akong kaugalingon, naghunahuna nga kini mahimong mas sayon ​​​​alang sa user kung ang hangyo mohunong sa paglibot sa usa ka dapit ngadto sa usa ka dapit.

Sa kasamtangan, ang user malulotong miuyon sa paghatag og snapshot sa sistema nga larawan. Kini usa ka maayo kaayo nga balita: ang abilidad sa pagsulay sa sistema sa akong kaugalingon naghimo sa pag-troubleshoot nga labi ka paspas, tungod kay dili na nako kinahanglan pangutan-on ang tiggamit sa pagpadagan sa mga mando, ipadala kanako ang mga resulta ug analisahon kini, mahimo nako ang tanan sa akong kaugalingon!

Ang akong mga kauban nagsugod sa pagkasina kanako gamay. Sa paniudto among gihisgutan ang pagkakabig, apan walay usa nga nakahibalo kung unsa ang nahitabo. Maayo na lang, ang tiggamit mismo nakahimo na og mga lakang aron mapagaan ang mga sangputanan ug wala magdali, mao nga kami adunay panahon sa pag-dissect sa problema. Ug tungod kay kami adunay usa ka imahe, mahimo namon nga modagan ang bisan unsang mga pagsulay nga makapainteres kanamo. Nindot!

Mibalik og lakang

Usa sa labing inila nga mga pangutana sa interbyu alang sa mga posisyon sa engineer sa sistema mao ang: "Unsa ang mahitabo kung mag-ping ka www.google.com? Nindot ang pangutana, tungod kay kinahanglan ihulagway sa kandidato ang tanan gikan sa kabhang hangtod sa wanang sa gumagamit, hangtod sa kernel sa sistema ug dayon sa network. Mipahiyom ko: usahay ang mga pangutana sa interbyu mahimong mapuslanon sa tinuod nga kinabuhi...

Nakahukom ko nga gamiton kini nga pangutana sa HR sa usa ka kasamtangan nga problema. Sa kinatibuk-an nga pagsulti, kung imong gisulayan ang pagtino sa usa ka ngalan sa DNS, mahitabo ang mosunod:

1. Ang aplikasyon nagtawag sa usa ka librarya sa sistema sama sa libdns
2. Gisusi sa libdns ang pag-configure sa sistema kung diin kinahanglan nga kontakon ang DNS server (sa diagram kini 169.254.169.254, metadata server)
3. Ang libdns naggamit sa mga tawag sa sistema sa paghimo og UDP socket (SOKET_DGRAM) ug ipadala ang UDP packet nga adunay DNS nga pangutana sa duha ka direksyon.
4. Pinaagi sa sysctl interface mahimo nimong i-configure ang UDP stack sa lebel sa kernel
5. Ang kernel nakig-interact sa hardware aron ipadala ang mga packet sa network pinaagi sa network interface
6. Ang hypervisor modakop ug mopadala sa packet ngadto sa metadata server sa pagkontak niini
7. Ang metadata server, pinaagi sa salamangka niini, nagtino sa ngalan sa DNS ug nagbalik sa tubag gamit ang parehas nga pamaagi

Tugoti ako nga pahinumdoman ka kung unsa nga mga pangagpas ang nahunahuna na namon:

Hypothesis: Naguba nga mga librarya

• Pagsulay 1: pagdagan strace sa sistema, susiha nga ang pagkalot nagtawag sa husto nga mga tawag sa sistema
• Resulta: Gitawag ang husto nga mga tawag sa sistema
• Pagsulay 2: gamit ang srapy aron masusi kung mahimo ba naton mahibal-an ang mga ngalan nga nag-bypass sa mga librarya sa sistema
• Resulta: mahimo nato
• Pagsulay 3: pagdagan rpm –V sa libdns package ug md5sum library files
• Resulta: ang code sa librarya hingpit nga parehas sa code sa nagtrabaho nga operating system
• Pagsulay 4: i-mount ang imahe sa sistema sa gamut sa gumagamit sa usa ka VM nga wala kini nga pamatasan, pagdagan ang chroot, tan-awa kung nagtrabaho ba ang DNS
• Resulta: Ang DNS nagtrabaho sa husto

Konklusyon base sa mga pagsulay: ang problema wala sa mga librarya

Hypothesis: Adunay sayup sa mga setting sa DNS

• Pagsulay 1: susiha ang tcpdump ug tan-awa kung ang mga DNS packet gipadala ug gibalik sa husto pagkahuman sa pagkalot
• Resulta: ang mga packet gipasa sa husto
• Pagsulay 2: pag-double check sa server /etc/nsswitch.conf и /etc/resolv.conf
• Resulta: ang tanan husto

Konklusyon base sa mga pagsulay: ang problema dili sa DNS configuration

Hypothesis: core nadaot

• Pagsulay: i-install ang bag-ong kernel, susiha ang pirma, i-restart
• Resulta: parehas nga pamatasan

Konklusyon base sa mga pagsulay: ang kernel dili madaot

Hypothesis: sayop nga kinaiya sa user network (o hypervisor network interface)

• Pagsulay 1: Susiha ang imong mga setting sa firewall
• Resulta: ang firewall nagpasa sa mga DNS packet sa host ug GCP
• Pagsulay 2: intercept ang trapiko ug bantayan ang pagkahusto sa pagpasa ug pagbalik sa mga hangyo sa DNS
• Resulta: gipamatud-an sa tcpdump nga ang host nakadawat mga pakete sa pagbalik

Konklusyon base sa mga pagsulay: ang problema wala sa network

Hypothesis: ang metadata server wala magtrabaho

• Pagsulay 1: susiha ang mga log sa metadata server alang sa mga anomaliya
• Resulta: walay anomaliya sa mga log
• Pagsulay 2: I-bypass ang metadata server pinaagi sa dig @8.8.8.8
• Resulta: Naguba ang resolusyon bisan wala gamita ang metadata server

Konklusyon base sa mga pagsulay: ang problema dili sa metadata server

Bottom line: gisulayan namon ang tanan nga mga subsystem gawas mga setting sa runtime!

Pag-dive sa Kernel Runtime Settings

Aron ma-configure ang kernel execution environment, mahimo nimong gamiton ang command line options (grub) o ang sysctl interface. Mitan-aw ko /etc/sysctl.conf ug huna-hunaa lang, nakadiskubre ko og daghang custom settings. Gibati nako nga ingon og nasakpan ko ang usa ka butang, gisalikway nako ang tanan nga mga setting nga dili network o dili tcp, nga nagpabilin sa mga setting sa bukid net.core. Unya miadto ko kung diin ang mga permiso sa host naa sa VM ug gisugdan ang pag-apply sa mga setting sa usag usa, sa usag usa, uban ang nabuak nga VM, hangtod nakit-an nako ang hinungdan:

net.core.rmem_default = 2147483647

Ania kini, usa ka DNS-breaking configuration! Akong nakit-an ang hinagiban sa pagpatay. Apan nganong nahitabo kini? Nagkinahanglan pa kog motibo.

Ang sukaranan nga DNS packet buffer nga gidak-on gi-configure pinaagi sa net.core.rmem_default. Ang usa ka kasagaran nga kantidad anaa sa mga 200KiB, apan kung ang imong server makadawat og daghang mga DNS packet, mahimo nimong dugangan ang buffer size. Kung puno ang buffer kung moabut ang bag-ong pakete, pananglitan tungod kay ang aplikasyon dili igo nga pagproseso niini, nan magsugod ka nga mawala ang mga pakete. Sakto nga gipadako sa among kliyente ang gidak-on sa buffer tungod kay nahadlok siya nga mawala ang datos, tungod kay naggamit siya usa ka aplikasyon alang sa pagkolekta sa mga sukatan pinaagi sa mga pakete sa DNS. Ang kantidad nga iyang gitakda mao ang pinakataas nga posible: 231-1 (kon ibutang sa 231, ang kernel mobalik og "INVALID ARGUMENT").

Sa kalit akong naamgohan ngano nga ang nmap ug scapy nagtrabaho sa husto: naggamit sila og hilaw nga mga socket! Ang mga hilaw nga socket lahi sa naandan nga mga socket: gilaktawan nila ang mga iptable, ug wala sila gibuffer!

Apan nganong ang "buffer sobra ka dako" ang hinungdan sa mga problema? Kini klaro nga dili molihok sama sa gituyo.

Niini nga punto mahimo nakong kopyahon ang problema sa daghang mga kernel ug daghang mga pag-apod-apod. Ang problema nagpakita na sa 3.x kernel ug karon nagpakita usab kini sa 5.x kernel.

Sa pagkatinuod, sa pagsugod

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

Ang DNS mihunong sa pagtrabaho.

Nagsugod ako sa pagpangita alang sa pagtrabaho nga mga kantidad pinaagi sa usa ka yano nga binary search algorithm ug nakit-an nga ang sistema nagtrabaho sa 2147481343, apan kini nga numero usa ka wala’y kahulogan nga hugpong sa mga numero alang kanako. Gisugyot nako ang kliyente nga sulayan kini nga numero, ug siya mitubag nga ang sistema nagtrabaho sa google.com, apan naghatag gihapon og sayup sa ubang mga domain, mao nga gipadayon nako ang akong imbestigasyon.

Gi-install nako dropwatch, usa ka himan nga gigamit unta sa sayo pa: kini nagpakita sa eksakto kung asa sa kernel ang usa ka pakete matapos. Ang hinungdan mao ang function udp_queue_rcv_skb. Gi-download nako ang mga gigikanan sa kernel ug gidugang ang pipila gimbuhaton printk aron masubay kung asa gyud ang packet matapos. Dali nakong nakit-an ang husto nga kahimtang if, ug yanong mitutok niini sulod sa pipila ka panahon, tungod kay niadto nga ang tanan sa katapusan nahiusa ngadto sa usa ka tibuok nga hulagway: 231-1, usa ka walay kahulogan nga numero, usa ka non-working domain... Kini usa ka piraso sa code sa __udp_enqueue_schedule_skb:

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

Palihug timan-i:

• rmem kay sa tipo int
• size kay sa tipo nga u16 (unsigned sixteen-bit int) ug gitipigan ang gidak-on sa pakete
• sk->sk_rcybuf mao ang tipo nga int ug gitipigan ang gidak-on sa buffer nga, sa kahulugan, parehas sa kantidad sa net.core.rmem_default

Kanus-a sk_rcvbuf moduol sa 231, ang pagsumada sa gidak-on sa pakete mahimong moresulta sa integer overflow. Ug tungod kay kini usa ka int, ang bili niini mahimong negatibo, mao nga ang kondisyon mahimong tinuod kung kini kinahanglan nga sayup (mahimo nimong mabasa ang dugang bahin niini sa link).

Ang sayup mahimong matul-id sa usa ka gamay nga paagi: pinaagi sa paghulma unsigned int. Gi-apply nako ang pag-ayo ug gi-restart ang sistema ug ang DNS nagtrabaho pag-usab.

Lami sa kadaugan

Akong gipasa ang akong mga nahibal-an sa kliyente ug gipadala LKML patch sa kernel. Nalipay ko: ang matag piraso sa puzzle motakdo, akong ipasabut sa eksakto kung nganong among naobserbahan ang among naobserbahan, ug labaw sa tanan, nakakaplag kami og solusyon sa problema salamat sa among teamwork!

Angayan nga ilhon nga ang kaso nahimo nga talagsaon, ug maayo na lang nga panagsa ra kami makadawat sa ingon ka komplikado nga mga hangyo gikan sa mga tiggamit.

Source: www.habr.com