Eng Geschicht iwwer fehlend DNS Pakete vu Google Cloud technescher Support

Vum Google Blog Editor: Hutt Dir jeemools gefrot wéi Google Cloud Technical Solutions (TSE) Ingenieuren Är Support Ufroe behandelen? TSE Technesch Ënnerstëtzung Ingenieuren si verantwortlech fir d'Identifikatioun an d'korrektur vun de Benotzer gemellt Quelle vu Probleemer. E puer vun dëse Problemer sinn zimlech einfach, awer heiansdo kommt Dir op en Ticket deen d'Opmierksamkeet vu verschiddenen Ingenieuren op eemol erfuerdert. An dësem Artikel wäert ee vun den TSE Mataarbechter eis iwwer ee ganz komplizéierte Problem aus senger rezenter Praxis soen - Fall vu fehlend DNS Päck. An dëser Geschicht wäerte mir gesinn wéi d'Ingenieuren et fäerdeg bruecht hunn d'Situatioun ze léisen, a wéi eng nei Saachen se geléiert hunn wärend de Feeler fixéiert gouf. Mir hoffen, datt dës Geschicht Iech net nëmmen iwwer en déif sëtze Käfer educéiert, mee gëtt Iech och Abléck an d'Prozesser, déi an d'Aschreiwung vun engem Support Ticket mat Google Cloud goen.

Troubleshooting ass souwuel eng Wëssenschaft wéi och eng Konscht. Et fänkt alles un mat enger Hypothese iwwer de Grond fir dat net-Standardverhalen vum System ze bauen, duerno gëtt et fir d'Kraaft getest. Wéi och ëmmer, ier mir eng Hypothese formuléieren, musse mir de Problem kloer definéieren a präzis formuléieren. Wann d'Fro ze vague kléngt, da musst Dir alles virsiichteg analyséieren; Dëst ass d'"Konscht" vun der Troubleshooting.

Ënner Google Cloud ginn esou Prozesser exponentiell méi komplex, well Google Cloud probéiert säi Bescht fir d'Privatsphär vu senge Benotzer ze garantéieren. Dofir hunn TSE Ingenieuren keen Zougang fir Är Systemer z'änneren, nach d'Fäegkeet Konfiguratiounen esou breet ze gesinn wéi d'Benotzer maachen. Dofir, fir eng vun eisen Hypothesen ze testen, kënne mir (Ingenieuren) de System net séier änneren.

E puer Benotzer gleewen datt mir alles wéi Mechanik an engem Autosservice fixéieren an eis einfach d'Id vun enger virtueller Maschinn schécken, wärend de Prozess an der Realitéit an engem Gespréichsformat stattfënnt: Informatioun sammelen, Hypothesen formen a bestätegt (oder refuséieren), an, um Enn, eng Decisioun Problemer sinn baséiert op Kommunikatioun mam Client.

Problem a Fro

Haut hu mir eng Geschicht mat engem gudden Enn. Ee vun de Grënn fir déi erfollegräich Léisung vum proposéierte Fall ass eng ganz detailléiert a korrekt Beschreiwung vum Problem. Hei ënnen kënnt Dir eng Kopie vum éischten Ticket gesinn (editéiert fir vertraulech Informatioun ze verstoppen):

Dëse Message enthält vill nëtzlech Informatioun fir eis:

• Spezifesch VM spezifizéiert
• De Problem selwer gëtt uginn - DNS funktionnéiert net
• Et gëtt uginn wou de Problem sech manifestéiert - VM a Container
• D'Schrëtt déi de Benotzer gemaach huet fir de Problem z'identifizéieren ginn uginn.

D'Ufro gouf registréiert als "P1: Critical Impact - Service Unusable in Production", dat heescht konstant Iwwerwaachung vun der Situatioun 24/7 no dem Schema "Follow the Sun" (Dir kënnt méi iwwer liesen Prioritéite vun Benotzer Demanden), mat sengem Transfert vun engem techneschen Supportteam an en anert mat all Zäitzonverschiebung. Tatsächlech, wéi de Problem eis Team zu Zürich erreecht huet, war et scho ronderëm de Globus. Zu dëser Zäit huet de Benotzer Mitigatiounsmoossname geholl, awer huet Angscht virun enger Widderhuelung vun der Situatioun an der Produktioun, well d'Ursaach vun der Ursaach nach net entdeckt gouf.

Wéi den Ticket Zürich ukomm ass, hate mir schonn déi folgend Informatiounen zur Hand:

• Inhalt /etc/hosts
• Inhalt /etc/resolv.conf
• Konklusioun iptables-save
• Assemblée vun der Equipe ngrep pcap Datei

Mat dësen Donnéeën ware mir prett fir d'"Enquête" an d'Problembehandlungsphase unzefänken.

Eis éischt Schrëtt

Als éischt hu mir d'Logbicher an de Status vum Metadatenserver gepréift a séchergestallt datt et richteg funktionnéiert. De Metadatenserver reagéiert op d'IP Adress 169.254.169.254 an ass ënner anerem verantwortlech fir d'Kontroll vun Domain Nimm. Mir hunn och duebel gepréift datt d'Firewall richteg mat der VM funktionnéiert an net Päckchen blockéiert.

Et war eng Aart vu komesche Problem: den nmap Scheck huet eis Haapthypothese iwwer de Verloscht vun UDP Pakete refuséiert, sou datt mir geeschteg mat e puer méi Optiounen a Weeër kommen fir se ze kontrolléieren:

• Ginn Pakete selektiv erofgelooss? => Check iptables Regelen
• Ass et net ze kleng? Jonge? => Ausgang kontrolléieren ip a show
• Betraff de Problem nëmmen UDP Pakete oder TCP och? => Fuert ewech dig +tcp
• Ginn grave generéiert Pakete zréckginn? => Fuert ewech tcpdump
• Wierkt libdns richteg? => Fuert ewech strace fir d'Transmissioun vu Päck a béid Richtungen ze kontrolléieren

Hei decidéiere mir de Benotzer ze ruffen fir Problemer live ze léisen.

Wärend dem Uruff kënne mir verschidde Saache kontrolléieren:

• No e puer Kontrollen ausgeschloss mir iptables Regelen aus der Lëscht vun Grënn
• Mir kontrolléieren Reseau Schnëttplazen an Routing Dëscher, an duebel-Check datt d'MTU richteg ass
• Mir entdecken dat dig +tcp google.com (TCP) Wierker wéi et soll, mä dig google.com (UDP) funktionnéiert net
• Fortgefuer ze hunn tcpdump et schafft nach ëmmer dig, Mir fannen datt UDP Pakete zréckginn
• Mir fueren ewech strace dig google.com a mir gesinn wéi grave richteg rifft sendmsg() и recvms(), allerdéngs gëtt deen zweete vun engem Timeout ënnerbrach

Leider kënnt d'Enn vun der Verréckelung a mir si gezwongen de Problem an déi nächst Zäitzone ze eskaléieren. D'Ufro huet awer d'Interesse an eisem Team erwächt, an e Kolleg proposéiert den initialen DNS-Paket mat dem scrapy Python-Modul ze kreéieren.

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

Dëst Fragment erstellt en DNS-Paket a schéckt d'Ufro un de Metadatenserver.

De Benotzer leeft de Code, d'DNS Äntwert gëtt zréck, an d'Applikatioun kritt et, bestätegen datt et kee Problem um Netzwierkniveau ass.

No enger weiderer "Weltrees" geet d'Ufro un eis Team zréck, an ech iwwerdroe se komplett op mech selwer, denken datt et méi bequem ass fir de Benotzer wann d'Ufro ophält vu Plaz zu Plaz ze kreesen.

An der Tëschenzäit ass de Benotzer frëndlech averstanen e Snapshot vum Systembild ze bidden. Dëst ass ganz gutt Noriicht: d'Kapazitéit fir de System selwer ze testen mécht d'Problembehandlung vill méi séier, well ech de Benotzer net méi muss froen fir Kommandoen auszeféieren, mir d'Resultater ze schécken an ze analyséieren, ech kann alles selwer maachen!

Meng Kollegen fänken un mech e bëssen ze beneiden. Iwwer Mëttegiessen diskutéiere mir iwwer d'Konversioun, awer keen huet eng Ahnung wat lass ass. Glécklecherweis huet de Benotzer selwer scho Moossname geholl fir d'Konsequenzen ze reduzéieren an ass net presséiert, also hu mir Zäit fir de Problem ze dissektéieren. A well mir e Bild hunn, kënne mir all Tester maachen déi eis interesséieren. Super!

E Schrëtt zréck ze huelen

Eng vun de populäersten Interviewfroe fir Systemingenieur Positiounen ass: "Wat geschitt wann Dir pingt www.google.com? D'Fro ass grouss, well de Kandidat muss alles vun der Shell bis zum Benotzerraum, zum Systemkär an dann zum Netz beschreiwen. Ech laachen: heiansdo ginn Interviewfroen am richtege Liewen nëtzlech ...

Ech décidéieren dës HR Fro op en aktuelle Problem ze gëllen. Grof geschwat, wann Dir probéiert en DNS Numm ze bestëmmen, geschitt déi folgend:

1. D'Applikatioun rifft eng Systembibliothéik wéi libdns
2. libdns kontrolléiert d'Systemkonfiguratioun op wéi en DNS-Server et soll kontaktéieren (am Diagramm ass dëst 169.254.169.254, Metadatenserver)
3. libdns benotzt System Appellen fir en UDP Socket (SOKET_DGRAM) ze kreéieren an UDP Päck mat enger DNS Ufro a béid Richtungen ze schécken
4. Duerch d'sysctl Interface kënnt Dir den UDP Stack um Kernel Niveau konfiguréieren
5. De Kernel interagéiert mat der Hardware fir Päckchen iwwer d'Netz iwwer d'Netzwierk-Interface ze vermëttelen
6. Den Hypervisor fangt an iwwerdréit de Paket op de Metadatenserver beim Kontakt mat him
7. De Metadatenserver, duerch seng Magie, bestëmmt den DNS-Numm a gitt eng Äntwert mat der selwechter Method zréck

Loosst mech Iech drun erënneren wéi eng Hypothesen mir scho berücksichtegt hunn:

Hypothese: Broken Bibliothéiken

• Test 1: lafen Strace am System, kontrolléiert datt d'Graf déi richteg Systemriff rifft
• Resultat: Korrekt System Uriff ginn genannt
• Test 2: benotzt Srapy fir ze kontrolléieren ob mir Nimm kënne bestëmmen déi Systembibliothéiken ëmgoen
• Resultat: mir kënnen
• Test 3: Run rpm -V op de libdns Package an md5sum Bibliothéik Dateien
• Resultat: de Bibliothéikscode ass komplett identesch mam Code am funktionnéierende Betribssystem
• Test 4: montéiert de Benotzer säi Root System Bild op engem VM ouni dëst Verhalen, lafen Chroot, kuckt ob DNS funktionnéiert
• Resultat: DNS funktionnéiert richteg

Conclusioun baséiert op Tester: de Problem ass net an de Bibliothéiken

Hypothese: Et gëtt e Feeler an den DNS-Astellungen

• Test 1: kontrolléiert tcpdump a kuckt ob DNS Pakete geschéckt ginn a richteg zréckginn nodeems Dir d'Grav leeft
• Resultat: Pakete gi korrekt iwwerdroen
• Test 2: duebel kontrolléieren op de Server /etc/nsswitch.conf и /etc/resolv.conf
• Resultat: alles ass richteg

Conclusioun baséiert op Tester: de Problem ass net mat der DNS Konfiguratioun

Hypothes: Kär beschiedegt

• Test: neie Kernel installéieren, Ënnerschrëft kontrolléieren, nei starten
• Resultat: ähnlecht Verhalen

Conclusioun baséiert op Tester: de Kär ass net beschiedegt

Hypothese: falscht Verhalen vum Benotzernetz (oder Hypervisor Netzwierk Interface)

• Test 1: Kontrolléiert Är Firewall Astellungen
• Resultat: d'Firewall passéiert DNS Pakete souwuel um Host wéi och op GCP
• Test 2: Traffic offangen an d'Korrektheet vun der Iwwerdroung an der Retour vun DNS-Ufroen iwwerwaachen
• Resultat: tcpdump bestätegt datt de Host Retourpakete kritt huet

Conclusioun baséiert op Tester: de Problem ass net am Netz

Hypothes: de Metadatenserver funktionnéiert net

• Test 1: kontrolléiert d'Metadatenserver Logbicher fir Anomalien
• Resultat: et gi keng Anomalien an de Logbicher
• Test 2: Bypass de Metadatenserver iwwer dig @8.8.8.8
• Resultat: D'Resolutioun ass gebrach och ouni e Metadatenserver ze benotzen

Conclusioun baséiert op Tester: de Problem ass net mam Metadatenserver

Stréch: mir getest all subsystems ausser Runtime Astellunge!

Taucht an Kernel Runtime Astellungen

Fir de Kernel Ausféierungsëmfeld ze konfiguréieren, kënnt Dir Kommandozeiloptiounen (grub) oder d'sysctl Interface benotzen. Ech hu gekuckt /etc/sysctl.conf an just denken, Ech entdeckt puer Mooss Astellunge. Gefill wéi wann ech eppes gegraff hätt, hunn ech all Net-Netz- oder Net-tcp-Astellunge verworf, bleiwen mat de Biergastellungen net.core. Dunn sinn ech gaang wou d'Host Permissiounen am VM waren an hunn ugefaang d'Astellungen een nom aneren, een nom aneren, mat dem futtis VM anzesetzen, bis ech den Täter fonnt hunn:

net.core.rmem_default = 2147483647

Hei ass et, eng DNS-breaking Konfiguratioun! Ech hunn d'Mordwaff fonnt. Awer firwat ass dat geschitt? Ech brauch nach e Motiv.

D'Basis DNS Paketbuffergréisst ass konfiguréiert iwwer net.core.rmem_default. En typesche Wäert ass iergendwou ronderëm 200KiB, awer wann Äre Server vill DNS-Päckchen kritt, wëllt Dir vläicht d'Puffergréisst erhéijen. Wann de Puffer voll ass wann en neie Paket ukomm ass, zum Beispill well d'Applikatioun et net séier genuch veraarbecht, da fänkt Dir un Pakete ze verléieren. Eise Client huet d'Puffergréisst korrekt erhéicht well hien Angscht virun Datenverloscht huet, well hien eng Applikatioun benotzt fir Metriken duerch DNS Päck ze sammelen. De Wäert, deen hie festgeluecht huet, war de Maximum méiglech: 231-1 (wann op 231 gesat gëtt, gëtt de Kärel "INVALID ARGUMENT") zréck.

Op eemol hunn ech gemierkt firwat nmap a scapy richteg funktionnéieren: si hunn rau Sockets benotzt! Raw Sockets sinn anescht wéi normal Sockets: Si ëmgoen iptables, a si sinn net gebuffert!

Awer firwat mécht "Puffer ze grouss" Problemer? Et funktionnéiert kloer net wéi virgesinn.

Zu dësem Zäitpunkt konnt ech de Problem op multiple Kärelen a multiple Verdeelungen reproduzéieren. De Problem ass schonn um 3.x Kernel erschéngt an elo ass et och um 5.x Kernel erschéngt.

Tatsächlech, beim Startup

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

DNS huet opgehalen ze schaffen.

Ech hunn ugefaang no Aarbechtswäerter duerch en einfache binäre Sichalgorithmus ze sichen a fonnt datt de System mat 2147481343 geschafft huet, awer dës Zuel war e sënnlosen Set vun Zuelen fir mech. Ech hunn de Client proposéiert dës Nummer ze probéieren, an hien huet geäntwert datt de System mat google.com geschafft huet, awer nach ëmmer e Feeler mat anere Domainen huet, also hunn ech meng Enquête weidergefouert.

Ech installéiert dropwatch, en Tool dat virdru sollt benotzt ginn: et weist genee wou am Kär e Paket ophält. De Täter war d'Funktioun udp_queue_rcv_skb. Ech hunn d'Kernelquellen erofgelueden an e puer bäigefüügt Funktiounen printk fir ze verfollegen wou genau de Paket ophält. Ech hunn séier de richtegen Zoustand fonnt if, an huet et einfach eng Zäitche gekuckt, well dunn ass alles endlech zu engem ganzt Bild zesummekomm: 231-1, eng sënnlos Zuel, en net funktionéierende Domain... Et war e Stéck Code an __udp_enqueue_schedule_skb:

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

Opgepasst:

• rmem ass vum Typ int
• size ass vum Typ u16 (net ënnerschriwwen siechzéng-Bit int) a späichert d'Pakgréisst
• sk->sk_rcybuf ass vum Typ int a späichert d'Puffergréisst déi, per Definitioun, gläich ass mam Wäert an net.core.rmem_default

Wéini sk_rcvbuf Approche 231, d'Summéiere vun der Paketgréisst kann zu resultéieren ganzt iwwerlaf. A well et en Int ass, gëtt säi Wäert negativ, sou datt d'Konditioun wouer gëtt wann et falsch sollt sinn (Dir kënnt méi doriwwer liesen op Link).

De Feeler kann op eng trivial Manéier korrigéiert ginn: duerch Casting unsigned int. Ech hunn de Fix ugewannt an de System nei gestart an DNS huet erëm geschafft.

Goût vun Victoire

Ech weiderginn meng Conclusiounen dem Client a geschéckt LKML Kernel Patch. Ech si frou: all Puzzlestéck passt zesummen, ech kann genau erklären firwat mir observéiert hunn wat mir observéiert hunn, a virun allem konnten mir dank eisem Teamwork eng Léisung fir de Problem fannen!

Et ass derwäert ze erkennen datt de Fall rar war, a glécklecherweis kréien mir selten esou komplex Ufroe vu Benotzer.

Source: will.com