Приказна за исчезнатите DNS пакети од техничката поддршка на Google Cloud

Од уредувачот на блог на Google: Дали некогаш сте се запрашале како инженерите на Google Cloud Technical Solutions (TSE) се справуваат со вашите барања за поддршка? Инженерите за техничка поддршка на TSE се одговорни за идентификување и коригирање на изворите на проблеми пријавени од корисниците. Некои од овие проблеми се прилично едноставни, но понекогаш ќе наидете на билет што бара внимание од неколку инженери одеднаш. Во оваа статија, еден од вработените во ТСЕ ќе ни каже за еден многу незгоден проблем од неговата неодамнешна пракса - случај на исчезнати DNS пакети. Во оваа приказна ќе видиме како инженерите успеале да ја решат ситуацијата и какви нови работи научиле додека ја поправале грешката. Се надеваме дека оваа приказна не само што ќе ве едуцира за длабоко вкоренетата грешка, туку и ќе ви даде увид во процесите што одат во поднесувањето на билет за поддршка на Google Cloud.

Решавањето проблеми е и наука и уметност. Сè започнува со изградба на хипотеза за причината за нестандардното однесување на системот, по што се тестира за јачина. Меѓутоа, пред да формулираме хипотеза, мора јасно да го дефинираме и прецизно да го формулираме проблемот. Ако прашањето звучи премногу нејасно, тогаш ќе мора внимателно да анализирате сè; Ова е „уметноста“ на решавање проблеми.

Под Google Cloud, таквите процеси стануваат експоненцијално посложени, бидејќи Google Cloud се труди максимално да ја гарантира приватноста на своите корисници. Поради ова, инженерите на TSE немаат пристап да ги уредуваат вашите системи, ниту можност да ги гледаат конфигурациите толку широко како што имаат корисниците. Затоа, за да тестираме некоја од нашите хипотези, ние (инженерите) не можеме брзо да го модифицираме системот.

Некои корисници веруваат дека ќе поправиме сè како механика во сервис за автомобили и едноставно ќе ни испратиме идентификатор на виртуелна машина, додека во реалноста процесот се одвива во разговорен формат: собирање информации, формирање и потврдување (или побивање) хипотези, и, на крајот, проблемите со одлуката се засноваат на комуникација со клиентот.

Проблем е во прашање

Денес имаме приказна со добар крај. Една од причините за успешно разрешување на предложениот случај е многу детален и точен опис на проблемот. Подолу можете да видите копија од првиот билет (уреден за да се сокријат доверливите информации):

Оваа порака содржи многу корисни информации за нас:

• Наведено е специфично VM
• Самиот проблем е означен - DNS не работи
• Се означува каде се манифестира проблемот - VM и контејнер
• Наведени се чекорите што ги презел корисникот за да го идентификува проблемот.

Барањето е регистрирано како „P1: Critical Impact - Service Unusable in production“, што значи постојано следење на состојбата 24/7 според шемата „Следи го сонцето“ (можете да прочитате повеќе за приоритети на барањата на корисниците), со неговото префрлање од еден тим за техничка поддршка во друг со секое поместување на временската зона. Всушност, додека проблемот стигна до нашиот тим во Цирих, тој веќе го обиколи светот. Во тоа време, корисникот презеде мерки за ублажување, но се плашеше од повторување на ситуацијата во производството, бидејќи основната причина сè уште не беше откриена.

До моментот кога билетот стигна во Цирих, веќе ги имавме при рака следните информации:

• Содржина /etc/hosts
• Содржина /etc/resolv.conf
• Излез iptables-save
• Собрани од тимот ngrep pcap датотека

Со овие податоци, бевме подготвени да ја започнеме фазата на „истрага“ и решавање проблеми.

Нашите први чекори

Прво, ги проверивме дневниците и статусот на серверот за метаподатоци и се уверивме дека работи правилно. Серверот за метаподатоци одговара на IP адресата 169.254.169.254 и, меѓу другото, е одговорен за контрола на имињата на домени. Исто така, двапати проверивме дали заштитниот ѕид работи правилно со VM и не блокира пакети.

Тоа беше некој вид чуден проблем: проверката на nmap ја поби нашата главна хипотеза за губење на UDP пакети, па ментално дојдовме до уште неколку опции и начини да ги провериме:

• Дали пакетите се паѓаат селективно? => Проверете ги правилата на iptables
• Да не е премал? МТУ? => Проверете го излезот ip a show
• Дали проблемот влијае само на UDP пакетите или на TCP? => Возете се dig +tcp
• Дали се враќаат генерираните пакети со ископување? => Возете се tcpdump
• Дали libdns работи правилно? => Возете се strace да се провери преносот на пакетите во двете насоки

Овде решивме да го повикаме корисникот за да ги реши проблемите во живо.

За време на повикот можеме да провериме неколку работи:

• По неколку проверки ги исклучуваме правилата за iptables од листата на причини
• Ги проверуваме мрежните интерфејси и табелите за насочување и проверуваме двапати дали MTU е точен
• Го откриваме тоа dig +tcp google.com (TCP) работи како што треба, но dig google.com (UDP) не работи
• Откако се избркаа tcpdump сè уште работи dig, откриваме дека UDP пакетите се враќаат
• Возиме strace dig google.com и гледаме како копа правилно повикува sendmsg() и recvms(), меѓутоа вториот е прекинат со тајмаут

За жал, пристигнува крајот на смената и принудени сме да го ескалираме проблемот во следната временска зона. Барањето, сепак, предизвика интерес кај нашиот тим, а еден колега предлага создавање на почетниот DNS пакет со помош на модулот за скршени Python.

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

Овој фрагмент создава DNS пакет и го испраќа барањето до серверот за метаподатоци.

Корисникот ја извршува шифрата, одговорот на DNS се враќа и апликацијата го прима, потврдувајќи дека нема проблем на ниво на мрежа.

По уште едно „патување околу светот“, барањето се враќа во нашиот тим и јас целосно го пренесувам на себе, мислејќи дека ќе биде поудобно за корисникот ако барањето престане да кружи од место до место.

Во меѓувреме, корисникот љубезно се согласува да обезбеди слика од сликата на системот. Ова е многу добра вест: можноста за сам тестирање на системот го прави решавањето на проблеми многу побрзо, бидејќи повеќе не морам да барам од корисникот да извршува команди, да ми ги испраќа резултатите и да ги анализира, можам да направам сè сам!

Колегите почнаа малку да ми завидуваат. За време на ручекот разговараме за преобразбата, но никој не знае што се случува. За среќа, самиот корисник веќе има преземено мерки за ублажување на последиците и не се брза, па имаме време да го расечеме проблемот. И бидејќи имаме слика, можеме да извршиме какви било тестови што не интересираат. Одлично!

Направете чекор назад

Едно од најпопуларните прашања за интервју за позиции за системски инженер е: „Што се случува кога пингувате www.google.com? Прашањето е одлично, бидејќи кандидатот треба да опише сè, од школка до кориснички простор, до системското јадро и потоа до мрежата. Се насмевнувам: понекогаш прашањата за интервју испаѓаат корисни во реалниот живот...

Решив да го применам ова прашање за човечки ресурси на актуелен проблем. Грубо кажано, кога се обидувате да одредите име на DNS, се случува следново:

1. Апликацијата повикува системска библиотека како што е libdns
2. libdns ја проверува конфигурацијата на системот до кој DNS сервер треба да контактира (на дијаграмот ова е 169.254.169.254, сервер за метаподатоци)
3. libdns користи системски повици за да создаде UDP приклучок (SOKET_DGRAM) и да испраќа UDP пакети со барање DNS во двете насоки
4. Преку sysctl интерфејсот можете да го конфигурирате стекот UDP на ниво на јадрото
5. Јадрото комуницира со хардверот за да пренесува пакети преку мрежата преку мрежниот интерфејс
6. Хипервизорот го фаќа и го пренесува пакетот до серверот за метаподатоци при контакт со него
7. Серверот за метаподатоци, по својата магија, го одредува името на DNS и враќа одговор користејќи го истиот метод

Дозволете ми да ве потсетам кои хипотези веќе ги разгледавме:

Хипотеза: Скршени библиотеки

• Тест 1: стартувајте траса во системот, проверете дали dig ги повикува точните системски повици
• Резултат: Се повикуваат правилни системски повици
• Тест 2: користење srapy за да провериме дали можеме да одредиме имиња кои ги заобиколуваат системските библиотеки
• Резултат: можеме
• Тест 3: извршете rpm –V на пакетот libdns и датотеките од библиотеката md5sum
• Резултат: кодот на библиотеката е целосно идентичен со кодот во работниот оперативен систем
• Тест 4: монтирајте ја сликата на коренскиот систем на корисникот на VM без ова однесување, стартувајте го chroot, проверете дали DNS работи
• Резултат: DNS работи правилно

Заклучок врз основа на тестови: проблемот не е во библиотеките

Хипотеза: Има грешка во поставките за DNS

• Тест 1: проверете го tcpdump и проверете дали DNS пакетите се испраќаат и се враќаат правилно по извршувањето на ископувањето
• Резултат: пакетите се пренесуваат правилно
• Тест 2: двојна проверка на серверот /etc/nsswitch.conf и /etc/resolv.conf
• Резултат: сè е точно

Заклучок врз основа на тестови: проблемот не е во DNS конфигурацијата

Хипотеза: јадрото е оштетено

• Тест: инсталирајте ново јадро, проверете го потписот, рестартирајте
• Резултат: слично однесување

Заклучок врз основа на тестови: јадрото не е оштетено

Хипотеза: неправилно однесување на корисничката мрежа (или мрежен интерфејс на хипервизорот)

• Тест 1: Проверете ги поставките за заштитен ѕид
• Резултат: заштитниот ѕид поминува DNS пакети и на домаќинот и на GCP
• Тест 2: пресретнете го сообраќајот и следете ја исправноста на преносот и враќањето на барањата за DNS
• Резултат: tcpdump потврдува дека домаќинот добил повратни пакети

Заклучок врз основа на тестови: проблемот не е во мрежата

Хипотеза: серверот за метаподатоци не работи

• Тест 1: проверете ги дневниците на серверот за метаподатоци за аномалии
• Резултат: нема аномалии во дневниците
• Тест 2: Заобиколете го серверот за метаподатоци преку dig @8.8.8.8
• Резултат: Резолуцијата е прекината дури и без користење на сервер за метаподатоци

Заклучок врз основа на тестови: проблемот не е во серверот за метаподатоци

Во крајна линија: ги тестиравме сите потсистеми освен поставки за време на траење!

Нуркање во поставките за траење на кернелот

За да ја конфигурирате околината за извршување на кернелот, можете да ги користите опциите на командната линија (grub) или интерфејсот sysctl. Погледнав внатре /etc/sysctl.conf и само размислете, открив неколку сопствени поставки. Чувствувајќи се како да сум зграпчил нешто, ги отфрлив сите поставки кои не се мрежни или не-tcp, останувајќи со поставките за планина net.core. Потоа отидов до местото каде што беа дозволите за домаќинот во VM и почнав да ги применувам поставките едно по едно, едно по друго, со скршеното VM, додека не го најдов виновникот:

net.core.rmem_default = 2147483647

Еве го тоа, конфигурација за кршење на DNS! Го најдов оружјето за убиство. Но, зошто се случува ова? Сè уште ми требаше мотив.

Основната големина на баферот на пакетите DNS е конфигурирана преку net.core.rmem_default. Типична вредност е некаде околу 200 KiB, но ако вашиот сервер прима многу DNS пакети, можеби ќе сакате да ја зголемите големината на баферот. Ако баферот е полн кога ќе пристигне нов пакет, на пример затоа што апликацијата не го обработува доволно брзо, тогаш ќе почнете да губите пакети. Нашиот клиент правилно ја зголеми големината на баферот бидејќи се плашеше од загуба на податоци, бидејќи користеше апликација за собирање метрика преку DNS пакети. Вредноста што ја постави беше максималната можна: 231-1 (ако е поставена на 231, кернелот ќе врати „НЕВАЛИДЕН АРГУМЕНТ“).

Одеднаш сфатив зошто nmap и scapy функционираат правилно: тие користеа сирови приклучоци! Необработените приклучоци се разликуваат од обичните приклучоци: тие ги заобиколуваат iptables и не се баферирани!

Но, зошто „преголем тампон“ предизвикува проблеми? Очигледно не функционира како што е замислено.

Во овој момент би можел да го репродуцирам проблемот на повеќе кернели и повеќе дистрибуции. Проблемот веќе се појави на кернелот 3.x, а сега се појави и на кернелот 5.x.

Навистина, при стартување

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

DNS престана да работи.

Почнав да барам работни вредности преку едноставен бинарен алгоритам за пребарување и открив дека системот работи со 2147481343, но овој број за мене беше бесмислен збир на броеви. Му предложив на клиентот да го проба овој број, а тој ми одговори дека системот работи со google.com, но сепак даде грешка со други домени, па продолжив со мојата истрага.

Имам инсталирано dropwatch, алатка која требаше да се користи порано: покажува точно каде во кернелот завршува пакетот. Виновникот беше функцијата udp_queue_rcv_skb. Ги преземав изворите на кернелот и додадов неколку функции printk да следи каде точно завршува пакетот. Брзо ја најдов вистинската состојба if, и едноставно зјапав во него некое време, бидејќи токму тогаш сè конечно се собра во цела слика: 231-1, бесмислен број, неработен домен... Тоа беше парче код во __udp_enqueue_schedule_skb:

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

Ве молиме запомнете:

• rmem е од типот инт
• size е од типот u16 (непотпишан шеснаесет-битен int) и ја складира големината на пакетот
• sk->sk_rcybuf е од типот int и ја складира големината на баферот која, по дефиниција, е еднаква на вредноста во net.core.rmem_default

Кога sk_rcvbuf се приближува до 231, собирањето на големината на пакетот може да резултира со прелевање на цел број. И бидејќи тоа е int, неговата вредност станува негативна, па условот станува вистинит кога треба да биде неточен (повеќе за ова можете да прочитате на линк).

Грешката може да се коригира на тривијален начин: со кастинг unsigned int. Ја применив поправката и го рестартирав системот и DNS повторно работеше.

Вкусот на победата

Ги проследив моите наоди до клиентот и испратив LKML лепенка на јадрото. Задоволен сум: секое парче од сложувалката се вклопува, можам точно да објаснам зошто го набљудувавме она што го набљудувавме и што е најважно, успеавме да најдеме решение за проблемот благодарение на нашата тимска работа!

Вреди да се признае дека случајот се покажа како редок, и за среќа ретко добиваме такви сложени барања од корисниците.

Извор: www.habr.com