Narratio de absentis DNS facis ex Google Cloud technicis auxiliis

Ex Google diariorum editor: Num unquam miratus es quomodo Google Cloud Solutiones technicae (TSE) fabrum petitiones tuas subsidium tractant? TSE Technical Support Engineers authores sunt ad cognoscendas et corrigendas usor-relatos problematum fontes. Quaedam ex his quaestionibus admodum simplicia sunt, sed interdum tessera occurreris quae plurium fabrum simul attentionem requirit. In hoc articulo, unus ex operariis TSE nobis narrabit de uno problemate valde captioso ex recenti usu suo - causa absentis DNS facis. In hac fabula videbimus quomodo res componendas fabrum egerit, et quae res novas in errore figentes didicerint. Speramus hanc fabulam non solum te de cimex penitus sedentem erudire, sed etiam perspectionem in processibus, qui tesseram Google Cloud interponere ineunt.

Fermentum est scientia et ars. Totum incipit cum aedificare hypothesin circa rationem agendi ratio non vexillum, post quam pro viribus probatur. Sed antequam hypothesin proponamus, clare definire ac praecise rem proponere oportet. Si quaestio nimis obscura sonat, omnia diligenter resolvere debebis; Haec est ars fermentum.

Sub Google Cloud, tales processus exponentialiter magis implicati fiunt, sicut Google Cloud suum optime studet intimitatem usorum suorum praestare. Propter hoc, TSE fabrum non habent accessum ad systemata tua emendandi, nec facultates videndi configurationes tam late quam utentes facere. Ergo ut quaelibet hypothesium nostrarum tentatio, nos non cito systema mitigare possumus.

Quidam usores putant nos omnia sicut mechanica in autocineto destinare et simpliciter id nobis mittere machinae virtualis, cum revera processus fiat in forma sermonis colloquii: informationes colligendi, hypotheses formandi et confirmandi (vel refellendi); et, ad extremum, problemata decisionem communicant cum client.

Quaestio in quaestione

Hodie cum bono fine fabulam habemus. Una ex causis in casu solutionis prospere propositi est accuratissima quaestionis descriptio. Infra videre potes exemplum primae tesserae (edita notitia secreta occultare);

Epistula hic multum utilis nobis notitia continet:

• Imprimis VM certa
• Quaestio ipsa indicatur - DNS non operatur
• Indicatur ubi quaestio se manifestat VM et continens
• Gradus usoris ad cognoscendum quaestionem demonstraverunt.

Rogatio relatus est "P1: Impact Critical - Service in productione inutile", quod significat constantem vigilantiam condicionis 24/7 secundum rationem "Sequere Solem" (de eo legere potes. prioritatibus user petitiones) cum sua translatione ab uno technico subsidii equos ad alterum cum zona trabea singulis vicibus. Re vera, per tempus quaestionis nostrae turmae in Zurich pervenit, iam orbem cingit. Iam usor deminutio mensuras acceperat, sed timebat iterationem condicionis in productione, cum causa radix nondum inventa esset.

Per tempus tesseram Tiguri perventum est, iam sequentia indicia in manibus habuimus;

• Summa /etc/hosts
• Summa /etc/resolv.conf
• conclusio, iptables-save
• Convenerunt per bigas ngrep pcap file

Hac notitia, "investigationem" et fermentum periodum incipere parati eramus.

Primus gradus

Ante omnia tigna et statum metadatae servientis repressimus et recte operatum esse fecimus. Metadata server cum inscriptione IP 169.254.169.254 respondet et, inter alia, est responsabilis nomina dominii moderandi. Etiam duplex repressus est firewall cum VM recte operari et facis non impedit.

Mira quaedam quaestio fuit: nmap perscriptio refutata hypothesin principalem nostram de amissione UDP facis, ideo mente pervenerunt cum pluribus optionibus et modis eas coercendi:

• Electiones omissae sunt facis? => Reprehendo praecepta iptables
• Nonne nimis parva est? MTU? => Reprehendo output ip a show
• An problema tantum UDP facis vel TCP quoque afficit? => Depelle dig +tcp
• Effoditur generatae fasciculi redditus? => Depelle tcpdump
• Estne libdns recte opus? => Depelle strace ut reprimendam tradenda facis utrinque

Hic statuimus ut difficultates utentis ad troubleshoot vocare vivant.

Per vocationem possumus plura reprimere;

• Post varias rationes iptables regulas ex elencho causarum excludimus
• Retiacula interfaces et tabulas excitandas reprimimus et duplex perscriptio quod MTU verum est
• Invenimus quod dig +tcp google.com (TCP) operatur ut debet, sed dig google.com (UDP) non operatur
• Eiecto tcpdump suus 'etiam opus diginvenimus UDP facis redditum
• Nos expellamus strace dig google.com et videmus quomodo recte vocat fodere sendmsg() и recvms()interrumpitur tamen alter per timetorium

Infeliciter, finis mutationis advenit et nos quaestionem proximo tempore zonam effugere cogimur. Postulatio autem interest in quadrigis nostris, et collega innuit sarcinam primam DNS creando modulo rasorio Pythone utens.

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

Hoc fragmentum fasciculum DNS creat et rogationem ad metadata server mittit.

Usoris codicem decurrit, responsio DNS redditur, et applicatio eam accipit, confirmans nullum problema in retiaculorum gradu esse.

Post aliud "per iter mundi" petitio ad equos nostros redit, et ad me ipsum omnino transfero, ratus commodiorem fore usori si petitio cessat de loco in locum.

Interea usor benigne consentit ad imaginem imaginis scapham praebere. Hoc est ipsum bonum nuntium: facultatem explorandi systema me movet sollicitudinis multo velocius, quia non amplius quaero utentem ad mandata currendi, mitte mihi eventus et eas resolvere, omnia me facere possum!

Collegae mei mihi paululum invideant. Super prandio conversionem discutimus, sed nemo quid agatur. Fortunate, ipse usor iam consilia ad consectaria mitiganda et properat, sic tempus est ut quaestionem dissecet. Et quoniam habemus imaginem, currere possumus quodlibet probat quod interest nobis. Magna!

Is cum gradum retro

Una ex maxime popularibus colloquium quaestiones pro systematibus fectum positionum est: "Quid accidit cum ping" www.google.com? Magna quaestio est, quia candidatus omnia e testa ad spatium usoris describere, ad nucleum systematis et deinde ad aeneam debet. Rideo: interdum colloquium quaestiones eveniat utiles in vita reali ...

Constituo hanc HR quaestionem adhibere ad quaestionem hodiernam. Dure loquendo, cum DNS nomen determinare conaris, sequentia fiunt;

1. Applicatio bibliothecam systematis vocat ut libdns
2. libdns inhibet conformationem systematis cui DNS ministrans debet contactum (in schemate hoc est 169.254.169.254, metadata servo)
3. libdns systematis utitur vocat ad UDP nervum (SOKET_DGRAM) creandum et UDP facis cum interrogatione DNS utrobique mitte.
4. Per sysctl interfaciei UDP acervum configurare potes ad gradum nuclei
5. Penitus nucleus cum ferramento ut transmittat facis per retis interfaces retis
6. Hypervisor fasciculum ad metadata servo comprehendit ac transmittit in contactu cum eo
7. Metadata server, sua magica, nomen DNS determinat et responsionem eodem modo reddit

Quas hypotheses iam perpendamus, admoneam te;

Hypothesis: Bibliothecae fracti

• Test 1: stramen in systemate detege, fode qui vocat rectam systema vocat
• Consequuntur: Recta ratio vocat dicuntur
• Test 2: per srapy ad reprimendam num nominare praetereuntes bibliothecas systematis determinare possumus
• Consequuntur: possumus
• Test 3: run rpm -V in sarcina libdns et md5sum fasciculi bibliothecae
• Consequuntur: in bibliotheca codice prorsus idem est cum codice in operando systemate operando
• Test 4: conscende radicem systematis utentis in a VM sine moribus, curre chroot, vide an DNS opera
• Consequuntur: DNS bene operatur

Conclusio secundum probat: quaestio non est in bibliothecis

Hypothesis est error in DNS occasus

• Test 1: reprime tcpdump et vide an DNS fasciculi mittantur et recte post currendo fodiantur
• Consequuntur: facis recte traducuntur
• Test 2: geminus reprehendo in calculonis servi /etc/nsswitch.conf и /etc/resolv.conf
• Consequuntur: omnia bene

Conclusio secundum probat: quaestio non est cum DNS configuratione

Hypothesis: core laesa

• Test: novum nucleum install, subscriptio reprehendo, sileo
• Consequuntur: similes mores

Conclusio secundum probat: nucleus non corrumpitur

Hypothesis: falsa mores in user network (sive hypervisor network interface)

• Test I: firewall Reprehendo vestri occasus
• Consequuntur: firewall transit DNS facis in utroque exercitu et GCP
• Test 2: intercipere negotiationem et monitor rectitudinem tradendi ac reditum petitionum DNS
• Consequuntur: tcpdump confirmat reditus facis exercitum accepisse

Conclusio secundum probat: quaestio non est in network

Hypothesis est metadata server non operatur

• Test I: reprehendo metadata server acta anomaliae
• Consequuntur: nulla anomalia in lignis sunt
• Test II: bypass metadata servo via dig @8.8.8.8
• Consequuntur: Resolutio rumpitur etiam sine metadata servo

Conclusio secundum probat: quaestio non est cum metadata server

Bottom linea: temptavimus omnia subsystems praeter runtime occasus!

Tribuo in Kernel Runtime Occasus

Ad ambitum nuclei exsecutionis configurare, iubere optiones lineae (grub) vel sysctl interfaciei uti potes. Vidi in /etc/sysctl.conf et mox, opinor, varios usus occasus indagavi. Sententia quasi in aliquid apprehendissem, omnes non-retis vel non-tcp occasus abieci, remanentibus omissis montanis. net.core. Et ivi ad ubi erant permissiones hospicii in VM, et incepi applicando uncinis per singula, per unum post alium, fracto VM, donec invenero rea;

net.core.rmem_default = 2147483647

Hic est figura DNS fractionis! homicidium telum inveni. Sed quid hoc est? Mihi adhuc opus est motivo.

DNS basic quiddam mole fasciculum configuratur via net.core.rmem_default. Valor typica alicubi est circa 200KiB, sed si servo tuo multum DNS fasciculos accipit, amplitudinem quiddam augere velis. Si quiddam plenum est cum novus fasciculus advenit, exempli gratia, quia applicatio non satis celeriter processit, tunc fasciculos amittere incipies. Cliens noster recte magnitudinem quiddam auxit quod damnorum notitiarum timebat, cum applicatione ad metricos colligendos per DNS facis utebatur. Valor quam posuit, erat maximum possibile: 231-1 (si ad 231 positos, nucleus "ARGUMENTUM CAUSAM reddet").

Subito intellexi cur nmap et scapylum recte operatum sit: basibus rudibus utebantur! Rudis bases a regularibus basibus diversae sunt: ​​iptables praetereunt et non sunt buffered!

Sed cur "quiddam nimis magnum" problemata causat? Scilicet quod in animo non operatur.

Hoc loco quaestionem de multis nucleis et multiplicibus distributionibus potui referre. Quaestio iam in 3.x nucleo apparuit et nunc etiam in 5.x nucleo apparuit.

Immo ad startup

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

DNS ab opere.

Incepi operandi valores per algorithmum simplex binarii inquisitionis et inveni systema operatum cum 2147481343, sed numerus hic numerus mihi inanis numerus erat. Hunc numerum clientem probavi et respondit systema google.com operatum esse, sed tamen errorem cum aliis ditionibus dedit, sic investigationem meam perseueravi.

Ego sum installed dropwatchinstrumentum, quod antea adhiberi debuit: exacte demonstrat ubi in nucleo lecti desinat. Reus est munus udp_queue_rcv_skb. Ego fontes nucleos deieci et pauca addidi munus printk ad inuestigandum ubi prorsus fasciculus desinit. Cito inveni ius conditio ifet simpliciter inspexerunt illud per aliquod tempus, quia tunc omnia demum in totam picturam convenerunt: 231-1, numerus inanis, in non operando... Erat particula codicis in __udp_enqueue_schedule_skb:

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

Placere note:

• rmem est genus int
• size est genus u16 (unsigned sedecim frenum int) et addit fasciculum magnitudine
• sk->sk_rcybuf int genus est ac reponit quiddam quantitatis, quod, definitione, aequatur valore in net.core.rmem_default

quod sk_rcvbuf accedit CCXXXI, quoquo fasciculus in magnitudine inveniatur integer redundantiam. Et cum illud int, eius valor negativus fit, condicio vera fit cum falsa sit (de hoc tempore plura legere potes. Link).

Error in triviali modo emendari potest: ejiciendo unsigned int. Ego rem figere et systema relevi et DNS iterum laboravi.

Gustus victoriae

Transmisit me inventa ad clientem et misit LKML nucleum panni. Placet mihi: singulas partes aenigmatis cohaeret, exacte possum explicare cur animadvertimus quid animadvertimus, ac potissimum, potuimus solutionem problemati nostro labore invenire!

Dignum est agnoscere casus rarus esse, et raro peropportune huiusmodi postulationes multiplices ab utentibus accipimus.

Source: www.habr.com