История за липсващи DNS пакети от техническата поддръжка на Google Cloud

От Google Blog Editor: Чудили ли сте се някога как инженерите на Google Cloud Technical Solutions (TSE) обработват заявките ви за поддръжка? Инженерите за техническа поддръжка на TSE са отговорни за идентифицирането и коригирането на докладваните от потребителите източници на проблеми. Някои от тези проблеми са доста прости, но понякога попадате на билет, който изисква вниманието на няколко инженера едновременно. В тази статия един от служителите на TSE ще ни разкаже за един много труден проблем от скорошната си практика - случай на липсващи DNS пакети. В тази история ще видим как инженерите са успели да разрешат ситуацията и какви нови неща са научили, докато са коригирали грешката. Надяваме се, че тази история не само ви информира за дълбоко вкоренена грешка, но също така ви дава представа за процесите, които влизат в подаването на билет за поддръжка в Google Cloud.

Отстраняването на неизправности е едновременно наука и изкуство. Всичко започва с изграждането на хипотеза за причината за нестандартното поведение на системата, след което тя се тества за здравина. Преди обаче да формулираме хипотеза, трябва ясно да дефинираме и прецизно формулираме проблема. Ако въпросът звучи твърде неясен, тогава ще трябва внимателно да анализирате всичко; Това е „изкуството“ за отстраняване на проблеми.

Под Google Cloud подобни процеси стават експоненциално по-сложни, тъй като Google Cloud се опитва да гарантира поверителността на своите потребители. Поради това инженерите на TSE нямат достъп да редактират вашите системи, нито възможността да преглеждат конфигурациите толкова широко, колкото потребителите. Следователно, за да тестваме някоя от нашите хипотези, ние (инженерите) не можем бързо да модифицираме системата.

Някои потребители смятат, че ще поправим всичко като механика в автосервиз и просто ни изпращат идентификатора на виртуална машина, докато в действителност процесът протича в разговорен формат: събиране на информация, формиране и потвърждаване (или опровергаване) на хипотези, и в крайна сметка проблемите с решението се основават на комуникацията с клиента.

Въпросният проблем

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

Това съобщение съдържа много полезна информация за нас:

• Посочена конкретна VM
• Самият проблем е посочен - DNS не работи
• Посочено е къде се проявява проблема - VM и контейнер
• Посочени са стъпките, предприети от потребителя, за да идентифицира проблема.

Заявката е регистрирана като „P1: Critical Impact - Service Unusable in production“, което означава постоянно наблюдение на ситуацията 24/7 по схемата „Follow the Sun“ (можете да прочетете повече за приоритети на потребителските заявки), с прехвърлянето му от един екип за техническа поддръжка към друг при всяка смяна на часовата зона. Всъщност, докато проблемът достигне до нашия екип в Цюрих, той вече е обиколил земното кълбо. До този момент потребителят е взел смекчаващи мерки, но се страхува от повторение на ситуацията в производството, тъй като основната причина все още не е открита.

Докато билетът стигне до Цюрих, вече разполагахме със следната информация:

• съдържание /etc/hosts
• съдържание /etc/resolv.conf
• Продукция iptables-save
• Сглобява се от екипа ngrep pcap файл

С тези данни бяхме готови да започнем фазата на „разследване“ и отстраняване на неизправности.

Първите ни стъпки

Първо, проверихме регистрационните файлове и състоянието на сървъра за метаданни и се уверихме, че работи правилно. Сървърът за метаданни отговаря на IP адрес 169.254.169.254 и, наред с други неща, отговаря за контролирането на имената на домейни. Също така проверихме отново дали защитната стена работи правилно с виртуалната машина и не блокира пакети.

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

• Пакетите пускат ли се избирателно? => Проверете правилата на iptables
• Не е ли твърде малък? MTU? => Проверете изхода ip a show
• Проблемът само UDP пакети ли засяга или и TCP? => Карайте dig +tcp
• Връщат ли се генерираните от dig пакети? => Карайте tcpdump
• libdns работи ли правилно? => Карайте strace за проверка на предаването на пакети в двете посоки

Тук решаваме да се обадим на потребителя за отстраняване на проблеми на живо.

По време на разговора можем да проверим няколко неща:

• След няколко проверки изключваме правилата на iptables от списъка с причини
• Проверяваме мрежовите интерфейси и таблиците за маршрутизиране и проверяваме дали MTU е правилен
• Ние откриваме това dig +tcp google.com (TCP) работи както трябва, но dig google.com (UDP) не работи
• Като се отдалечи tcpdump все още работи dig, откриваме, че се връщат UDP пакети
• Ние караме strace dig google.com и виждаме как dig правилно извиква sendmsg() и recvms(), но вторият е прекъснат от таймаут

За съжаление наближава краят на смяната и сме принудени да ескалираме проблема до следващата часова зона. Заявката обаче предизвика интерес в нашия екип и колега предлага да създадем първоначалния DNS пакет с помощта на scrapy 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? Въпросът е страхотен, тъй като кандидатът трябва да опише всичко от обвивката до потребителското пространство, до системното ядро ​​и след това до мрежата. Усмихвам се: понякога въпросите за интервю се оказват полезни в реалния живот...

Решавам да приложа този HR въпрос към настоящ проблем. Грубо казано, когато се опитате да определите 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: стартирайте strace в системата, проверете дали dig извиква правилните системни извиквания
• Резултат: Извикват се правилни системни повиквания
• Тест 2: използване на srapy за проверка дали можем да определим имената, заобикаляйки системните библиотеки
• Резултат: можем
• Тест 3: стартирайте rpm –V на пакета libdns и библиотечните файлове md5sum
• Резултат: кодът на библиотеката е напълно идентичен с кода в работещата операционна система
• Тест 4: монтирайте изображението на root системата на потребителя на VM без това поведение, стартирайте chroot, вижте дали DNS работи
• Резултат: DNS работи правилно

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

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

• Тест 1: проверете tcpdump и вижте дали DNS пакетите се изпращат и връщат правилно след стартиране на dig
• Резултат: пакетите се предават правилно
• Тест 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. Типичната стойност е някъде около 200KiB, но ако вашият сървър получава много 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, но все още дава грешка с други домейни, така че продължих разследването си.

Инсталирах падащ часовник, инструмент, който трябваше да се използва по-рано: той показва точно къде в ядрото завършва даден пакет. Виновникът беше функцията udp_queue_rcv_skb. Изтеглих изходните кодове на ядрото и добавих няколко функция printk за да проследите къде точно свършва пакетът. Бързо намерих правилното състояние if, и просто го гледаше известно време, защото тогава всичко най-накрая се събра в една цялостна картина: 231-1, безсмислено число, неработещ домейн... Беше част от код в __udp_enqueue_schedule_skb:

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

Моля, обърнете внимание:

• rmem е от тип int
• size е от тип u16 (неподписано шестнадесет-битово int) и съхранява размера на пакета
• sk->sk_rcybuf е от тип int и съхранява размера на буфера, който по дефиниция е равен на стойността в net.core.rmem_default

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

Грешката може да бъде коригирана по тривиален начин: чрез кастинг unsigned int. Приложих корекцията и рестартирах системата и DNS отново заработи.

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

Препратих констатациите си на клиента и изпратих LKML корекция на ядрото. Доволен съм: всяко парче от пъзела пасва, мога да обясня точно защо наблюдавахме това, което наблюдавахме, и най-важното, успяхме да намерим решение на проблема благодарение на нашата екипна работа!

Струва си да се признае, че случаят се оказа рядък и за щастие рядко получаваме толкова сложни заявки от потребители.

Източник: www.habr.com