Stori am becynnau DNS coll o gefnogaeth dechnegol Google Cloud

Gan Olygydd Blog Google: Ydych chi erioed wedi meddwl sut mae peirianwyr Google Cloud Technical Solutions (TSE) yn trin eich ceisiadau cymorth? Mae peirianwyr cymorth technegol TSE yn gyfrifol am nodi a chywiro ffynonellau problemau a adroddir gan ddefnyddwyr. Mae rhai o'r problemau hyn yn eithaf syml, ond weithiau byddwch chi'n dod ar draws tocyn sy'n gofyn am sylw sawl peiriannydd ar unwaith. Yn yr erthygl hon, bydd un o weithwyr TSE yn dweud wrthym am un broblem anodd iawn o'i ymarfer diweddar - achos o becynnau DNS ar goll. Yn y stori hon, byddwn yn gweld sut y llwyddodd y peirianwyr i ddatrys y sefyllfa, a pha bethau newydd a ddysgwyd ganddynt wrth atgyweirio'r gwall. Gobeithiwn y bydd y stori hon nid yn unig yn eich addysgu am fyg dwfn, ond hefyd yn rhoi cipolwg i chi ar y prosesau sy'n mynd i mewn i ffeilio tocyn cymorth gyda Google Cloud.

Mae datrys problemau yn wyddoniaeth ac yn gelfyddyd. Mae'r cyfan yn dechrau gydag adeiladu rhagdybiaeth am y rheswm dros ymddygiad ansafonol y system, ac ar ôl hynny caiff ei brofi am gryfder. Fodd bynnag, cyn i ni lunio rhagdybiaeth, rhaid inni ddiffinio'n glir a llunio'r broblem yn fanwl gywir. Os yw'r cwestiwn yn swnio'n rhy amwys, yna bydd yn rhaid i chi ddadansoddi popeth yn ofalus; Dyma "gelfyddyd" datrys problemau.

O dan Google Cloud, mae prosesau o'r fath yn dod yn fwy cymhleth yn esbonyddol, wrth i Google Cloud wneud ei orau i warantu preifatrwydd ei ddefnyddwyr. Oherwydd hyn, nid oes gan beirianwyr TSE fynediad i olygu eich systemau, na'r gallu i weld ffurfweddiadau mor eang ag sydd gan ddefnyddwyr. Felly, i brofi unrhyw un o'n damcaniaethau, ni allwn ni (peirianwyr) addasu'r system yn gyflym.

Mae rhai defnyddwyr yn credu y byddwn yn trwsio popeth fel mecaneg mewn gwasanaeth ceir, ac yn syml yn anfon id peiriant rhithwir atom, ond mewn gwirionedd mae'r broses yn digwydd mewn fformat sgwrsio: casglu gwybodaeth, ffurfio a chadarnhau (neu wrthbrofi) damcaniaethau, ac, yn y diwedd, mae problemau penderfyniad yn seiliedig ar gyfathrebu â'r cleient.

Problem dan sylw

Heddiw mae gennym stori gyda diweddglo da. Un o'r rhesymau dros ddatrys yr achos arfaethedig yn llwyddiannus yw disgrifiad manwl a chywir iawn o'r broblem. Isod gallwch weld copi o'r tocyn cyntaf (wedi'i olygu i guddio gwybodaeth gyfrinachol):

Mae'r neges hon yn cynnwys llawer o wybodaeth ddefnyddiol i ni:

• VM penodol wedi'i nodi
• Nodir y broblem ei hun - nid yw DNS yn gweithio
• Mae'n cael ei nodi lle mae'r broblem yn amlygu ei hun - VM a cynhwysydd
• Nodir y camau a gymerodd y defnyddiwr i nodi'r broblem.

Cofrestrwyd y cais fel “P1: Effaith Critigol - Gwasanaeth na ellir ei ddefnyddio wrth gynhyrchu”, sy’n golygu monitro’r sefyllfa’n gyson 24/7 yn ôl y cynllun “Dilyn yr Haul” (gallwch ddarllen mwy am blaenoriaethau ceisiadau defnyddwyr), gyda'i drosglwyddo o un tîm cymorth technegol i'r llall gyda phob shifft parth amser. Yn wir, erbyn i'r broblem gyrraedd ein tîm yn Zurich, roedd eisoes wedi mynd o amgylch y byd. Erbyn hyn, roedd y defnyddiwr wedi cymryd mesurau lliniaru, ond roedd yn ofni ailadrodd y sefyllfa wrth gynhyrchu, gan nad oedd yr achos sylfaenol wedi'i ddarganfod eto.

Erbyn i'r tocyn gyrraedd Zurich, roedd gennym eisoes y wybodaeth ganlynol wrth law:

• Cynnwys /etc/hosts
• Cynnwys /etc/resolv.conf
• Allbwn iptables-save
• Wedi'i ymgynnull gan y tîm ngrep ffeil pcap

Gyda'r data hwn, roeddem yn barod i ddechrau'r cam “ymchwiliad” a datrys problemau.

Ein camau cyntaf

Yn gyntaf oll, fe wnaethom wirio logiau a statws y gweinydd metadata a gwneud yn siŵr ei fod yn gweithio'n gywir. Mae'r gweinydd metadata yn ymateb i'r cyfeiriad IP 169.254.169.254 ac, ymhlith pethau eraill, mae'n gyfrifol am reoli enwau parth. Gwnaethom hefyd wirio ddwywaith bod y wal dân yn gweithio'n gywir gyda'r VM ac nad yw'n rhwystro pecynnau.

Roedd yn rhyw fath o broblem ryfedd: roedd y gwiriad nmap yn gwrthbrofi ein prif ddamcaniaeth am golli pecynnau CDU, felly fe wnaethon ni feddwl yn feddyliol am sawl opsiwn arall a ffyrdd o'u gwirio:

• A yw pecynnau'n cael eu gollwng yn ddetholus? => Gwiriwch reolau iptables
• Onid yw'n rhy fach? MTU? => Gwiriwch allbwn ip a show
• A yw'r broblem yn effeithio ar becynnau CDU neu TCP yn unig hefyd? => Gyrrwch i ffwrdd dig +tcp
• A yw pecynnau a gynhyrchir gan gloddio yn cael eu dychwelyd? => Gyrrwch i ffwrdd tcpdump
• Ydy libdns yn gweithio'n gywir? => Gyrrwch i ffwrdd strace i wirio trosglwyddiad pecynnau i'r ddau gyfeiriad

Yma rydyn ni'n penderfynu galw'r defnyddiwr i ddatrys problemau yn fyw.

Yn ystod yr alwad rydym yn gallu gwirio sawl peth:

• Ar ôl sawl gwiriad rydym yn eithrio rheolau iptables o'r rhestr o resymau
• Rydym yn gwirio rhyngwynebau rhwydwaith a thablau llwybro, ac yn gwirio ddwywaith bod yr MTU yn gywir
• Rydym yn darganfod hynny dig +tcp google.com (TCP) yn gweithio fel y dylai, ond dig google.com (CDU) ddim yn gweithio
• Wedi gyrru i ffwrdd tcpdump mae'n dal i weithio dig, canfyddwn fod pecynnau CDU yn cael eu dychwelyd
• Rydyn ni'n gyrru i ffwrdd strace dig google.com a gwelwn mor gloddio yn gywir yn galw sendmsg() и recvms(), fodd bynnag mae terfyn amser yn torri ar draws yr ail un

Yn anffodus, mae diwedd y shifft yn cyrraedd ac rydym yn cael ein gorfodi i uwchgyfeirio'r broblem i'r parth amser nesaf. Fodd bynnag, cododd y cais ddiddordeb yn ein tîm, ac mae cydweithiwr yn awgrymu creu'r pecyn DNS cychwynnol gan ddefnyddio'r modiwl Python sgrapiog.

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

Mae'r darn hwn yn creu pecyn DNS ac yn anfon y cais at y gweinydd metadata.

Mae'r defnyddiwr yn rhedeg y cod, dychwelir yr ymateb DNS, ac mae'r cais yn ei dderbyn, gan gadarnhau nad oes problem ar lefel y rhwydwaith.

Ar ôl “taith rownd-y-byd arall,” mae'r cais yn dychwelyd i'n tîm, ac rwy'n ei drosglwyddo'n llwyr i mi fy hun, gan feddwl y bydd yn fwy cyfleus i'r defnyddiwr os yw'r cais yn stopio cylchu o le i le.

Yn y cyfamser, mae'r defnyddiwr yn garedig yn cytuno i ddarparu ciplun o ddelwedd y system. Mae hyn yn newyddion da iawn: mae'r gallu i brofi'r system fy hun yn gwneud datrys problemau yn llawer cyflymach, oherwydd nid oes raid i mi ofyn i'r defnyddiwr redeg gorchmynion, anfon y canlyniadau ataf a'u dadansoddi, gallaf wneud popeth fy hun!

Mae fy nghydweithwyr yn dechrau eiddigeddu ychydig wrthyf. Dros ginio rydym yn trafod y trosiad, ond does gan neb syniad beth sy'n mynd ymlaen. Yn ffodus, mae'r defnyddiwr ei hun eisoes wedi cymryd mesurau i liniaru'r canlyniadau ac nid yw ar unrhyw frys, felly mae gennym amser i ddadansoddi'r broblem. A chan fod gennym ddelwedd, gallwn gynnal unrhyw brofion sydd o ddiddordeb i ni. Gwych!

Cymryd cam yn ôl

Un o'r cwestiynau cyfweld mwyaf poblogaidd ar gyfer swyddi peirianwyr systemau yw: “Beth sy'n digwydd pan fyddwch chi'n ping www.google.com? Mae'r cwestiwn yn wych, gan fod angen i'r ymgeisydd ddisgrifio popeth o'r gragen i ofod y defnyddiwr, i gnewyllyn y system ac yna i'r rhwydwaith. Rwy'n gwenu: weithiau mae cwestiynau cyfweliad yn troi allan i fod yn ddefnyddiol mewn bywyd go iawn ...

Rwy'n penderfynu cymhwyso'r cwestiwn AD hwn at broblem gyfredol. Yn fras, pan geisiwch bennu enw DNS, mae'r canlynol yn digwydd:

1. Mae'r cymhwysiad yn galw llyfrgell system fel libdns
2. Mae libdns yn gwirio ffurfwedd y system â pha weinydd DNS y dylai gysylltu ag ef (yn y diagram dyma 169.254.169.254, gweinydd metadata)
3. mae libdns yn defnyddio galwadau system i greu soced CDU (SOKET_DGRAM) ac anfon pecynnau CDU gydag ymholiad DNS i'r ddau gyfeiriad
4. Trwy'r rhyngwyneb sysctl gallwch chi ffurfweddu'r pentwr CDU ar lefel y cnewyllyn
5. Mae'r cnewyllyn yn rhyngweithio â'r caledwedd i drosglwyddo pecynnau dros y rhwydwaith trwy'r rhyngwyneb rhwydwaith
6. Mae'r hypervisor yn dal ac yn trosglwyddo'r pecyn i'r gweinydd metadata pan ddaw i gysylltiad ag ef
7. Mae'r gweinydd metadata, yn ôl ei hud, yn pennu'r enw DNS ac yn dychwelyd ymateb gan ddefnyddio'r un dull

Gadewch imi eich atgoffa pa ddamcaniaethau yr ydym eisoes wedi'u hystyried:

Damcaniaeth: Llyfrgelloedd wedi torri

• Prawf 1: rhedeg strace yn y system, gwirio bod cloddio galwadau y system gywir galwadau
• Canlyniad: Gelwir galwadau system gywir
• Prawf 2: defnyddio chwistrell i wirio a allwn bennu enwau osgoi llyfrgelloedd system
• Canlyniad: gallwn
• Prawf 3: rhedeg rpm –V ar y pecyn libdns a ffeiliau llyfrgell md5sum
• Canlyniad: mae cod y llyfrgell yn union yr un fath â'r cod yn y system weithredu weithredol
• Prawf 4: gosod delwedd system wreiddiau'r defnyddiwr ar VM heb yr ymddygiad hwn, rhedeg chroot, gweld a yw DNS yn gweithio
• Canlyniad: Mae DNS yn gweithio'n gywir

Casgliad yn seiliedig ar brofion: nid yw'r broblem yn y llyfrgelloedd

Damcaniaeth: Mae gwall yn y gosodiadau DNS

• Prawf 1: gwiriwch tcpdump a gweld a yw pecynnau DNS yn cael eu hanfon a'u dychwelyd yn gywir ar ôl rhedeg cloddio
• Canlyniad: mae pecynnau'n cael eu trosglwyddo'n gywir
• Prawf 2: gwiriad dwbl ar y gweinydd /etc/nsswitch.conf и /etc/resolv.conf
• Canlyniad: popeth yn gywir

Casgliad yn seiliedig ar brofion: nid yw'r broblem gyda'r ffurfwedd DNS

Damcaniaeth: craidd wedi'i ddifrodi

• Prawf: gosod cnewyllyn newydd, gwirio llofnod, ailgychwyn
• Canlyniad: ymddygiad tebyg

Casgliad yn seiliedig ar brofion: nid yw'r cnewyllyn wedi'i ddifrodi

Damcaniaeth: ymddygiad anghywir y rhwydwaith defnyddwyr (neu ryngwyneb rhwydwaith hypervisor)

• Prawf 1: Gwiriwch eich gosodiadau wal dân
• Canlyniad: mae'r wal dân yn pasio pecynnau DNS ar y gwesteiwr a'r GCP
• Prawf 2: rhyng-gipio traffig a monitro cywirdeb trosglwyddo a dychwelyd ceisiadau DNS
• Canlyniad: tcpdump yn cadarnhau bod y gwesteiwr wedi derbyn pecynnau dychwelyd

Casgliad yn seiliedig ar brofion: nid yw'r broblem yn y rhwydwaith

Damcaniaeth: nid yw'r gweinydd metadata yn gweithio

• Prawf 1: gwiriwch logiau'r gweinydd metadata am anghysondebau
• Canlyniad: nid oes unrhyw anghysondebau yn y boncyffion
• Prawf 2: Osgoi'r gweinydd metadata trwy dig @8.8.8.8
• Canlyniad: Mae datrysiad wedi'i dorri'n gyfartal heb ddefnyddio gweinydd metadata

Casgliad yn seiliedig ar brofion: nid yw'r broblem gyda'r gweinydd metadata

Mae'r llinell waelod: gwnaethom brofi pob is-system ac eithrio gosodiadau amser rhedeg!

Plymio i Gosodiadau Amser Rhedeg Cnewyllyn

I ffurfweddu'r amgylchedd gweithredu cnewyllyn, gallwch ddefnyddio opsiynau llinell orchymyn (grub) neu'r rhyngwyneb sysctl. Edrychais i mewn /etc/sysctl.conf a meddyliwch, darganfyddais sawl gosodiad arferiad. Gan deimlo fel pe bawn i wedi cydio ar rywbeth, fe wnes i gael gwared ar yr holl leoliadau nad ydynt yn rhwydwaith neu nad ydynt yn tcp, gan aros gyda'r gosodiadau mynydd net.core. Yna euthum i ble roedd y caniatâd gwesteiwr yn y VM a dechreuais gymhwyso'r gosodiadau fesul un, un ar ôl y llall, gyda'r VM wedi torri, nes i mi ddod o hyd i'r troseddwr:

net.core.rmem_default = 2147483647

Dyma hi, cyfluniad sy'n torri DNS! Cefais hyd i'r arf llofruddiaeth. Ond pam mae hyn yn digwydd? Roeddwn i angen cymhelliad o hyd.

Mae maint byffer pecyn DNS sylfaenol wedi'i ffurfweddu trwy net.core.rmem_default. Mae gwerth nodweddiadol rhywle o gwmpas 200KiB, ond os yw'ch gweinydd yn derbyn llawer o becynnau DNS, efallai y byddwch am gynyddu maint y byffer. Os yw'r byffer yn llawn pan fydd pecyn newydd yn cyrraedd, er enghraifft oherwydd nad yw'r cais yn ei brosesu'n ddigon cyflym, yna byddwch yn dechrau colli pecynnau. Cynyddodd ein cleient y maint byffer yn gywir oherwydd ei fod yn ofni colli data, gan ei fod yn defnyddio cymhwysiad ar gyfer casglu metrigau trwy becynnau DNS. Y gwerth a osododd oedd yr uchafswm posibl: 231-1 (os caiff ei osod i 231, bydd y cnewyllyn yn dychwelyd “DADL ANNILYS”).

Yn sydyn sylweddolais pam fod nmap a scapy yn gweithio'n gywir: roedden nhw'n defnyddio socedi amrwd! Mae socedi amrwd yn wahanol i socedi arferol: maen nhw'n osgoi iptables, ac nid ydyn nhw wedi'u clustogi!

Ond pam mae "byffer rhy fawr" yn achosi problemau? Mae'n amlwg nad yw'n gweithio fel y bwriadwyd.

Ar y pwynt hwn gallwn atgynhyrchu'r broblem ar gnewyllyn lluosog a dosbarthiadau lluosog. Roedd y broblem eisoes yn ymddangos ar y cnewyllyn 3.x ac yn awr roedd hefyd yn ymddangos ar y cnewyllyn 5.x.

Yn wir, wrth gychwyn

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

Ni wnaeth DNS weithio.

Dechreuais chwilio am werthoedd gweithio trwy algorithm chwilio deuaidd syml a chanfod bod y system yn gweithio gyda 2147481343, ond roedd y rhif hwn yn set ddiystyr o rifau i mi. Awgrymais i'r cleient roi cynnig ar y rhif hwn, ac atebodd fod y system yn gweithio gyda google.com, ond yn dal i roi gwall gyda pharthau eraill, felly fe wnes i barhau â'm hymchwiliad.

Rwyf wedi gosod dropwatch, offeryn y dylid bod wedi'i ddefnyddio'n gynharach: mae'n dangos yn union ble yn y cnewyllyn y mae pecyn yn dod i ben. Y troseddwr oedd y swyddogaeth udp_queue_rcv_skb. Fe wnes i lawrlwytho'r ffynonellau cnewyllyn ac ychwanegu ychydig swyddogaethau printk i olrhain ble yn union y pecyn yn dod i ben i fyny. Fe wnes i ddod o hyd i'r cyflwr cywir yn gyflym if, ac yn syml wedi syllu arno am beth amser, oherwydd dyna pryd y daeth popeth at ei gilydd o'r diwedd i greu darlun cyfan: 231-1, rhif diystyr, parth nad yw'n gweithio... Darn o god ydoedd yn __udp_enqueue_schedule_skb:

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

Noder:

• rmem yn fath int
• size o fath u16 (int un ar bymtheg did heb ei lofnodi) ac yn storio maint y pecyn
• sk->sk_rcybuf Mae o fath int ac yn storio maint byffer sydd, yn ôl diffiniad, yn hafal i'r gwerth yn net.core.rmem_default

Pan fydd sk_rcvbuf yn agosáu at 231, a gallai crynhoi maint y pecyn arwain at hynny gorlif cyfanrif. A chan ei fod yn int, mae ei werth yn dod yn negyddol, felly mae'r cyflwr yn dod yn wir pan ddylai fod yn ffug (gallwch ddarllen mwy am hyn yn cyswllt).

Gellir cywiro'r gwall yn ddibwys: trwy fwrw unsigned int. Cymhwysais yr atgyweiriad ac ailgychwyn y system a gweithiodd DNS eto.

Blas buddugoliaeth

Anfonais fy nghanfyddiadau ymlaen at y cleient a'u hanfon LKML clwt cnewyllyn. Rwy'n falch: mae pob darn o'r pos yn cyd-fynd â'i gilydd, gallaf esbonio'n union pam y gwnaethom arsylwi ar yr hyn a welsom, ac yn bwysicaf oll, roeddem yn gallu dod o hyd i ateb i'r broblem diolch i'n gwaith tîm!

Mae'n werth cydnabod mai prin fu'r achos, ac yn ffodus, anaml y byddwn yn derbyn ceisiadau mor gymhleth gan ddefnyddwyr.

Ffynhonnell: hab.com