סיפור על מנות DNS חסרות מהתמיכה הטכנית של Google Cloud

מעורך הבלוגים של גוגל: האם תהיתם פעם כיצד מהנדסי Google Cloud Technical Solutions (TSE) מטפלים בבקשות התמיכה שלכם? מהנדסי התמיכה הטכנית של TSE אחראים על זיהוי ותיקון מקורות בעיות שדווחו על ידי משתמשים. חלק מהבעיות הללו די פשוטות, אבל לפעמים נתקלים בכרטיס שדורש תשומת לב של כמה מהנדסים בו זמנית. במאמר זה, אחד מעובדי TSE יספר לנו על בעיה אחת מאוד מסובכת מהתרגול האחרון שלו - במקרה של מנות DNS חסרות. בסיפור זה נראה כיצד המהנדסים הצליחו לפתור את המצב, ואילו דברים חדשים הם למדו תוך כדי תיקון השגיאה. אנו מקווים שהסיפור הזה לא רק מלמד אותך על באג עמוק, אלא גם נותן לך תובנות לגבי התהליכים הנלווים להגשת כרטיס תמיכה ל-Google Cloud.

פתרון בעיות הוא גם מדע וגם אמנות. הכל מתחיל בבניית השערה לגבי הסיבה להתנהגות הלא סטנדרטית של המערכת, ולאחר מכן היא נבדקת על חוזקה. עם זאת, לפני שאנו מנסחים השערה, עלינו להגדיר בבירור ולנסח במדויק את הבעיה. אם השאלה נשמעת מעורפלת מדי, אז תצטרך לנתח הכל בזהירות; זוהי "האמנות" של פתרון בעיות.

תחת Google Cloud, תהליכים כאלה הופכים מורכבים יותר באופן אקספוננציאלי, מכיוון ש-Google Cloud מנסה כמיטב יכולתו להבטיח את פרטיות המשתמשים שלו. בגלל זה, למהנדסי TSE אין גישה לערוך את המערכות שלך, וגם לא את היכולת להציג תצורות בצורה רחבה כמו למשתמשים. לכן, כדי לבדוק כל אחת מההשערות שלנו, אנחנו (מהנדסים) לא יכולים לשנות במהירות את המערכת.

חלק מהמשתמשים מאמינים שנתקן הכל כמו מכונאות בשירות רכב, ופשוט נשלח לנו את תעודת הזהות של מכונה וירטואלית, בעוד שבמציאות התהליך מתרחש בפורמט של שיחה: איסוף מידע, גיבוש ואישור (או הפרכת) השערות, ובסופו של דבר, בעיות החלטה מבוססות על תקשורת עם הלקוח.

הבעיה המדוברת

היום יש לנו סיפור עם סוף טוב. אחת הסיבות לפתרון המוצלח של המקרה המוצע היא תיאור מפורט ומדויק מאוד של הבעיה. להלן ניתן לראות עותק של הכרטיס הראשון (ערוך כדי להסתיר מידע סודי):

הודעה זו מכילה מידע רב שימושי עבורנו:

• צוין VM ספציפי
• הבעיה עצמה מסומנת - DNS לא עובד
• מצוין היכן הבעיה באה לידי ביטוי - VM ומיכל
• מצוינים הצעדים שהמשתמש נקט כדי לזהות את הבעיה.

הבקשה נרשמה כ-"P1: השפעה קריטית - שירות לא שמיש בייצור", כלומר ניטור מתמיד של המצב 24/7 על פי תכנית "Follow the Sun" (תוכלו לקרוא עוד על סדרי עדיפויות של בקשות משתמשים), עם העברתו מצוות תמיכה טכנית אחד לאחר עם כל שינוי של אזור זמן. למעשה, כשהבעיה הגיעה לצוות שלנו בציריך, היא כבר הקיפה את העולם. בשלב זה, המשתמש נקט באמצעי הפחתה, אך חשש מחזרה של המצב בייצור, שכן הסיבה השורשית טרם התגלתה.

כשהכרטיס הגיע לציריך, כבר היה בידינו המידע הבא:

• תוֹכֶן /etc/hosts
• תוֹכֶן /etc/resolv.conf
• פלט iptables-save
• מורכב על ידי הצוות ngrep קובץ pcap

עם הנתונים האלה, היינו מוכנים להתחיל את שלב ה"חקירה" ופתרון הבעיות.

הצעדים הראשונים שלנו

קודם כל, בדקנו את היומנים והסטטוס של שרת המטא נתונים ווידאנו שהוא פועל כהלכה. שרת המטא נתונים מגיב לכתובת ה-IP 169.254.169.254 ובין היתר אחראי על השליטה בשמות הדומיין. כמו כן בדקנו פעמיים שחומת האש פועלת כהלכה עם ה-VM ואינה חוסמת מנות.

זו הייתה איזושהי בעיה מוזרה: בדיקת nmap הפריכה את ההשערה העיקרית שלנו לגבי אובדן מנות UDP, אז הגענו נפשית לעוד כמה אפשרויות ודרכים לבדוק אותן:

• האם מנות נושרות באופן סלקטיבי? => בדוק את כללי iptables
• זה לא קטן מדי? MTU? => בדוק פלט 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. ה-Hypervisor תופס ומשדר את החבילה לשרת המטא נתונים בעת מגע איתו
7. שרת המטא נתונים, בקסמו, קובע את שם ה-DNS ומחזיר תגובה באותה שיטה

הרשו לי להזכיר לכם אילו השערות כבר שקלנו:

השערה: ספריות שבורות

• מבחן 1: הפעל את ה-strace במערכת, בדוק שחפירה קוראת את קריאות המערכת הנכונות
• תוצאה: קריאות מערכת נכונות נקראות
• מבחן 2: שימוש ב-srapy כדי לבדוק אם אנחנו יכולים לקבוע שמות עוקפים ספריות מערכת
• תוצאה: אנחנו יכולים
• מבחן 3: הפעל rpm –V על חבילת libdns וקבצי ספריית md5sum
• תוצאה: קוד הספרייה זהה לחלוטין לקוד במערכת ההפעלה העובדת
• מבחן 4: הרכב את תמונת מערכת השורש של המשתמש ב-VM ללא התנהגות זו, הפעל chroot, ראה אם ​​DNS עובד
• תוצאה: DNS פועל כהלכה

מסקנה על סמך בדיקות: הבעיה לא בספריות

השערה: יש שגיאה בהגדרות ה-DNS

• מבחן 1: בדוק את tcpdump וראה אם ​​מנות DNS נשלחות ומוחזרות כהלכה לאחר הפעלת החפירה
• תוצאה: מנות מועברות כהלכה
• מבחן 2: בדוק שוב בשרת /etc/nsswitch.conf и /etc/resolv.conf
• תוצאה: הכל נכון

מסקנה על סמך בדיקות: הבעיה היא לא בתצורת ה-DNS

השערה: הליבה פגומה

• בדיקה: התקן קרנל חדש, בדוק חתימה, הפעל מחדש
• תוצאה: התנהגות דומה

מסקנה על סמך בדיקות: הקרנל אינו פגום

השערה: התנהגות שגויה של רשת המשתמש (או ממשק רשת ה-Hypervisor)

• מבחן 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, הקרנל יחזיר "INVALID ARGUMENT").

פתאום הבנתי למה 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 הוא מסוג int
• size הוא מסוג u16 (לא חתום שישה-עשר סיביות int) ומאחסן את גודל החבילה
• sk->sk_rcybuf הוא מסוג int ומאחסן את גודל המאגר אשר, בהגדרה, שווה לערך in net.core.rmem_default

כאשר sk_rcvbuf מתקרב ל-231, סיכום גודל החבילה עשוי לגרום גלישה נומרית. ומכיוון שמדובר ב-int, הערך שלו הופך לשלילי, אז התנאי הופך להיות אמיתי כאשר הוא צריך להיות שקר (תוכל לקרוא עוד על כך ב- קשר).

ניתן לתקן את השגיאה בצורה טריוויאלית: על ידי ליהוק unsigned int. החלתי את התיקון והפעלתי מחדש את המערכת וה-DNS עבד שוב.

טעם של ניצחון

העברתי את הממצאים שלי ללקוח ושלחתי LKML תיקון ליבה. אני מרוצה: כל חלק בפאזל משתלב, אני יכול להסביר בדיוק למה צפינו במה שצפינו, והכי חשוב, הצלחנו למצוא פתרון לבעיה בזכות עבודת הצוות שלנו!

ראוי להכיר כי המקרה התברר כנדיר, ולמרבה המזל אנו מקבלים רק לעתים רחוקות בקשות מורכבות כל כך ממשתמשים.

מקור: www.habr.com