Crita babagan paket DNS sing ilang saka dhukungan teknis Google Cloud

Saka Google Blog Editor: Apa sampeyan tau kepingin weruh carane insinyur Google Cloud Technical Solutions (TSE) nangani panjalukan dhukungan sampeyan? Insinyur dhukungan teknis TSE tanggung jawab kanggo ngenali lan mbenerake sumber masalah sing dilaporake pangguna. Sawetara masalah iki cukup prasaja, nanging kadhangkala sampeyan nemokake tiket sing mbutuhake manungsa waé saka sawetara engineers bebarengan. Ing artikel iki, salah sawijining karyawan TSE bakal ngandhani babagan masalah sing angel banget saka praktik anyar - kasus ilang paket DNS. Ing crita iki, kita bakal weruh carane engineers ngatur kanggo mutusake masalah kahanan, lan apa anyar padha sinau nalika ndandani kesalahan. Muga-muga crita iki ora mung ngajari sampeyan babagan bug sing ana ing jero, nanging uga menehi wawasan babagan proses ngajokake tiket dhukungan karo Google Cloud.

Ngatasi masalah minangka ilmu lan seni. Iku kabeh diwiwiti kanthi mbangun hipotesis babagan alesan kanggo prilaku non-standar sistem, sawise kang dites kanggo kekuatan. Nanging, sadurunge ngrumusake hipotesis, kita kudu nemtokake kanthi jelas lan kanthi tepat ngrumusake masalah kasebut. Yen pitakonan kasebut ora jelas, mula sampeyan kudu nganalisa kabeh kanthi teliti; Iki minangka "seni" ngatasi masalah.

Ing Google Cloud, proses kasebut dadi luwih rumit, amarga Google Cloud nyoba sing paling apik kanggo njamin privasi pangguna. Amarga iki, insinyur TSE ora duwe akses kanggo nyunting sistem sampeyan, utawa kemampuan kanggo ndeleng konfigurasi kanthi jembar kaya pangguna. Mulane, kanggo nguji hipotesis apa wae, kita (insinyur) ora bisa kanthi cepet ngowahi sistem kasebut.

Sawetara pangguna percaya yen kita bakal ndandani kabeh kaya mekanik ing layanan mobil, lan mung ngirim id saka mesin virtual, dene ing kasunyatan proses kasebut dumadi ing format obrolan: ngumpulake informasi, mbentuk lan ngonfirmasi (utawa mbantah) hipotesis, lan, ing pungkasan, masalah kaputusan adhedhasar komunikasi karo klien.

Masalah ing pitakonan

Dina iki kita duwe crita kanthi pungkasan sing apik. Salah sawijining alasan kanggo sukses resolusi kasus sing diusulake yaiku deskripsi sing rinci lan akurat babagan masalah kasebut. Ing ngisor iki sampeyan bisa ndeleng salinan tiket pisanan (diedit kanggo ndhelikake informasi rahasia):

Pesen iki ngemot akeh informasi sing migunani kanggo kita:

• VM spesifik sing ditemtokake
• Masalah kasebut dituduhake - DNS ora bisa digunakake
• Dituduhake ing ngendi masalah kasebut muncul - VM lan wadhah
• Langkah-langkah sing ditindakake pangguna kanggo ngenali masalah kasebut dituduhake.

Panjaluk kasebut kadhaptar minangka "P1: Dampak Kritis - Layanan Ora Bisa Digunakake ing produksi", sing tegese ngawasi kahanan terus-terusan 24/7 miturut skema "Follow the Sun" (sampeyan bisa maca liyane babagan prioritas panjalukan pangguna), kanthi transfer saka siji tim dhukungan teknis menyang liyane kanthi saben shift zona wektu. Nyatane, nalika masalah tekan tim kita ing Zurich, masalah kasebut wis ngubengi jagad iki. Ing wektu iki, pangguna wis njupuk langkah-langkah mitigasi, nanging wedi yen kedadeyan maneh ing produksi, amarga sababe durung ditemokake.

Nalika tiket tekan Zurich, kita wis duwe informasi ing ngisor iki:

• Konten /etc/hosts
• Konten /etc/resolv.conf
• kesimpulan iptables-save
• Dikumpulake dening tim ngrep file pcap

Kanthi data iki, kita wis siyap miwiti fase "investigasi" lan ngatasi masalah.

Langkah pisanan kita

Kaping pisanan, kita mriksa log lan status server metadata lan priksa manawa bisa digunakake kanthi bener. Server metadata nanggapi alamat IP 169.254.169.254 lan, ing antarane, tanggung jawab kanggo ngontrol jeneng domain. Kita uga mriksa kaping pindho yen firewall bisa digunakake kanthi bener karo VM lan ora ngalangi paket.

Iki minangka sawetara masalah aneh: mriksa nmap mbantah hipotesis utama babagan kelangan paket UDP, mula kita kanthi mental nggawe sawetara opsi lan cara kanggo mriksa:

• Apa paket mudhun kanthi selektif? => Priksa aturan iptables
• Apa ora cilik banget? WONG? => Priksa output ip a show
• Apa masalah mung mengaruhi paket UDP utawa TCP uga? => Mlayu dig +tcp
• Apa paket sing digawe dig bali? => Mlayu tcpdump
• Apa libdns bisa digunakake kanthi bener? => Mlayu strace kanggo mriksa transmisi paket ing loro arah

Ing kene kita mutusake nelpon pangguna kanggo ngatasi masalah kanthi langsung.

Sajrone telpon, kita bisa mriksa sawetara perkara:

• Sawise sawetara mriksa, kita ngilangi aturan iptables saka dhaptar alasan
• Kita mriksa antarmuka jaringan lan tabel rute, lan priksa manawa MTU bener
• Kita nemokake iku dig +tcp google.com (TCP) dianggo minangka ngirim, nanging dig google.com (UDP) ora bisa
• Wis diusir tcpdump nalika nyambut gawe dig, kita nemokake yen paket UDP lagi bali
• We drive adoh strace dig google.com lan kita ndeleng carane dig bener nelpon sendmsg() и recvms(), nanging sing nomer loro diganggu wektu entek

Sayange, pungkasan shift teka lan kita kepeksa nambah masalah menyang zona wektu sabanjure. Panjaluk kasebut, Nanging, narik minat tim kita, lan kanca-kanca nyaranake nggawe paket DNS awal nggunakake modul Python scrapy.

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

Fragmen iki nggawe paket DNS lan ngirim panjalukan menyang server metadata.

Pangguna mbukak kode kasebut, respon DNS bali, lan aplikasi kasebut nampa, konfirmasi yen ora ana masalah ing tingkat jaringan.

Sawise "trip-the-world trip" liyane, panjaluk kasebut bali menyang tim kita, lan aku nransfer kabeh menyang aku, mikir manawa pangguna bakal luwih trep yen panjaluk kasebut mandheg ngubengi saka papan menyang papan.

Ing sawetoro wektu, pangguna setuju kanggo menehi gambar gambar sistem. Iki warta apik banget: kemampuan kanggo nyoba sistem dhewe nggawe ngatasi masalah luwih cepet, amarga aku ora maneh kudu takon pangguna kanggo mbukak printah, ngirim kula asil lan nganalisa, aku bisa nindakake kabeh dhewe!

Kanca-kancaku wiwit iri karo aku. Sajrone nedha awan kita ngrembug babagan konversi, nanging ora ana sing ngerti apa sing kedadeyan. Untunge, pangguna dhewe wis njupuk langkah-langkah kanggo nyuda akibat lan ora cepet-cepet, mula kita duwe wektu kanggo mbedakake masalah kasebut. Lan amarga kita duwe gambar, kita bisa nganakake tes sing menarik. apik tenan!

Mundur selangkah

Salah sawijining pitakonan wawancara sing paling populer kanggo posisi insinyur sistem yaiku: "Apa sing kedadeyan nalika sampeyan ping www.google.com? Pitakonan kasebut apik banget, amarga calon kudu njlèntrèhaké kabeh saka cangkang menyang ruang panganggo, menyang kernel sistem lan banjur menyang jaringan. Aku mesem: kadhangkala pitakonan wawancara dadi migunani ing urip nyata ...

Aku arep kanggo aplikasi pitakonan HR iki kanggo masalah saiki. Secara kasar, nalika sampeyan nyoba nemtokake jeneng DNS, kedadeyan ing ngisor iki:

1. Aplikasi kasebut nelpon perpustakaan sistem kayata libdns
2. libdns mriksa konfigurasi sistem sing kudu dikontak server DNS (ing diagram iki 169.254.169.254, server metadata)
3. libdns nggunakake panggilan sistem kanggo nggawe soket UDP (SOKET_DGRAM) lan ngirim paket UDP kanthi pitakon DNS ing loro arah.
4. Liwat antarmuka sysctl sampeyan bisa ngatur tumpukan UDP ing tingkat kernel
5. Kernel berinteraksi karo hardware kanggo ngirim paket liwat jaringan liwat antarmuka jaringan
6. Hypervisor nyekel lan ngirim paket menyang server metadata nalika kontak karo
7. Server metadata, kanthi sihir, nemtokake jeneng DNS lan ngasilake respon nggunakake cara sing padha

Ayo kula ngelingake sampeyan apa hipotesis sing wis kita pikirake:

Hipotesis: Pustaka rusak

• Test 1: mbukak strace ing sistem, priksa manawa dig nelpon telpon sistem sing bener
• Asil: Telpon sistem sing bener diarani
• Tes 2: nggunakake srapy kanggo mriksa apa kita bisa nemtokake jeneng sing ngliwati perpustakaan sistem
• Hasil: kita bisa
• Tes 3: mbukak rpm –V ing paket libdns lan file perpustakaan md5sum
• Asil: kode perpustakaan temen padha karo kode ing sistem operasi apa
• Tes 4: pasang gambar sistem root pangguna ing VM tanpa prilaku iki, bukak chroot, deleng yen DNS bisa digunakake
• Asil: DNS bisa digunakake kanthi bener

Kesimpulan adhedhasar tes: masalah ora ana ing perpustakaan

Hipotesis: Ana kesalahan ing setelan DNS

• Tes 1: priksa tcpdump lan deleng manawa paket DNS dikirim lan bali kanthi bener sawise digali
• Asil: paket dikirim kanthi bener
• Test 2: mriksa pindho ing server /etc/nsswitch.conf и /etc/resolv.conf
• Asil: kabeh bener

Kesimpulan adhedhasar tes: masalah ora karo konfigurasi DNS

Hipotesis: inti rusak

• Tes: nginstal kernel anyar, mriksa tandha tangan, miwiti maneh
• Asil: prilaku sing padha

Kesimpulan adhedhasar tes: kernel ora rusak

Hipotesis: prilaku jaringan pangguna sing salah (utawa antarmuka jaringan hypervisor)

• Tes 1: Priksa setelan firewall sampeyan
• Asil: firewall ngliwati paket DNS ing host lan GCP
• Test 2: nyegat lalu lintas lan ngawasi bener saka transmisi lan bali saka panjalukan DNS
• Asil: tcpdump negesake manawa host wis nampa paket bali

Kesimpulan adhedhasar tes: masalah ora ana ing jaringan

Hipotesis: server metadata ora bisa digunakake

• Test 1: mriksa log server metadata kanggo anomali
• Asil: ora ana anomali ing log
• Test 2: Bypass server metadata liwat dig @8.8.8.8
• Asil: Resolusi rusak sanajan tanpa nggunakake server metadata

Kesimpulan adhedhasar tes: masalah ora karo server metadata

Ngisor garis: kita dites kabeh subsistem kajaba setelan runtime!

Nyilem menyang Setelan Runtime Kernel

Kanggo ngatur lingkungan eksekusi kernel, sampeyan bisa nggunakake opsi baris perintah (grub) utawa antarmuka sysctl. Aku katon ing /etc/sysctl.conf lan mung mikir, Aku katutup sawetara setelan adat. Kroso kaya-kaya wis nyekel soko, aku mbuwang kabeh setelan non-jaringan utawa non-tcp, tetep karo setelan gunung. net.core. Banjur aku menyang ngendi ijin host ing VM lan miwiti nglamar setelan siji-siji, siji-sijine, kanthi VM sing rusak, nganti aku nemokake pelakune:

net.core.rmem_default = 2147483647

Punika, konfigurasi DNS-breaking! Aku nemokake senjata pembunuhan. Nanging kenapa iki kedadeyan? Aku isih butuh motif.

Ukuran buffer paket DNS dhasar dikonfigurasi liwat net.core.rmem_default. Nilai khas ana ing sekitar 200KiB, nanging yen server sampeyan nampa akeh paket DNS, sampeyan bisa uga pengin nambah ukuran buffer. Yen buffer kebak nalika paket anyar teka, contone amarga aplikasi ora proses cukup cepet, sampeyan bakal miwiti ilang paket. Klien kita kanthi bener nambah ukuran buffer amarga dheweke wedi mundhut data, amarga dheweke nggunakake aplikasi kanggo ngumpulake metrik liwat paket DNS. Nilai sing disetel paling maksimal: 231-1 (yen disetel dadi 231, kernel bakal ngasilake "ARGUMEN INVALID").

Dumadakan aku nyadari kenapa nmap lan scapy bisa digunakake kanthi bener: dheweke nggunakake soket mentah! Soket mentah beda karo soket biasa: padha ngliwati iptables, lan ora dibuffer!

Nanging kenapa "buffer gedhe banget" nyebabake masalah? Cetha ora bisa kaya sing dikarepake.

Ing jalur iki aku bisa ngasilake masalah ing macem-macem kernels lan macem-macem distribusi. Masalah wis katon ing kernel 3.x lan saiki uga katon ing kernel 5.x.

Pancen, nalika wiwitan

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

DNS mandheg kerja.

Aku miwiti nggoleki nilai-nilai sing bisa digunakake liwat algoritma telusuran binar sing prasaja lan nemokake manawa sistem kasebut bisa digunakake karo 2147481343, nanging nomer iki minangka nomer sing ora ana gunane kanggo aku. Aku ngusulake klien nyoba nomer iki, lan dheweke mangsuli yen sistem kasebut bisa digunakake karo google.com, nanging isih menehi kesalahan karo domain liyane, mula aku terus investigasi.

Aku wis diinstal dropwatch, alat sing kudu digunakake sadurungé: nuduhake persis ing ngendi ing kernel paket rampung. Pelakune ana fungsi udp_queue_rcv_skb. Aku ndownload sumber kernel lan nambah sawetara fungsi printk kanggo trek ngendi persis paket ends munggah. Aku cepet nemokake kondisi sing bener if, lan mung mandeng ing sawetara wektu, amarga iku banjur kabeh pungkasanipun teka bebarengan menyang gambar wutuh: 231-1, nomer ora ana artine, domain ora bisa digunakake... Iku Piece saka kode ing __udp_enqueue_schedule_skb:

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

Wigati dimangerteni:

• rmem punika jinis int
• size jinis u16 (unsigned nembelas-bit int) lan nyimpen ukuran paket
• sk->sk_rcybuf jinis int lan nyimpen ukuran buffer sing, miturut definisi, padha karo nilai ing net.core.rmem_default

Nalika sk_rcvbuf nyedhaki 231, jumlah ukuran paket bisa nyebabake integer overflow. Lan amarga iku int, regane dadi negatif, mula kahanan kasebut dadi bener yen kudu salah (sampeyan bisa maca liyane babagan iki ing link).

Kesalahan bisa didandani kanthi cara sing ora pati penting: kanthi casting unsigned int. Aku ngetrapake fix lan miwiti maneh sistem lan DNS bisa digunakake maneh.

Rasa kamenangan

Aku nerusake temuan menyang klien lan dikirim LKML patch kernel. Aku pleased: saben Piece saka teka-teki mathuk bebarengan, Aku bisa nerangake persis apa kita diamati apa kita diamati, lan sing paling Jahwéh, kita bisa nemokake solusi kanggo masalah thanks kanggo kerja tim!

Perlu dingerteni manawa kasus kasebut arang banget, lan untunge kita jarang nampa panjaluk rumit saka pangguna.

Source: www.habr.com