Carita ngeunaan pakét DNS anu leungit tina dukungan téknis Google Cloud

Ti Google Blog Editor: Naha anjeun kantos panginten kumaha insinyur Google Cloud Technical Solutions (TSE) nanganan pamundut dukungan anjeun? Insinyur dukungan téknis TSE tanggung jawab pikeun ngaidentipikasi sareng ngabenerkeun sumber masalah anu dilaporkeun ku pangguna. Sababaraha masalah ieu cukup basajan, tapi kadang anjeun datang di sakuliah tikét anu merlukeun perhatian sababaraha insinyur sakaligus. Dina artikel ieu, salah sahiji karyawan TSE bakal ngabejaan urang ngeunaan hiji masalah pisan tricky tina prakték panganyarna na - bisi pakét DNS leungit. Dina carita ieu, urang bakal ningali kumaha insinyur junun ngabéréskeun kaayaan, sarta naon hal anyar maranéhna diajar bari ngalereskeun kasalahan. Kami ngarepkeun carita ieu henteu ngan ukur ngadidik anjeun ngeunaan bug anu jero, tapi ogé masihan anjeun wawasan ngeunaan prosés anu badé ngajukeun tikét dukungan sareng Google Cloud.

Ngarengsekeun masalah duanana mangrupa elmu jeung seni. Eta sadayana dimimitian ku ngawangun hipotesa ngeunaan alesan pikeun kabiasaan non-standar sistem, nu satutasna diuji pikeun kakuatan. Sanajan kitu, saméméh urang ngarumuskeun hiji hipotésis, urang kudu jelas nangtukeun tur persis ngarumuskeun masalah. Lamun patarosan disada teuing samar, mangka anjeun kudu nganalisis sagalana taliti; Ieu mangrupikeun "seni" ngungkulan masalah.

Dina Google Cloud, prosés sapertos kitu janten langkung kompleks, sabab Google Cloud nyobian pangsaéna pikeun ngajamin privasi panggunana. Kusabab ieu, insinyur TSE henteu gaduh aksés pikeun ngédit sistem anjeun, atanapi kamampuan pikeun ningali konfigurasi sacara lega sapertos pangguna. Ku alatan éta, pikeun nguji salah sahiji hipotesis urang, urang (insinyur) teu bisa gancang ngarobah sistem.

Sababaraha pamaké yakin yén urang bakal ngalereskeun sagalana kawas mékanika dina layanan mobil, sarta ngan ngirimkeun kami id tina mesin virtual, sedengkeun dina kanyataanana prosés lumangsung dina format conversational: ngumpulkeun informasi, ngabentuk jeung confirming (atawa refuting) hipotesis, jeung, tungtungna, masalah kaputusan anu dumasar kana komunikasi jeung klien nu.

Masalah anu ditaroskeun

Dinten ieu kami gaduh carita kalayan tungtung anu saé. Salah sahiji alesan pikeun ngabéréskeun suksés tina pasualan anu diusulkeun nyaéta pedaran anu lengkep sareng akurat ngeunaan masalah éta. Di handap anjeun tiasa ningali salinan tikét anu munggaran (diédit pikeun nyumputkeun inpormasi rahasia):

Pesen ieu ngandung seueur inpormasi anu mangpaat pikeun urang:

• VM husus dieusian
• Masalahna sorangan dituduhkeun - DNS henteu jalan
• Ieu dituduhkeun dimana masalah manifests sorangan - VM jeung wadahna
• Léngkah anu dilakukeun ku pangguna pikeun ngaidentipikasi masalah dituduhkeun.

Paménta kadaptar salaku "P1: Dampak Kritis - Jasa Teu Bisa Digunakeun dina Produksi", anu hartosna ngawaskeun kaayaan 24/7 numutkeun skéma "Tuturkeun Panonpoé" (anjeun tiasa maca langkung seueur ngeunaan prioritas requests pamaké), kalayan transferna ti hiji tim pangrojong téknis ka anu sanés kalayan unggal shift zona waktos. Nyatana, nalika masalahna dugi ka tim kami di Zurich, éta parantos ngurilingan dunya. Ku waktu ieu, pamaké geus nyokot ukuran mitigasi, tapi sieun ulangan kaayaan dina produksi, sabab akar sabab teu acan kapanggih.

Nalika tikét dugi ka Zurich, kami parantos ngagaduhan inpormasi ieu:

• Eusi /etc/hosts
• Eusi /etc/resolv.conf
• kacindekan iptables-save
• Dikumpulkeun ku tim ngrep file pcap

Kalayan data ieu, kami siap ngamimitian "panalungtikan" sareng fase ngungkulan.

Léngkah munggaran urang

Anu mimiti, urang pariksa log sareng status server metadata sareng mastikeun yén éta jalanna leres. Pangladén metadata ngaréspon kana alamat IP 169.254.169.254 sareng, diantarana, tanggung jawab pikeun ngatur nami domain. Kami ogé pariksa dua kali yén firewall tiasa dianggo leres sareng VM sareng henteu meungpeuk pakét.

Ieu mangrupikeun masalah anu anéh: cék nmap nolak hipotésis utama urang ngeunaan leungitna pakét UDP, ku kituna urang sacara mental datang sareng sababaraha pilihan sareng cara pikeun mariksa aranjeunna:

• Naha pakét turun sacara selektif? => Pariksa aturan iptables
• Teu leutik teuing? JALMA? => Pariksa kaluaran ip a show
• Naha masalahna ngan ukur mangaruhan pakét UDP atanapi TCP ogé? => Ngajauhan dig +tcp
• Dupi dig dihasilkeun pakét balik? => Ngajauhan tcpdump
• Naha libdns jalanna leres? => Ngajauhan strace pikeun mariksa pangiriman pakét dina dua arah

Di dieu urang mutuskeun pikeun nelepon pamaké pikeun troubleshoot masalah langsung.

Nalika nelepon kami tiasa pariksa sababaraha hal:

• Saatos sababaraha cék kami ngaluarkeun aturan iptables tina daptar alesan
• Urang pariksa interfaces jaringan sarta tabel routing, sarta ganda-pariksa yén MTU bener
• Urang manggihan éta dig +tcp google.com (TCP) jalan sakumaha sakuduna, tapi dig google.com (UDP) teu jalan
• Sanggeus diusir tcpdump éta masih jalan dig, urang manggihan yén pakét UDP keur balik
• Urang ngajauhan strace dig google.com sarta kami ningali kumaha dig neuleu nelepon sendmsg() и recvms(), tapi anu kadua diganggu ku seep

Hanjakal, ahir shift anjog sarta kami kapaksa escalate masalah ka zona waktos salajengna. Paménta, kumaha oge, ngahudangkeun minat tim kami, sareng batur sapagawean nyarankeun nyiptakeun pakét DNS awal nganggo modul Python anu 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())

Fragmén ieu nyiptakeun pakét DNS sareng ngirim pamundut ka pangladén metadata.

Pamaké ngajalankeun kode, réspon DNS dipulangkeun, sareng aplikasi nampi éta, mastikeun yén teu aya masalah dina tingkat jaringan.

Saatos "perjalanan babak-dunya" anu sanés, pamenta balik deui ka tim kami, sareng kuring leres-leres nransferkeunana ka diri kuring, mikir yén éta bakal langkung gampang pikeun pangguna upami pamundutna eureun ngurilingan ti hiji tempat ka tempat.

Samentawis éta, pangguna satuju pikeun nyayogikeun gambar gambar sistem. Ieu warta anu saé pisan: kamampuan pikeun nguji sistem sorangan ngajadikeun masalah langkung gancang, sabab kuring henteu kedah naroskeun ka pangguna pikeun ngajalankeun paréntah, kirimkeun hasil sareng analisa aranjeunna, kuring tiasa ngalakukeun sadayana nyalira!

Babaturan kuring mimiti sirik ka kuring. Leuwih dahar beurang urang ngabahas konvérsi, tapi teu saurang ogé boga pamanggih naon anu lumangsung. Untungna, pangguna nyalira parantos nyandak ukuran pikeun ngirangan akibat sareng henteu buru-buru, janten urang gaduh waktos pikeun ngabedah masalahna. Sarta saprak urang boga hiji gambar, urang tiasa ngajalankeun sagala tés nu dipikaresep ku urang. Hebat!

Mundur saléngkah

Salah sahiji patarosan wawancara anu paling populér pikeun posisi insinyur sistem nyaéta: "Naon anu kajantenan nalika anjeun ping www.google.com? Patarosanna hébat, sabab calon kedah ngajelaskeun sadayana tina cangkang ka rohangan pangguna, ka kernel sistem teras ka jaringan. Kuring seuri: sakapeung patarosan wawancara tétéla mangpaat dina kahirupan nyata ...

Kuring mutuskeun pikeun nerapkeun patarosan HR ieu kana masalah ayeuna. Sacara kasar, nalika anjeun nyobian nangtukeun nami DNS, ieu kajadian:

1. Aplikasi nyauran perpustakaan sistem sapertos libdns
2. libdns mariksa konfigurasi sistem dimana server DNS kedah ngahubungi (dina diagram ieu 169.254.169.254, server metadata)
3. libdns nganggo sauran sistem pikeun nyiptakeun stop kontak UDP (SOKET_DGRAM) sareng ngirim pakét UDP kalayan pamundut DNS dina dua arah.
4. Ngaliwatan panganteur sysctl anjeun tiasa ngonpigurasikeun tumpukan UDP dina tingkat kernel
5. Kernel berinteraksi sareng hardware pikeun ngirimkeun pakét dina jaringan ngalangkungan antarmuka jaringan
6. Hypervisor nangkep sareng ngirimkeun pakét ka server metadata nalika kontak sareng éta
7. Server metadata, ku sihirna, nangtukeun nami DNS sareng ngabalikeun réspon nganggo metodeu anu sami

Hayu atuh ngingetkeun anjeun naon hipotesis kami geus dianggap:

Hipotesis: Perpustakaan rusak

• Tés 1: ngajalankeun strace dina sistem, pariksa yén dig nyaéta panggero sistem bener nelepon
• Hasilna: Telepon sistem anu leres disebut
• Tés 2: ngagunakeun srapy pikeun mariksa naha urang tiasa nangtukeun nami ngalangkungan perpustakaan sistem
• Hasilna: urang tiasa
• Tés 3: ngajalankeun rpm –V dina pakét libdns sareng file perpustakaan md5sum
• Hasilna: kode perpustakaan sagemblengna idéntik jeung kode dina sistem operasi jalan
• Tés 4: pasang gambar sistem akar pangguna dina VM tanpa paripolah ieu, jalankeun chroot, tingali upami DNS jalanna
• Hasilna: DNS jalanna leres

Kacindekan dumasar kana tés: masalahna henteu di perpustakaan

Hipotesis: Aya kasalahan dina setélan DNS

• Test 1: pariksa tcpdump tur tingal lamun pakét DNS dikirim tur balik neuleu sanggeus ngajalankeun dig
• Hasilna: pakét dikirimkeun leres
• Tés 2: pariksa ganda dina server /etc/nsswitch.conf и /etc/resolv.conf
• Hasilna: sadayana leres

Kacindekan dumasar kana tés: masalahna teu jeung konfigurasi DNS

Hipotesis: inti ruksak

• Test: install kernel anyar, pariksa signature, balikan deui
• Hasilna: kabiasaan sarupa

Kacindekan dumasar kana tés: kernel henteu ruksak

Hipotesis: kabiasaan salah sahiji jaringan pamaké (atawa panganteur jaringan hypervisor)

• Tés 1: Pariksa setélan firewall anjeun
• Hasilna: firewall ngalangkungan pakét DNS dina host sareng GCP
• Tés 2: nyegat lalu lintas sareng ngawaskeun kabeneran pangiriman sareng uih deui pamundut DNS
• Hasilna: tcpdump negeskeun yén host parantos nampi pakét mulang

Kacindekan dumasar kana tés: masalahna teu aya dina jaringan

Hipotesis: pangladén metadata henteu jalan

• Tés 1: pariksa log server metadata pikeun anomali
• Hasilna: teu aya anomali dina log
• Tés 2: Jalankeun pangladén metadata via dig @8.8.8.8
• Hasilna: Resolusi rusak sanajan henteu nganggo pangladén metadata

Kacindekan dumasar kana tés: masalahna teu jeung server metadata

Bottom line: kami diuji sakabeh subsistem iwal setélan runtime!

Nyilem kana Setélan Runtime Kernel

Pikeun ngonpigurasikeun lingkungan palaksanaan kernel, anjeun tiasa nganggo pilihan garis paréntah (grub) atanapi antarmuka sysctl. Kuring nempo ka jero /etc/sysctl.conf sarta ngan pikir, Kuring manggihan sababaraha setélan custom. Perasaan saolah-olah kuring nyekel hiji hal, kuring miceun sadaya setélan non-jaringan atanapi non-tcp, sésana sareng setélan gunung. net.core. Teras kuring angkat ka tempat ijin host dina VM sareng mimiti nerapkeun setélan hiji-hiji, hiji-hiji, sareng VM rusak, dugi ka kuring mendakan palaku:

net.core.rmem_default = 2147483647

Ieu, konfigurasi DNS-breaking! Kuring manggihan pakarang rajapati. Tapi naha ieu lumangsung? Kuring masih peryogi motif.

Ukuran panyangga pakét DNS dasar dikonpigurasi via net.core.rmem_default. A nilai has nyaeta wae sabudeureun 200KiB, tapi lamun server anjeun narima loba pakét DNS, Anjeun meureun hoyong ningkatkeun ukuran panyangga. Upami panyangga pinuh nalika pakét énggal sumping, contona kusabab aplikasina henteu ngolah éta cukup gancang, maka anjeun bakal mimiti kaleungitan pakét. Klién kami leres-leres ningkatkeun ukuran panyangga kusabab anjeunna sieun kaleungitan data, sabab anjeunna nganggo aplikasi pikeun ngumpulkeun métrik ngalangkungan pakét DNS. Nilai anjeunna diatur éta maksimum mungkin: 231-1 (upami disetel ka 231, kernel bakal balik "ARGUMEN SALAH").

Ujug-ujug kuring sadar naha nmap sareng scapy damel leres: aranjeunna nganggo socket atah! Sockets atah béda ti sockets biasa: aranjeunna bypass iptables, sarta aranjeunna henteu buffered!

Tapi naha "panyangga badag teuing" ngabalukarkeun masalah? Ieu jelas teu jalan sakumaha dimaksud.

Dina titik ieu kuring bisa baranahan masalah dina sababaraha kernels sarta sababaraha sebaran. Masalahna parantos muncul dina kernel 3.x sareng ayeuna ogé muncul dina kernel 5.x.

Mémang, nalika ngamimitian

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

DNS eureun gawé.

Kuring mimiti milarian nilai anu tiasa dianggo ngaliwatan algoritma pamilarian binér anu saderhana sareng mendakan yén sistemna damel sareng 2147481343, tapi nomer ieu mangrupikeun sakumpulan nomer anu henteu aya gunana pikeun kuring. Kuring ngusulkeun klien nu coba angka ieu, sarta anjeunna ngawaler yén sistem gawé bareng google.com, tapi masih masihan kasalahan jeung domain séjénna, jadi kuring nuluykeun panalungtikan kuring.

Kuring geus dipasang dropwatch, alat anu sakuduna dipaké saméméhna: nembongkeun persis dimana dina kernel pakét a ends up. Pelakuna éta fungsi udp_queue_rcv_skb. Kuring ngundeur sumber kernel sarta ditambahkeun sababaraha fungsi printk pikeun ngalacak dimana persis pakét éta. Kuring gancang mendakan kaayaan anu pas if, sarta ngan saukur neuteup ka dinya pikeun sawatara waktu, sabab éta lajeng sagalana tungtungna datangna babarengan kana sakabeh gambar: 231-1, angka euweuh hartina, domain non-kerja... Ieu sapotong kode dina __udp_enqueue_schedule_skb:

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

Perhatikeun:

• rmem mangrupa tipe int
• size nyaeta tipe u16 (unsigned genep belas-bit int) jeung nyimpen ukuran pakét
• sk->sk_rcybuf mangrupa tipe int sarta nyimpen ukuran panyangga nu, ku harti, sarua jeung nilai di net.core.rmem_default

iraha sk_rcvbuf ngadeukeutan 231, nyimpulkeun ukuran pakét tiasa nyababkeun integer ngabahekeun. Sareng kusabab éta int, nilaina janten négatip, janten kaayaan janten leres nalika kedahna palsu (anjeun tiasa maca langkung seueur ngeunaan ieu di link).

Kasalahan bisa dibenerkeun ku cara trivial: ku casting unsigned int. Kuring dilarapkeun fix jeung restarted sistem na DNS digawé deui.

Rasa meunangna

Kuring diteruskeun papanggihan kuring ka klien tur dikirim LKML patch kernel. Kami pleased: unggal sapotong teka fits babarengan, abdi tiasa ngajelaskeun persis naha urang observasi naon urang observasi, jeung paling importantly, kami bisa manggihan solusi pikeun masalah berkat gawé babarengan kami!

Perlu dipikanyaho yén pasualan éta jarang, sareng untungna urang jarang nampi panjaluk rumit sapertos kitu ti pangguna.

sumber: www.habr.com