Scéal faoi phaicéid DNS atá ar iarraidh ó thacaíocht theicniúil Google Cloud

Ó Eagarthóir Blag Google: Ar smaoinigh tú riamh ar conas a láimhseálann innealtóirí Google Cloud Technical Solutions (TSE) d’iarratais tacaíochta? Tá Innealtóirí Tacaíochta Teicniúla TSE freagrach as foinsí fadhbanna a thuairiscíonn úsáideoirí a aithint agus a cheartú. Tá cuid de na fadhbanna seo simplí go leor, ach uaireanta tagann tú trasna ar thicéad a éilíonn aird roinnt innealtóirí ag an am céanna. San Airteagal seo, inseoidh duine d’fhostaithe TSE dúinn faoi fhadhb thar a bheith deacair ón gcleachtas a rinne sé le déanaí - gcás paicéid DNS in easnamh. Sa scéal seo, feicfimid conas a d'éirigh leis na hinnealtóirí an cás a réiteach, agus cad iad na rudaí nua a d'fhoghlaim siad agus an earráid á réiteach. Tá súil againn ní hamháin go gcuireann an scéal seo oideachas ort faoi fhabht domhain, ach go dtugann sé léargas duit freisin ar na próisis a bhaineann le ticéad tacaíochta a chomhdú le Google Cloud.

Is eolaíocht agus ealaín araon é fabhtcheartú. Tosaíonn sé go léir le hipitéis a thógáil faoin gcúis atá le hiompar neamhchaighdeánach an chórais, agus déantar tástáil neart ina dhiaidh sin. Sula ndéanaimid hipitéis a cheapadh, áfach, ní mór dúinn an fhadhb a shainiú go beacht agus a fhoirmliú go beacht. Má fhuaimeann an cheist ró-doiléir, ansin beidh ort gach rud a anailísiú go cúramach; Is é seo an “ealaín” fabhtcheartaithe.

Faoi Google Cloud, éiríonn próisis den sórt sin níos casta as cuimse, de réir mar a dhéanann Google Cloud a dhícheall príobháideacht a chuid úsáideoirí a ráthú. Mar gheall air seo, níl rochtain ag innealtóirí TSE chun do chórais a chur in eagar, ná an cumas chun cumraíochtaí a fheiceáil chomh leathan agus atá ag úsáideoirí. Mar sin, chun aon cheann dár hipitéisí a thástáil, ní féidir linne (innealtóirí) an córas a mhodhnú go tapa.

Creideann roinnt úsáideoirí go socróimid gach rud cosúil le meicnic i seirbhís cairr, agus go simplí seolfaimid aitheantas meaisín fíorúil chugainn, ach i ndáiríre tarlaíonn an próiseas i bhformáid chomhrá: faisnéis a bhailiú, hipitéisí a fhoirmiú agus a dhearbhú (nó a bhréagnú), agus, sa deireadh, cinneadh fadhbanna bunaithe ar chumarsáid leis an gcliant.

Fadhb atá i gceist

Inniu tá scéal againn a bhfuil deireadh maith leis. Ceann de na cúiseanna gur éirigh le réiteach an cháis bheartaithe ná cur síos an-mhionsonraithe agus cruinn ar an bhfadhb. Anseo thíos feicfidh tú cóip den chéad ticéad (arna chur in eagar chun faisnéis rúnda a cheilt):

Tá go leor eolais úsáideach sa teachtaireacht seo dúinn:

• VM sonrach sonraithe
• Cuirtear an fhadhb féin in iúl - ní oibríonn DNS
• Tá sé in iúl i gcás ina manifests an fhadhb féin - VM agus coimeádán
• Léirítear na céimeanna a ghlac an t-úsáideoir chun an fhadhb a aithint.

Cláraíodh an t-iarratas mar “P1: Tionchar Criticiúil - Seirbhís Neamh-inúsáidte i dtáirgeadh”, rud a chiallaíonn monatóireacht leanúnach ar an gcás 24/7 de réir na scéime “Follow the Sun” (is féidir leat tuilleadh a léamh faoi tosaíochtaí iarrataí úsáideoirí), lena aistriú ó fhoireann tacaíochta theicniúil amháin go ceann eile le gach athrú crios ama. Go deimhin, faoin am a shroich an fhadhb ár bhfoireann i Zurich, bhí sé ciorcal timpeall na cruinne cheana féin. Faoin am seo, bhí bearta maolaithe glactha ag an úsáideoir, ach bhí eagla air go dtarlódh athrá ar an staid i dtáirgeadh, ós rud é nach bhfuarthas an bhunchúis fós.

Faoin am a shroich an ticéad Zurich, bhí an t-eolas seo a leanas idir lámha againn cheana féin:

• Ábhar /etc/hosts
• Ábhar /etc/resolv.conf
• Aschur iptables-save
• Le chéile ag an bhfoireann ngrep comhad pcap

Leis na sonraí seo, bhíomar réidh chun tús a chur leis an gcéim “imscrúdaithe” agus fabhtcheartaithe.

Ár gcéad chéimeanna

Ar an gcéad dul síos, rinneamar seiceáil ar logaí agus stádas an fhreastalaí meiteashonraí agus rinneamar cinnte go raibh sé ag obair i gceart. Freagraíonn an freastalaí meiteashonraí an seoladh IP 169.254.169.254 agus, i measc rudaí eile, tá sé freagrach as ainmneacha fearainn a rialú. Rinneamar seiceáil faoi dhó freisin go n-oibríonn an balla dóiteáin i gceart leis an VM agus nach gcuireann sé bac ar phaicéid.

Fadhb aisteach de shaghas éigin a bhí ann: dhiúltaigh an tseiceáil nmap ár bpríomh-hipitéis faoi chailliúint paicéid UDP, agus mar sin tháinig muid suas go meabhrach le go leor roghanna eile agus bealaí chun iad a sheiceáil:

• An scaoiltear paicéid go roghnach? => Seiceáil rialacha iptables
• Nach bhfuil sé róbheag? MTU? => Seiceáil aschur ip a show
• An gcuireann an fhadhb isteach ar phaicéid UDP nó ar TCP amháin freisin? => Tiomáint ar shiúl dig +tcp
• An gcuirtear paicéid ginte tochailte ar ais? => Tiomáint ar shiúl tcpdump
• An bhfuil libdns ag obair i gceart? => Tiomáint ar shiúl strace chun tarchur paicéid sa dá threo a sheiceáil

Anseo socraímid glaoch ar an úsáideoir chun fadhbanna a réiteach beo.

Le linn an ghlao is féidir linn roinnt rudaí a sheiceáil:

• Tar éis roinnt seiceálacha déanaimid rialacha iptables a eisiamh ón liosta cúiseanna
• Déanaimid seiceáil ar chomhéadain líonra agus táblaí ródaithe, agus seiceáil faoi dhó go bhfuil an MTU i gceart
• Faighimid amach go dig +tcp google.com (TCP) ag obair mar ba chóir, ach dig google.com (UDP) nach bhfuil ag obair
• Tar éis tiomáint ar shiúl tcpdump tá sé fós ag obair dig, feicimid go bhfuil paicéid UDP á gcur ar ais
• Táimid ag tiomáint ar shiúl strace dig google.com agus feicimid conas glaonna tochailt i gceart sendmsg() и recvms(), ach cuireann teorainn ama isteach ar an dara ceann

Ar an drochuair, tagann deireadh leis an athrú agus tá iallach orainn an fhadhb a ardú go dtí an chéad chrios ama eile. Spreag an t-iarratas, áfach, suim inár bhfoireann, agus molann comhghleacaí an pacáiste DNS tosaigh a chruthú ag baint úsáide as modúl scrapy Python.

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

Cruthaíonn an blúire seo paicéad DNS agus seolann sé an t-iarratas chuig an bhfreastalaí meiteashonraí.

Ritheann an t-úsáideoir an cód, cuirtear an freagra DNS ar ais, agus faigheann an t-iarratas é, ag dearbhú nach bhfuil aon fhadhb ann ar leibhéal an líonra.

Tar éis “turas ar fud an domhain” eile, filleann an t-iarratas ar ár bhfoireann, agus aistrím go hiomlán chugam féin é, ag ceapadh go mbeidh sé níos áisiúla don úsáideoir má stopann an t-iarratas ag dul timpeall ó áit go háit.

Idir an dá linn, aontaíonn an t-úsáideoir go cineálta léargas a thabhairt ar íomhá an chórais. Is dea-scéal é seo: déanann an cumas an córas a thástáil mé féin fabhtcheartaithe i bhfad níos tapúla, mar ní gá dom a thuilleadh a iarraidh ar an úsáideoir orduithe a rith, na torthaí a sheoladh chugam agus anailís a dhéanamh orthu, is féidir liom gach rud a dhéanamh mé féin!

Tá mo chomhghleacaithe ag cur éad beag orm. I rith am lóin pléimid an tiontú, ach níl aon tuairim ag éinne cad atá ar siúl. Ar ámharaí an tsaoil, tá bearta glactha ag an úsáideoir féin cheana féin chun na hiarmhairtí a mhaolú agus níl aon deifir air, agus mar sin tá an t-am againn an fhadhb a scaradh. Agus ós rud é go bhfuil íomhá againn, is féidir linn aon tástálacha a bhfuil suim againn iontu a reáchtáil. Go hiontach!

Ag tabhairt céim siar

Ceann de na ceisteanna agallaimh is coitianta maidir le poist innealtóra córais ná: “Cad a tharlaíonn nuair a bhíonn tú ag pingin www.google.com? Tá an cheist iontach, ós rud é go gcaithfidh an t-iarrthóir cur síos a dhéanamh ar gach rud ón bhlaosc go spás úsáideora, go dtí eithne an chórais agus ansin chuig an líonra. Bím ag gáire: uaireanta bíonn ceisteanna agallaimh úsáideach sa saol fíor...

Cinnim an cheist AD seo a chur i bhfeidhm ar fhadhb reatha. Go garbh, nuair a dhéanann tú iarracht ainm DNS a chinneadh, tarlaíonn an méid seo a leanas:

1. Glaonn an feidhmchlár leabharlann córais ar nós libdns
2. seiceálann libdns cumraíocht an chórais lenar cheart don fhreastalaí DNS dul i dteagmháil (sa léaráid é seo 169.254.169.254, freastalaí meiteashonraí)
3. Úsáideann libdns glaonna córais chun soicéad UDP (SOKET_DGRAM) a chruthú agus paicéid UDP a sheoladh le ceist DNS sa dá threo
4. Tríd an gcomhéadan sysctl is féidir leat an stack UDP a chumrú ag an leibhéal eithne
5. Idirghníomhaíonn an eithne leis na crua-earraí chun paicéid a tharchur thar an líonra tríd an gcomhéadan líonra
6. Gabhann agus tarchuireann an hypervisor an paicéad chuig an bhfreastalaí meiteashonraí nuair a théann sé i dteagmháil leis
7. Cinneann an freastalaí meiteashonraí, de réir a draíocht, an t-ainm DNS agus cuireann sé freagra ar ais ag baint úsáide as an modh céanna

Cuir i gcuimhne duit cad iad na hipitéisí atá curtha san áireamh againn cheana féin:

Hipitéis: Leabharlanna briste

• Tástáil 1: rith strace sa chóras, seiceáil go ndéanann tochailt glaonna an chórais cheart
• Toradh: Glaoitear córais cheart ar ghlaonna
• Tástáil 2: ag baint úsáide as srapy le seiceáil an féidir linn ainmneacha a chinneadh ag seachaint leabharlanna córais
• Toradh: is féidir linn
• Tástáil 3: rith rpm –V ar an bpacáiste libdns agus comhaid leabharlainne md5sum
• Toradh: tá an cód leabharlainne go hiomlán comhionann leis an gcód sa chóras oibriúcháin oibre
• Tástáil 4: cuir íomhá chórais fréimhe an úsáideora ar VM gan an t-iompar seo, rith chroot, féach an oibríonn DNS
• Toradh: Oibríonn DNS i gceart

Conclúid bunaithe ar thástálacha: níl an fhadhb sna leabharlanna

Hipitéis: Tá earráid sna socruithe DNS

• Tástáil 1: seiceáil tcpdump agus féach an seoltar agus go gcuirtear ar ais paicéid DNS i gceart tar éis tochailt a rith
• Toradh: tarchuirtear paicéid i gceart
• Tástáil 2: seiceáil dúbailte ar an bhfreastalaí /etc/nsswitch.conf и /etc/resolv.conf
• Toradh: tá gach rud ceart

Conclúid bunaithe ar thástálacha: níl an fhadhb le cumraíocht DNS

Hipitéis: croí-damáiste

• Tástáil: eithne nua a shuiteáil, síniú a sheiceáil, atosú
• Toradh: iompar den chineál céanna

Conclúid bunaithe ar thástálacha: nach bhfuil an eithne damáiste

Hipitéis: iompar mícheart an líonra úsáideora (nó comhéadan líonra hypervisor)

• Tástáil 1: Seiceáil do shocruithe balla dóiteáin
• Toradh: Gabhann an balla dóiteáin paicéid DNS ar an óstaigh agus ar an GCP araon
• Tástáil 2: idircheapadh trácht agus monatóireacht a dhéanamh ar cheart an tarchuir agus ar ais iarratais DNS
• Toradh: deimhníonn tcpdump go bhfuil paicéid fillte faighte ag an óstach

Conclúid bunaithe ar thástálacha: níl an fhadhb sa líonra

Hipitéis: níl an freastalaí meiteashonraí ag obair

• Tástáil 1: seiceáil logaí an fhreastalaí meiteashonraí le haghaidh aimhrialtachtaí
• Toradh: níl aon aimhrialtachtaí sna logaí
• Tástáil 2: Seachbhóthar an freastalaí meiteashonraí trí dig @8.8.8.8
• Toradh: Tá an réiteach briste fiú gan freastalaí meiteashonraí a úsáid

Conclúid bunaithe ar thástálacha: níl an fhadhb leis an bhfreastalaí meiteashonraí

An líne bun: rinneamar tástáil ar gach fochóras ach amháin socruithe am rite!

Tumadóireacht isteach i Socruithe Eithne Reatha

Chun an timpeallacht forghníomhaithe eithne a chumrú, is féidir leat roghanna na n-orduithe (grub) nó an comhéadan sysctl a úsáid. D'fhéach mé isteach /etc/sysctl.conf agus díreach smaoineamh, fuair mé amach roinnt socruithe saincheaptha. Ag mothú amhail is dá mba rud é gur rug mé ar rud éigin, chaith mé gach socrú neamhlíonra nó neamh-tcp amach, ag fanacht leis na socruithe sléibhe net.core. Ansin chuaigh mé go dtí an áit a raibh na ceadanna óstaigh sa VM agus thosaigh mé ag cur na socruithe i bhfeidhm ceann ar cheann, ceann i ndiaidh a chéile, leis an VM briste, go dtí gur aimsigh mé an culprit:

net.core.rmem_default = 2147483647

Seo é, cumraíocht DNS-bhriseadh! Fuair ​​​​mé an arm dúnmharaithe. Ach cén fáth go bhfuil sé seo ag tarlú? Bhí rún ag teastáil uaim fós.

Tá bunmhéid maoláin an phacéid DNS cumraithe trí net.core.rmem_default. Tá luach tipiciúil áit éigin timpeall 200KiB, ach má fhaigheann do fhreastalaí go leor paicéid DNS, b'fhéidir gur mhaith leat an méid maoláin a mhéadú. Má tá an maolán iomlán nuair a thagann paicéad nua isteach, mar shampla toisc nach bhfuil an t-iarratas á phróiseáil go tapa go leor, ansin tosóidh tú ag cailliúint paicéid. Mhéadaigh ár gcliant an méid maoláin i gceart toisc go raibh eagla air roimh chaillteanas sonraí, ós rud é go raibh sé ag baint úsáide as iarratas chun méadracht a bhailiú trí phaicéid DNS. Ba é an luach a shocraigh sé ná an t-uasmhéid a d'fhéadfadh a bheith ann: 231-1 (má tá sé socraithe go 231, tabharfaidh an eithne ar ais “ARgÓID NEAMHBHAILÍ”).

Go tobann thuig mé cén fáth gur oibrigh nmap agus scapy i gceart: bhí siad ag baint úsáide as soicéid amh! Tá soicéid amh difriúil ó soicéid rialta: seachnaíonn siad iptables, agus níl siad maolánach!

Ach cén fáth go bhfuil "maolán ró-mhór" ina chúis le fadhbanna? Is léir nach n-oibríonn sé mar a bhí beartaithe.

Ag an bpointe seo d'fhéadfainn an fhadhb a atáirgeadh ar il-eithne agus ildháiltí. Bhí an fhadhb le feiceáil cheana féin ar an eithne 3.x agus anois bhí sé le feiceáil freisin ar an eithne 5.x.

Go deimhin, ar tosaithe

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

Stop DNS ag obair.

Thosaigh mé ag lorg luachanna oibre trí algartam cuardaigh dénártha simplí agus fuair mé amach gur oibrigh an córas le 2147481343, ach bhí an uimhir seo ina sraith uimhreacha gan brí domsa. Mhol mé don chliant triail a bhaint as an uimhir seo, agus d'fhreagair sé gur oibrigh an córas le google.com, ach fós thug sé earráid le fearainn eile, agus mar sin lean mé ar aghaidh le m'imscrúdú.

Tá mé suiteáilte uaireadóir, uirlis ar cheart a bheith in úsáid níos luaithe: taispeánann sé go díreach cá háit san eithne a chríochnaíonn paicéad. Ba é an culprit an fheidhm udp_queue_rcv_skb. Íoslódáil mé na foinsí eithne agus chuir mé cúpla feidhmeanna printk a rianú cá háit go díreach a chríochnaíonn an paicéad suas. Fuair ​​​​mé an riocht ceart go tapa if, agus go simplí ag stánadh air ar feadh tamaill, mar is ansin a tháinig gach rud le chéile faoi dheireadh i bpictiúr iomlán: 231-1, uimhir gan bhrí, fearann ​​neamhoibríoch... Píosa cód a bhí ann i __udp_enqueue_schedule_skb:

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

Tabhair faoi deara:

• rmem is den chineál int
• size is de chineál u16 é ( slánuimhir sé ghiotán déag gan síniú) agus stórálann sé méid an phaicéid
• sk->sk_rcybuf is den chineál int agus stórálann sé an méid maoláin atá, de réir sainmhínithe, comhionann leis an luach i net.core.rmem_default

Nuair a sk_rcvbuf cur chuige 231, agus d'fhéadfadh go mbeadh sé mar thoradh ar mhéid an phaicéid slánuimhir thar maoil. Agus ós rud é gur slánuimhir é, éiríonn a luach diúltach, agus mar sin éiríonn an riocht fíor nuair ba chóir go mbeadh sé bréagach (is féidir leat tuilleadh a léamh faoi seo ag nasc).

Is féidir an earráid a cheartú ar bhealach fánach: trí réitigh unsigned int. Chuir mé an socrú i bhfeidhm agus d'atosaigh mé an córas agus d'oibrigh DNS arís.

Blas bua

Chuir mé mo thorthaí ar aghaidh chuig an gcliant agus sheol mé LKML paiste eithne. Tá áthas orm: luíonn gach píosa den bhfreagra le chéile, is féidir liom a mhíniú go díreach cén fáth ar thugamar faoi deara an méid a thugamar faoi deara, agus níos tábhachtaí fós, bhíomar in ann teacht ar réiteach ar an bhfadhb a bhuíochas lenár n-obair foirne!

Is fiú a aithint gur annamh a tharla an cás, agus ar an dea-uair is annamh a fhaighimid iarratais chasta den sórt sin ó úsáideoirí.

Foinse: will.com