Çîrokek li ser windabûna pakêtên DNS ji piştgiriya teknîkî ya Google Cloud

Ji Edîtorê Blogê Google: Ma we qet meraq kiriye ka endezyarên Çareseriyên Teknîkî yên Google Cloud (TSE) çawa daxwazên piştgirîya we digirin? Endezyarên Piştgiriya Teknîkî ya TSE berpirsiyar in ku çavkaniyên pirsgirêkan ên ku ji hêla bikarhêner ve hatine ragihandin nas bikin û rast bikin. Hin ji van pirsgirêkan pir hêsan in, lê carinan hûn bi bilêtek ku yekcar bala gelek endezyaran hewce dike tê. Di vê gotarê de, yek ji xebatkarên TSE-ê dê ji me re pirsgirêkek pir dijwar ji pratîka xwe ya vê dawiyê vebêje - doza pakêtên DNS wenda. Di vê çîrokê de, em ê bibînin ka endezyaran çawa karîbûn rewşê çareser bikin, û di dema rastkirina xeletiyê de çi tiştên nû fêr bûn. Em hêvî dikin ku ev çîrok ne tenê we di derheqê xeletiyek kûr de hîn dike, lê di heman demê de di derheqê pêvajoyên ku diçin peldanka piştevaniyê bi Google Cloud re jî têgihiştinê dide we.

Çareserkirina pirsgirêkan hem zanist û hem jî huner e. Hemî bi avakirina hîpotezek li ser sedema tevgera ne-standard a pergalê dest pê dike, piştî ku ew ji bo hêzê tê ceribandin. Lêbelê, berî ku em hîpotezek formule bikin, divê em pirsgirêkê bi zelalî diyar bikin û bi awayekî rast formule bikin. Ger pirs pir zelal xuya dike, wê hingê hûn neçar in ku her tiştî bi baldarî analîz bikin; Ev "hunera" çareserkirina pirsgirêkan e.

Di binê Google Cloud de, pêvajoyên weha bi rengek berbiçav tevlihevtir dibin, ji ber ku Google Cloud herî baş hewl dide ku nepeniya bikarhênerên xwe garantî bike. Ji ber vê yekê, endezyarên TSE ne xwedan rêgezên guherandina pergalên we ne, ne jî şiyana dîtina mîhengan bi berfirehî wekî bikarhêneran heye. Ji ber vê yekê, ji bo ceribandina yek ji hîpotezên xwe, em (endazyar) nikarin zû pergalê biguherînin.

Hin bikarhêner bawer dikin ku em ê her tiştî mîna mekanîkê di karûbarek gerîdeyê de rast bikin, û bi hêsanî nasnameya makîneyek virtual ji me re bişînin, lê di rastiyê de pêvajo di forma danûstendinê de pêk tê: berhevkirina agahdarî, damezrandin û pejirandin (an redkirina) hîpotezan, û, di dawiyê de, pirsgirêkên biryarek li ser bingeha danûstendina bi xerîdar re têne çêkirin.

Pirsgirêk di pirsê de

Îro çîrokeke me ya bi dawîhatineke xweş heye. Yek ji sedemên çareseriya serketî ya doza pêşniyarkirî şirovekirina pir berfireh û rast a pirsgirêkê ye. Li jêr hûn dikarin kopiyek bilêta yekem bibînin (ji bo ku agahdariya nepenî veşêre hatî guherandin):

Ev peyam ji bo me gelek agahdariyên kêrhatî hene:

• VM-ya taybetî diyar kir
• Pirsgirêk bixwe tê destnîşan kirin - DNS nexebite
• Li ku derê pirsgirêk xwe diyar dike - VM û konteynir tê destnîşan kirin
• Gavên ku bikarhêner avêtin ji bo tespîtkirina pirsgirêkê têne destnîşan kirin.

Daxwaz wekî "P1: Bandora krîtîk - Xizmeta ku di hilberînê de nayê bikar anîn" hate tomar kirin, ku tê wateya çavdêriya domdar a rewşê 24/7 li gorî nexşeya "Rojê bişopînin" (hûn dikarin bêtir li ser bixwînin pêşîniyên daxwazên bikarhêner), digel veguheztina wê ji yek tîmek piştgirî ya teknîkî ji yekî din re digel her guheztina devera demjimêr. Bi rastî, dema ku pirsgirêk gihîşt tîmê me yê li Zurichê, ew berê xwe dida cîhanê. Di vê demê de, bikarhêner tedbîrên sivikkirinê girtibû, lê ji dubarebûna rewşê di hilberînê de ditirsiya, ji ber ku sedema bingehîn hîn nehatibû kifş kirin.

Dema ku bilêt gihîşt Zurichê, me berê agahdariya jêrîn li ber destan bû:

• Dilşad /etc/hosts
• Dilşad /etc/resolv.conf
• encamê iptables-save
• Ji hêla tîmê ve hatî berhev kirin ngrep pelê pcap

Bi van daneyan, em amade bûn ku dest bi qonaxa "lêkolîn" û çareserkirina pirsgirêkan bikin.

Pêngavên me yên pêşîn

Berî her tiştî, me têketin û rewşa servera metadata kontrol kir û piştrast kir ku ew rast dixebite. Pêşkêşkara metadata bersivê dide navnîşana IP-ya 169.254.169.254 û, di nav tiştên din de, berpirsiyarê kontrolkirina navên domainê ye. Me her weha du caran kontrol kir ku dîwarê agir bi VM re rast dixebite û pakêtan asteng nake.

Ew celebek pirsgirêkek xerîb bû: kontrolkirina nmap hîpoteza meya sereke ya di derbarê windakirina pakêtên UDP de red kir, ji ber vê yekê me bi derûnî çend vebijark û awayên din peyda kir ku em wan kontrol bikin:

• Ma pakêt bi bijartî têne avêtin? => Rêgezên iptables kontrol bikin
• Ma ne pir piçûk e? Mtu? => Hilberê kontrol bikin ip a show
• Ma pirsgirêk tenê li ser pakêtên UDP an TCP jî bandor dike? => Birevin dig +tcp
• Ma pakêtên hilberandî yên kolandinê têne vegerandin? => Birevin tcpdump
• Ma libdns rast dixebite? => Birevin strace ji bo veguheztina pakêtan di her du aliyan de kontrol bikin

Li vir em biryar didin ku gazî bikarhênerê bikin da ku pirsgirêkan bi zindî çareser bike.

Di dema telefonê de em dikarin çend tiştan kontrol bikin:

• Piştî çend kontrolan em qaîdeyên iptables ji navnîşa sedeman derdixin
• Em navgînên torê û tabloyên rêvekirinê kontrol dikin, û rastbûna MTU-yê ducarî kontrol dikin
• Em wê yekê kifş dikin dig +tcp google.com (TCP) wekî ku divê dixebite, lê dig google.com (UDP) naxebite
• Bi dûr xistin tcpdump hê jî dixebite dig, em dibînin ku pakêtên UDP têne vegerandin
• Em dûr dikevin strace dig google.com û em dibînin ka çiqas rast bang dike sendmsg() и recvms(), lê belê ya duyemîn ji hêla demkî ve tê qut kirin

Mixabin, dawiya veguheztinê tê û em neçar in ku pirsgirêkê berbi qada demjimêra din ve mezin bikin. Lêbelê, daxwaz di tîmê me de eleqedar kir, û hevkarek pêşniyar dike ku pakêta destpêkê ya DNS-ê bi karanîna modula Python-a scrapy biafirîne.

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

Ev parçe pakêtek DNS diafirîne û daxwazê ​​ji servera metadata re dişîne.

Bikarhêner kodê dimeşîne, bersiva DNS vedigere, û serîlêdan wê distîne, piştrast dike ku di asta torê de pirsgirêk tune.

Piştî "rêwîtiyek din a cîhanê", daxwaz vedigere tîmê me, û ez bi tevahî wê ji xwe re vediguhêzim, difikirîm ku ger daxwaz ji cîhek bi cîh raweste dê ji bikarhêner re hêsantir be.

Di vê navberê de, bikarhêner bi dilovanî qebûl dike ku wêneyek wêneya pergalê peyda bike. Ev nûçeyek pir baş e: şiyana ceribandina pergalê bi xwe çareserkirina pirsgirêkan pir zûtir dike, ji ber ku êdî ne hewce ye ku ez ji bikarhêner bipirsim ku fermanan bimeşîne, encaman ji min re bişîne û wan analîz bike, ez dikarim her tiştî bixwe bikim!

Hevalên min hinekî dest bi çavnebariya min dikin. Di dema nîvro de em li ser veguherînê nîqaş dikin, lê kes nizane ka çi diqewime. Xweşbextane, bikarhêner bixwe berê tedbîran girtiye da ku encaman kêm bike û lez nake, ji ber vê yekê wextê me heye ku em pirsgirêkê derxînin. Û ji ber ku wêneyek me heye, em dikarin her ceribandinên ku me eleqedar dikin bimeşînin. Ecêb!

Paşve gav avêtin

Yek ji pirsên hevpeyivînê yên herî populer ên ji bo pozîsyonên endezyar pergalê ev e: "Gava ku hûn ping dikin çi diqewime www.google.com? Pirs mezin e, ji ber ku berendam hewce dike ku her tiştî ji şêlê bigire heya cîhê bikarhêner, heya kernelê pergalê û dûv re jî torê vebêje. Ez dibişirim: carinan pirsên hevpeyivînê di jiyana rast de kêrhatî dibin…

Ez biryar didim ku vê pirsa HR li pirsgirêkek heyî bicîh bikim. Bi gelemperî, gava ku hûn hewl didin ku navek DNS-ê destnîşan bikin, jêrîn diqewime:

1. Serlêdan pirtûkxaneyek pergalê wekî libdns gazî dike
2. libdns veavakirina pergalê bi kîjan servera DNS-ê re divê pê re têkilî dayne kontrol dike (di diagramê de ev 169.254.169.254, servera metadata ye)
3. libdns bangên pergalê bikar tîne da ku soketek UDP (SOKET_DGRAM) biafirîne û pakêtên UDP bi pirsek DNS-ê di her du alîyan de bişîne.
4. Bi navbeynkariya sysctl hûn dikarin staka UDP-ê di asta kernelê de mîheng bikin
5. Kernel bi hardware re têkilî dike da ku pakêtan bi navgîniya torê veguhezîne ser torê
6. Hîpervisor di pêwendiya pê re pakêtê digire û dişîne servera metadata
7. Pêşkêşkara metadata, bi sêrbaziya xwe, navê DNS-ê destnîşan dike û bi karanîna heman rêbazê bersivek vedigerîne

Bila ez ji we re bi bîr bînim ka kîjan hîpotezên ku me berê li ber çavan girtine:

Hîpotez: Pirtûkxaneyên şikestî

• Test 1: Di pergalê de rêgezê bimeşînin, kontrol bikin ku dig bangên pergalê yên rast dike
• Encam: Bangên pergalê yên rast têne gazî kirin
• Test 2: Srapy bikar bînin da ku kontrol bikin ka em dikarin navên ku pirtûkxaneyên pergalê derbas dikin diyar bikin
• Encam: em dikarin
• Test 3: rpm –V li ser pakêta libdns û pelên pirtûkxaneya md5sum bimeşînin
• Encam: koda pirtûkxaneyê bi tevahî koda di pergala xebitandinê ya xebatê de wekhev e
• Test 4: Wêneya pergala root ya bikarhêner bêyî vê tevgerê li ser VM-ê siwar bikin, chroot-ê bimeşînin, bibînin ka DNS dixebite
• Encam: DNS rast dixebite

Encam li ser bingeha testan: pirsgirêk ne di pirtûkxaneyan de ye

Hîpotez: Di mîhengên DNS de xeletiyek heye

• Test 1: tcpdump kontrol bikin û bibînin ka pakêtên DNS-ê piştî xebitandina kolandinê rast têne şandin û vegerandin
• Encam: pakêt rast têne şandin
• Test 2: du caran li ser serverê kontrol bikin /etc/nsswitch.conf и /etc/resolv.conf
• Encam: her tişt rast e

Encam li ser bingeha testan: pirsgirêk ne bi veavakirina DNS-ê ye

Hîpotez: core xera bûye

• Test: Kernelê nû saz bikin, îmzeyê kontrol bikin, ji nû ve bidin destpêkirin
• Encam: tevgerek wekhev

Encam li ser bingeha testan: kernel xera nabe

Hîpotez: tevgera çewt a tora bikarhêner (an navrûya torê ya hypervisor)

• Test 1: Mîhengên dîwarê xwe kontrol bikin
• Encam: Firewall pakêtên DNS hem li ser mêvandar û hem jî GCP derbas dike
• Test 2: seyrûseferê bigire û rastdariya veguheztin û vegerandina daxwazên DNS bişopîne
• Encam: tcpdump piştrast dike ku mêvandar pakêtên vegerê wergirtine

Encam li ser bingeha testan: pirsgirêk ne di torê de ye

Hîpotez: servera metadata nexebite

• Test 1: Têketinên servera metadata ji bo anomalî kontrol bikin
• Encam: di qeydan de anomalî tune
• Test 2: Ji hêla servera metadata re derbas bibin dig @8.8.8.8
• Encam: Çareserkirin bêyî karanîna serverek metadata jî têk diçe

Encam li ser bingeha testan: pirsgirêk ne bi servera metadata ye

Bi kurtahî: me hemû binpergalan ceriband ji bilî mîhengên dema xebatê!

Dive nav Mîhengên Runtime Kernel

Ji bo mîhengkirina hawîrdora darvekirina kernelê, hûn dikarin vebijarkên rêzika fermanê (grub) an navrûya sysctl bikar bînin. Min lê nêrî /etc/sysctl.conf û tenê bifikirim, min gelek mîhengên xwerû kifş kir. Bi hesta ku min dest avêtiye ser tiştek, min hemî mîhengên ne-torê an ne-tcp avêtin, bi mîhengên çiyê re mam net.core. Dûv re ez çûm cihê ku destûrên mêvandar di VM-yê de bûn û min dest bi sepandina mîhengan yek bi yek, yek li dû hev, bi VM-ya şikestî kir, heya ku min sûcdar dît:

net.core.rmem_default = 2147483647

Li vir ew e, veavakirinek şikandina DNS! Min çeka kuştinê dît. Lê çima ev diqewime? Hîn ji min re motîvasyonek lazim bû.

Mezinahiya tamponê ya pakêta DNS-ê ya bingehîn bi rê ve tê mîheng kirin net.core.rmem_default. Nirxek gelemperî li derûdora 200KiB ye, lê heke servera we gelek pakêtên DNS werdigire, dibe ku hûn bixwazin mezinahiya tamponê zêde bikin. Ger dema ku pakêtek nû tê de tampon tije be, mînakî ji ber ku serîlêdan bi têra xwe zû pê naxebite, wê hingê hûn ê dest bi windakirina pakêtan bikin. Muwekîlê me bi rast mezinahiya tampon zêde kir ji ber ku ew ji windabûna daneyê ditirsiya, ji ber ku wî serîlêdanek ji bo berhevkirina metrîkan bi pakêtên DNS-ê bikar tîne. Nirxa ku wî destnîşan kir herî zêde gengaz bû: 231-1 (heke li 231 were danîn, dê kernel "ARGUMENT INVALID" vegere).

Ji nişkê ve min fêm kir ku çima nmap û scapy rast dixebitin: wan soketên xav bikar tînin! Soketên xav ji soketên birêkûpêk cûda ne: ew iptables derbas dikin, û ew ne tampon in!

Lê çima "tampon pir mezin" dibe sedema pirsgirêkan? Ew eşkere wekî ku tê xwestin naxebite.

Di vê nuqteyê de ez dikarim pirsgirêkê li ser gelek kernel û belavokên pirjimar dubare bikim. Pirsgirêk berê li ser kernel 3.x xuya bû û niha ew jî li ser kernel 5.x xuya bû.

Bi rastî, piştî destpêkirinê

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

DNS kar rawestand.

Min di nav algorîtmayek lêgerîna binaryê ya sade de dest bi lêgerîna nirxên xebatê kir û min dît ku pergal bi 2147481343 re dixebitî, lê ev hejmar ji min re komek hejmarên bêwate bû. Min ji xerîdar re pêşniyar kir ku vê hejmarê biceribîne, û wî bersiv da ku pergal bi google.com re dixebitî, lê dîsa jî bi domên din re xeletiyek da, ji ber vê yekê min lêpirsîna xwe domand.

Min saz kiriye dropwatch, amûrek ku diviya berê bihata bikar anîn: ew tam nîşan dide ku pakêtek li ku derê di kernelê de diqede. Sûcdar fonksiyon bû udp_queue_rcv_skb. Min çavkaniyên kernel dakêşand û çend zêde kir karûbaran printk ji bo şopandina ku pakêt tam li ku diqede. Min zû rewşa rast dît if, û bi tenê demekê li wê mêze kir, ji ber ku wê demê her tişt di dawiyê de bû wêneyek tevahî: 231-1, hejmareke bêwate, domanek nexebitî... Ew parçeyek kodek bû __udp_enqueue_schedule_skb:

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

Ji kerema xwe not bikin:

• rmem ji cureyê int e
• size ji cureya u16 e (navnîşana şazdeh-bit ya bê îmze) û mezinahiya pakêtê diparêze
• sk->sk_rcybuf ji celebê int e û mezinahiya tamponê ku, ji hêla pênase ve, bi nirxa tê de wekhev e, hilîne net.core.rmem_default

Dema ku sk_rcvbuf Nêzîkî 231 dibe, dibe ku mezinahiya pakêtê bicive hejmar zêde zêde. Û ji ber ku ew int e, nirxa wê neyînî dibe, ji ber vê yekê rewş rast dibe dema ku ew xelet be (hûn dikarin li ser vê yekê bêtir bixwînin link).

Xeletî dikare bi rengek piçûk were rast kirin: bi avêtinê unsigned int. Min rastkirinê sepand û pergalê ji nû ve da destpêkirin û DNS dîsa xebitî.

Tama serkeftinê

Min encamên xwe ji muwekîlê re şand û şand LKML patch kernel. Ez kêfxweş im: her perçeyek puzzle bi hev re diqewime, ez dikarim tam rave bikim ka çima me çavdêriya tiştê ku me dît, û ya herî girîng, me bi saya xebata tîmê xwe karî çareseriyek ji pirsgirêkê re bibînin!

Hêjayî gotinê ye ku doz kêm bû, û bi bextewarî em kêm kêm daxwazên weha tevlihev ji bikarhêneran werdigirin.

Source: www.habr.com