פתרון בעיות ב-Cloud DNS

בדף הזה מפורטים פתרונות לבעיות נפוצות שעלולות לקרות כשמשתמשים ב-Cloud DNS כדי ליצור תחומים ציבוריים, תחומים פרטיים,תחומים לחיפוש הפוך (reverse lookup zone), תחומי העברה ורשומות משאבים.

אזורים ציבוריים

בקטע הזה מוסבר על בעיות באזורים ציבוריים.

אי אפשר ליצור אזור ציבורי

אם מופיעה השגיאה attempted action failed, סימן ש-Cloud DNS API לא מופעל בפרויקט.

כדי להפעיל את Cloud DNS API:

  1. נכנסים לדף API Library במסוף Google Cloud .

    לדף API Library

  2. בקטע Select a recent project, בוחרים את הפרויקט ב- Google Cloud שבו רוצים להפעיל את ה-API.

  3. בדף API library, משתמשים בתיבה Search for APIs & Services כדי לחפש את Cloud DNS API. יופיע דף שמתאר את ה-API.

  4. לוחצים על הפעלה.

אזורים פרטיים

בקטע הזה מוסבר על בעיות באזורים פרטיים.

בעיות באזורים פרטיים בפרויקטים של שירות VPC משותף

מידע חשוב על השימוש באזורים פרטיים עם רשתות VPC משותפות מופיע במאמר אזורים פרטיים ו-VPC משותף.

אי אפשר ליצור אזור פרטי, ואי אפשר להציג או ליצור כללי מדיניות

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

אזורים פרטיים לא פותרים באותה רשת VPC

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

מוודאים שהממשק הראשי של המכונה הווירטואלית נמצא באותה רשת כמו האזור הפרטי שיצרתם.

מכונה וירטואלית (VM) שולחת את כל תעבורת הנתונים מהממשק הראשי שלה, אלא אם תעבורת הנתונים מיועדת לרשת משנה שמחוברת לאחד מהממשקים האחרים, או אם במכונה הווירטואלית מוגדרת מדיניות ניתוב. מוודאים שהממשק הראשי של ה-VM לבדיקה נמצא באותה רשת כמו האזור הפרטי שבודקים.

מוודאים שהמכונה הווירטואלית משתמשת באחת מהאפשרויות הבאות:

gcloud compute instances describe VM_NAME \
    --zone=GCE_ZONE \
    --format="csv[no-heading](networkInterfaces['network'])"

מוודאים שהרשת נמצאת ברשימת הרשתות שמורשות לשלוח שאילתות לאזור הפרטי:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv(privateVisibilityConfig['networks'])"

מוודאים ששם ה-DNS בשאילתה תואם לאזור שלכם

‫Google Cloud פותר רשומה לפי סדר פתרון השמות, ומשתמש באזור עם הסיומת הארוכה ביותר כדי להחליט לאיזה אזור לשלוח שאילתה לגבי שם DNS נתון. חשוב לוודא שהסיומת של הרשומה שאתם שולחים אליה שאילתה תואמת לפחות לאזור פרטי אחד שאפשר לגשת אליו ברשת ה-VPC. לדוגמה, Google Cloudמחפש קודם את myapp.dev.gcp.example.lan באזור שמשרת את dev.gcp.example.lan, אם הוא נגיש, לפני שהוא מחפש אותו באזור שמשרת את gcp.example.lan, אם הוא נגיש.

הפלט של הפקודה הבאה מציג את סיומת ה-DNS לאזור פרטי נתון:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv[no-heading](dnsName)"

שליחת שאילתה לשם ה-DNS באמצעות שרת המטא-נתונים

משתמשים ב-dig כדי לשלוח את שאילתת שם ה-DNS ישירות לשרת המטא-נתונים של Google Cloud, 169.254.169.254:

dig DNS_NAME @169.254.169.254

משתמשים ב-dig כדי לשלוח שאילתה לשרת השמות שמוגדר כברירת מחדל במכונה הווירטואלית:

dig DNS_NAME

אם הפלט של שתי פקודות ה-dig מפיק תשובות שונות, בודקים את הקטע ;; SERVER: של הפקודה השנייה. השרת שמגיב חייב להיות שרת המטא-נתונים, 169.254.169.254. אם לא, סימן שהגדרתם את מערכת ההפעלה של האורח להשתמש בשרת שמות DNS בהתאמה אישית במקום בשרת המטא-נתוניםGoogle Cloud שמוגדר כברירת מחדל. באזורים פרטיים של Cloud DNS, צריך להשתמש בשרת המטא-נתונים לתרגום שם (name resolution). סביבת האורח של Linux וסביבת האורח של Windows עושות את זה בשבילכם. אם ייבאתם את קובץ האימג' שבו אתם משתמשים למכונה וירטואלית, ודאו שסביבת האורח המתאימה הותקנה.

אזורים פרטיים לא נפתרים דרך Cloud VPN או Cloud Interconnect

קודם כל, ודאו שאתם יכולים לשלוח שאילתה לשם ה-DNS ולקבל תשובה מתוך רשת VPC מורשית.

אימות הקישוריות דרך Cloud VPN או Cloud Interconnect

מוודאים שהקישוריות ממערכת מקומית לרשת ה-VPC פועלת. באופן ספציפי, תעבורת הנתונים של TCP ו-UDP ביציאה 53 צריכה להיות מסוגלת לצאת מהרשת המקומית ולהישלח לרשת ה-VPC. מוודאים שהגדרת חומות האש המקומיות מאפשרת תעבורת נתונים יוצאת כזו.

אתם יכולים להשתמש בכל פרוטוקול, כמו ping (ICMP), כדי לבדוק את הקישוריות למכונה וירטואלית לדוגמה ברשת ה-VPC מהרשת המקומית. למרות שבקשות Cloud DNS לא נשלחות למכונות וירטואליות של Google Cloud , בדיקת הקישוריות למכונה וירטואלית לדוגמה מאפשרת לאמת את הקישוריות דרך מנהרת Cloud VPN או חיבור Cloud Interconnect. חשוב לוודא שהגדרתם כלל חומת אש מתאים שמאפשר תעבורת נתונים נכנסת (ingress) למכונה הווירטואלית לדוגמה ב-Google Cloud , כי אחרת כלל ברירת המחדל שמונע תעבורת נתונים נכנסת חוסם את כל תעבורת הנתונים הנכנסת.

מוודאים שהעברה נכנסת מופעלת ברשת ה-VPC המורשית

צריך להפעיל העברה של תעבורת נתונים נכנסת לכל רשת VPC שמורשית לשלוח שאילתות לאזור הפרטי שלכם ב-Cloud DNS. כדי להציג את כל כללי המדיניות, משתמשים בפקודה הבאה:

gcloud dns policies list

מזהים את הרשת בטבלת הפלט ובודקים אם ההעברה מופעלת בשדה Forwarding.

מוודאים שהרשת המורשית היא רשת VPC

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

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

רשתות מדור קודם מזוהות בפלט בתור LEGACY.

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

הפקודה הבאה מציגה את כל כתובות ה-IP השמורות להעברת DNS בפרויקט.

gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER" \
    --format='csv[no-heading](address, subnetwork)'

אפשר להוסיף למסנן סעיף AND כדי להגביל את הפלט רק לרשת המשנה הרלוונטית.

דוגמה:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"

אם לא מופיעה כתובת IP ברשת או באזור שציפיתם, שלחו כרטיס תמיכה לתמיכה שלGoogle Cloud .

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

dig DNS_NAME @10.150.0.1 # address returned by previous command

חוזרים על אותה פקודת dig, אבל ממארח מקומי דרך ה-VPN.

רשומת CNAME שמוגדרת באזור פרטי לא פועלת

‫Cloud DNS עוקב אחרי רשומות CNAME רק כפי שמתואר בקטע מעקב אחרי CNAME.

תחומי DNS לחיפוש הפוך (reverse lookup zone)

בקטע הזה מופיעים טיפים לפתרון בעיות בתחומי DNS לחיפוש הפוך. חלק מהבעיות באזורים פרטיים רלוונטיות גם לתחומי DNS לחיפוש הפוך. טיפים נוספים מופיעים בקטע פתרון בעיות באזורים פרטיים.

לא מתבצעת פתירה של כתובת VM שאינה RFC 1918

אם יש לכם כתובת שהיא לא RFC 1918, צריך להתאים את המכונה הווירטואלית.

התאמה של המכונה הווירטואלית לכתובת שהיא לא RFC 1918

אם יצרתם VM במהלך גרסת האלפא של non-RFC 1918 לפני שהושקה התמיכה ב-Cloud DNS, יכול להיות שהמכונות הווירטואליות האלה לא יפתרו בצורה נכונה. כדי לפתור את הבעיה, צריך להפעיל מחדש את המכונות הווירטואליות.

אזורי העברה

בקטע הזה מפורטים טיפים לפתרון בעיות באזורי העברה. חלק מהבעיות באזורים פרטיים רלוונטיות גם לאזורי העברה. טיפים נוספים מופיעים בקטע פתרון בעיות באזורים פרטיים.

אזורי העברה (העברה יוצאת) לא פועלים

קודם כל, ודאו שאתם יכולים לשלוח שאילתה לשם ה-DNS ולקבל תשובה מתוך רשת VPC מורשית.

העברת שאילתות ממכונות וירטואליות ברשת VPC של צרכן לרשת VPC של יצרן לא עובדת

אם אתם משתמשים בקישור בין רשתות שכנות (peering) ב-DNS ורוצים להעביר שאילתות ממכונות וירטואליות ברשת VPC של צרכן לרשת VPC של ספק, ואז לשרת שמות מקומי אחד או יותר, ודאו שאחד מהתנאים המוקדמים הבאים מתקיים:

  • מצב הניתוב הדינמי של רשת ה-VPC המנוהלת מוגדר ל-GLOBAL.

  • המכונה הווירטואלית ברשת ה-VPC של הצרכן נמצאת באותו אזור כמו מנהרת ה-VPN או Cloud Interconnect ב-VPC של היצרן.

  • (רק נתיבים סטטיים או הצעדים הבאים בהתאמה אישית) ברשת ה-VPC של ספק השירות מוגדר נתיב סטטי לשליחת תעבורת נתונים שמיועדת לשרתי השמות המקומיים דרך מנהרת ה-VPN הקלאסי, VPN בניהול עצמי או שער שאינו BGP. ברשת ה-VPC של הספק צריכה להיות גם מכונה וירטואלית או מנהרת VPN באותו אזור שבו נמצאת רשת המשנה שמשמשת את המכונות הווירטואליות של הלקוח.

    • לדוגמה, נניח ש-VPC1 משתמש בתחום קישור בין רשתות שכנות ששולח שאילתות של example.com. ל-VPC2. נניח גם של-VPC2 יש אזור העברה פרטי של example.com. שמעביר את השאילתות לשרת שמות מקומי באמצעות מנהרת VPN קלאסית.

      כדי שמכונה וירטואלית שנמצאת ב-us-east1 ב-VPC1 תוכל לשלוח שאילתות ל-example.com., ל-VPC2 צריכה להיות מכונה וירטואלית שנמצאת ב-us-east1. צריך גם להגדיר מסלול סטטי שמכסה את טווחי ה-CIDR של שרתי השמות המקומיים, כשהקפיצה הבאה מוגדרת כמנהרת ה-VPN הקלאסי.

      אימות הקישוריות דרך Cloud VPN או Cloud Interconnect

אתם יכולים להשתמש בכל פרוטוקול, כמו ping (ICMP), כדי לבדוק את הקישוריות למכונה וירטואלית לדוגמה ברשת ה-VPC מהרשת המקומית. צריך גם לנסות לשלוח שאילתה לשרת השמות המקומי ישירות ממכונה וירטואלית לדוגמה שלGoogle Cloud , באמצעות כלי כמו dig:

dig DNS_NAME @192.168.x.x # address of the onprem DNS server

בדיקת הכללים של חומת האש ברשת ה-VPC

כלל חומת האש המשתמע שמאפשר תעבורת נתונים יוצאת מאפשר חיבורים יוצאים ותגובות שנוצרו ממכונות וירטואליות ברשת ה-VPC, אלא אם יצרתם כללים בהתאמה אישית שדוחים תעבורת נתונים יוצאת. אם יצרתם כללי דחייה בהתאמה אישית לתעבורת נתונים יוצאת, תצטרכו ליצור כללי הרשאה בעדיפות גבוהה יותר שמאפשרים תעבורת נתונים יוצאת לפחות לשרתי השמות המקומיים.

בדיקת חומת האש המקומית

חשוב לוודא שחומת האש המקומית מוגדרת כך שתאפשר תנועה נכנסת מ-35.199.192.0/19 ותנועה יוצאת אליו.

בודקים את היומנים בחומת האש המקומית ומחפשים בקשות DNS מ-35.199.192.0/19. כדי להשתמש בביטוי regex לחיפוש, משתמשים בביטוי הבא:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

בדיקת שרת השמות המקומי

מוודאים שלא מוגדרת רשימת ACL בשרת השמות המקומי, שעלולה לחסום שאילתות מ-35.199.192.0/19.

בודקים את שרת השמות המקומי כדי לראות אם הוא מקבל חבילות מ-35.199.192.0/19. אם יש לכם גישה למעטפת, אתם יכולים להשתמש בכלי כמו tcpdump כדי לחפש גם חבילות נכנסות מ- וגם חבילות יוצאות אל 35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

אימות נתיבי החזרה

ברשת המקומית צריך להיות נתיב ליעד 35.199.192.0/19, כשהדילוג הבא הוא מנהרת VPN או חיבור Interconnect לאותה רשת VPC ששלחה את בקשת ה-DNS. ההתנהגות הזו מתוארת במאמר יצירת אזורי העברה.

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

אם חיברתם יותר מרשת VPC אחת לרשת המקומית, אתם צריכים לוודא שתשובות ה-DNS לא נשלחות לרשת הלא נכונה. Google Cloud מתעלם מתשובות DNS שנשלחות לרשת ה-VPC הלא נכונה. לפתרון מומלץ, עיינו במדריך השיטות המומלצות.

העברה יוצאת לשרת שמות שמשתמש בכתובת IP שאינה RFC 1918 נכשלת

כברירת מחדל, ב-Cloud DNS נעשה שימוש בניתוב רגיל, שבו שאילתות מנותבות דרך האינטרנט הציבורי כשכתובת ה-IP של שרת השמות המוגדר כיעד היא לא RFC 1918. ניתוב רגיל לא תומך בהעברת שאילתות לשרתי שמות עם כתובות שאינן RFC 1918, שלא ניתן להגיע אליהן מהאינטרנט הציבורי.

כדי להעביר שאילתות לשרת שמות שמשתמש בכתובת IP שאינה RFC 1918 דרך רשת ה-VPC, צריך להגדיר את מדיניות השרת או את אזור ההעברה של Cloud DNS כך שישתמשו בניתוב פרטי לשרת השמות המטורגט.

הסבר על ההבדלים בין ניתוב רגיל לניתוב פרטי מופיע במאמר יעדי העברה ושיטות ניתוב.

המגבלה הזו חלה גם אם יש נתיב VPC לשרת השמות של היעד. לנתיבים של כתובות שאינן RFC 1918 אין השפעה על התנהגות ההעברה החוצה של Cloud DNS כשמוגדר ניתוב רגיל.

העברה יוצאת לכרטיס רשת משני נכשלת

מוודאים שהגדרתם נכון את בקר ממשק הרשת (NIC) המשני.

במאמר יצירת מכונות וירטואליות עם כמה ממשקי רשת מוסבר איך להגדיר כרטיסי רשת נוספים.

שאילתות שמועברות החוצה מקבלות שגיאות SERVFAIL

אם Cloud DNS מקבל שגיאה מכל שרתי השמות המטורגטים, או לא מקבל תשובה מאף אחד מהם, הוא מחזיר את השגיאה SERVFAIL.

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

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

רשומות משאבים

בקטע הזה מפורטים טיפים לפתרון בעיות ברשומות משאבים.

נתונים לא צפויים בשאילתה על קבוצות של רשומות משאבים שקיימות באזור

יכולות להיות כמה סיבות לכך שקיבלתם נתונים לא צפויים כששלחתם שאילתה לגבי קבוצות של רשומות משאבים שקיימות באזור מנוהל של Cloud DNS:

  1. אין תמיכה בקבוצות של רשומות משאבים שנוצרו באמצעות התחביר @ שצוין ב-RFC 1035. מערכת Cloud DNS מפרשת את הסמל @ בקבוצות של רשומות משאבים כאלה באופן מילולי. לכן, באזור example.com., קבוצת רשומות שנוצרה עבור ה-QNAME‏ @ מפורשת כ-@.example.com. במקום כ-example.com.. כדי לפתור את הבעיה, צריך ליצור קבוצות רשומות בלי הסמל @. כל השמות הם ביחס ל-apex של האזור.

  2. כמו כל הרשומות, רשומות CNAME עם תו כללי לחיפוש כפופות לכללי הקיום שמתוארים ב-RFC 4592. לדוגמה, נניח שאתם מגדירים את קבוצות הרשומות הבאות באזור example.com.:

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    שאילתה לגבי public.srv1.images.example.com. מחזירה את NOERROR עם קטע תשובה ריק. הקיום של רשומה בין ה-CNAME ל-QNAME מונע את החזרת ה-CNAME, אבל אין רשומה שתואמת בדיוק ל-QNAME, ולכן Cloud DNS מחזיר תשובה ריקה. זו התנהגות רגילה של DNS.

Google Cloud במכונה הווירטואלית מוצגות רשומות מצביע (PTR) שגויות

כשמכונה וירטואלית מועברת במהלך אירוע תחזוקה, הלוגיקה של רשומת ה-PTR לא מטפלת נכון במקרי קצה מסוימים ומחזירה את רשומות ה-DNS PTR לשם הדומיין שמוגדר במלואו (FQDN) של googleusercontent.com. כדי לשחזר את הפונקציונליות, צריך להחיל שוב את רשומת ה-PTR.

לפרטים על החלת רשומות PTR על מכונה וירטואלית, ראו יצירת רשומת PTR למכונה וירטואלית.

קבוצות של רשומות משאבים ב-Cloud DNS שמוחזרות בסדר אקראי

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

סוג המשאב של התחום המוגדר לא נתמך

כשמזינים את הדגל --location בפקודה או בבקשת API של gcloud למאפיין שמטרגט תחום DNS אחר של Cloud DNS, הבקשה נדחית. לדוגמה, אם שולחים הגשת בקשה להוספת תכונה שרלוונטית רק לתחום מוגדר לשרת גלובלי, או הגשת בקשה להוספת תכונה שרלוונטית רק לשרת גלובלי לשרת של תחום מוגדר, השרת דוחה את הבקשה ומחזיר את השגיאה _UNSUPPORTED_ZONAL_RESOURCETYPE.

רשימה של משאבים ותכונות שנתמכים ב-Cloud DNS ברמת האזור מופיעה במאמר תמיכה ב-Cloud DNS ברמת האזור.

זיהוי איומים מתקדם

בקטע הזה מפורטות בעיות שאתם עלולים להיתקל בהן כשאתם משתמשים ב-DNS Armor, והצעות לפתרון של כל אחת מהן.

המדדים מראים שלא נשלחות שאילתות DNS לגלאי האיומים, או שנשלחות מעט מאוד שאילתות כאלה

קודם כול, מוודאים שיש לכם גלאי איומים ב-DNS.

אימות של גלאי האיומים ב-DNS

  1. נכנסים לדף Advanced threat detection במסוף Google Cloud .

    מעבר לזיהוי איומים מתקדם

  2. מוודאים שמופיע גלאי איומים.

בדיקה אם האזור נתמך

  1. מוודאים שהשדה Locations מכיל את האזור שמטפל בשאילתות ה-DNS של תהליך העבודה.

מוודאים שיש שאילתות שקשורות לאינטרנט

יומני השאילתות נשלחים רק כשמתבצעות שאילתות או בקשות מהרשת שלכם לאינטרנט.

  1. נכנסים לדף Monitoring במסוף Google Cloud .

    למעבר אל Monitoring

  2. בקטע Metric, בוחרים באפשרות Cloud DNS Query ואז בוחרים באפשרויות Query ו-DNS response counts.

  3. צפייה במדדים של סוגי יעדים שמחוברים לאינטרנט.

לחלופין, אם הפעלתם את Cloud Logging לשאילתות DNS, אתם יכולים להשתמש ב-Logs Explorer כדי לוודא שיש לכם שאילתות שמיועדות לאינטרנט.

  1. נכנסים לדף Logs Explorer במסוף Google Cloud .

    כניסה לדף Logs Explorer

  2. צופים ביומני ה-DNS ובודקים אם יש שאילתות שקשורות לאינטרנט.

לא מוחזרים יומני אירועים של איומים

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

איך מוודאים שזיהוי האיומים מופעל

  1. במסוף Google Cloud , נכנסים לדף Advanced threat detection.

    מעבר לזיהוי איומים מתקדם

  2. מוודאים שמופיע גלאי איומים.

לא נוצרים אירועי איומים ב-DNS בחלק מהדומיינים הפוגעניים או הזדוניים

יכול להיות שחלק מאירועי האיומים ב-DNS שקשורים לדומיינים פוגעניים או זדוניים לא ייווצרו לדומיינים שהתקבלו מרשימות ציבוריות של דומיינים זדוניים באינטרנט, כי דומיינים של איומים ב-DNS משתנים לעיתים קרובות. דומיינים ישנים או שפג תוקפם מהרשימות האלה לא יוצרים אירועי איום ב-DNS.

אלה דומיינים לבדיקה שאפשר להשתמש בהם כדי לאמת דומיינים של איומי DNS:

  • dnst-gcp-blox.com
  • ftags-gcp-blox.com
  • dga-gcp-blox.com

מוודאים שנוצרים אירועי איום ב-DNS לדומיינים לבדיקה

  1. נכנסים למכונה וירטואלית ששייכת לפרויקט שעוקבים אחריו.

  2. פותחים טרמינל ומריצים פקודת dig לאחד מהדומיינים לבדיקה. 

    domain=TEST_DOMAIN 
    
dig $domain -t A

    מחליפים את TEST_DOMAIN באחד מהדומיינים שברשימה.

  3. פותחים את הדף Logs Explorer במסוף Google Cloud .

    כניסה לדף Logs Explorer

  4. מריצים את השאילתה הבאה: resource.type="networksecurity.googleapis.com/DnsThreatDetector"

  5. מחפשים את הדומיין לבדיקה שבו השתמשתם בפקודת ה-dig.

    הדומיינים האלה יוצרים אירועי איום ב-DNS. אם אתם לא מוצאים את יומני ה-DNS של הדומיינים שברשימה, פנו לתמיכה.

נקודות קצה יוצאות

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

שאילתות DNS לא מועברות לשרתי היעד

יש כמה סיבות אפשריות לבעיה הזו.

הגדרה שגויה של משאבים

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

חשוב לוודא שתת-הרשת האזורית של שרת proxy בלבד מוגדרת בצורה נכונה, ושיש בה מספיק כתובות IP זמינות לשאילתות של שרת proxy. אפשר גם להפעיל רישום של שאילתות ביומן ואז לבדוק את השדה jsonPayload.egressPath ביומני השאילתות. השדה הזה מוגדר כ-OUTBOUND_ENDPOINT אם השאילתה שהועברה משתמשת בנקודות קצה יוצאות. אם יומני השאילתות לא כוללים את השדה הזה, או אם השדה לא מוגדר ל-OUTBOUND_ENDPOINT, ברירת המחדל של התנועה היא 35.199.192.0/19.

כדי לבדוק את ההגדרות, מריצים את הפקודה gcloud beta dns outbound-endpoints describe:

gcloud beta dns outbound-endpoints describe ENDPOINT_NAME \
    --project=PROJECT_ID \
    --location=REGION

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ENDPOINT_NAME: שם נקודת הקצה
  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫REGION: האזור שבו נמצאת נקודת הקצה (endpoint)

קישוריות רשת

מוודאים שקיים נתיב מרשת ה-VPC לשרתי ה-DNS המקומיים או המרוחקים, ושכללי חומת האש המקומית מאפשרים תעבורת נתונים ביציאת TCP/UDP‏ 53 מטווח כתובות ה-IP של תת-הרשת של שרת ה-proxy בלבד. חשוב גם לוודא שקיים נתיב מהרשת המקומית בחזרה לטווח כתובות ה-IP של תת-הרשת של שרת ה-proxy בלבד.

בעיה ב-VPC משותף או בקישור בין רשתות שכנות (peering)

  • בעיה ב-VPC משותף: צריך ליצור נקודות קצה לתעבורת נתונים יוצאת בפרויקט המארח שבו נמצאים רשת ה-VPC המשותפת ותת-הרשתות. כשמשייכים אזור העברה או מדיניות של שרת DNS בפרויקט שירות לנקודת קצה יוצאת בפרויקט המארח, צריך לוודא שלמשתמש יש את ההרשאה dns.outboundEndpoints.bindPrivateDNSZone או dns.outboundEndpoints.bindPrivateDNSPolicy בפרויקט המארח.
  • בעיה בקישור בין רשתות שכנות (peering): מוודאים שסטטוס הקישור בין רשתות VPC שכנות מוגדר כ-Active.

צריך גם לוודא שהמסלולים וכללי חומת האש מאפשרים תעבורת DNS (יציאות UDP ו-TCP‏ 53) בין טווח הכתובות של תת-הרשת האזורית של שרת ה-proxy בלבד ברשת ה-VPC של נקודת הקצה לבין שרתי ה-DNS המטורגטים.

הזמן הקצוב לתפוגה של שאילתות DNS

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

בעיית זמן אחזור ברשת בין נקודת הקצה של התעבורה היוצאת לבין שרתי היעד

בודקים את זמן האחזור בין רשת ה-VPC לבין שרתי היעד של ה-DNS. יכול להיות שגם העברת שרתי ה-DNS של היעד קרוב יותר מבחינה גיאוגרפית לפרויקט ב-Google Cloud תעזור.

מיצוי של רשת משנה לשרתי proxy בלבד

בודקים ב-Monitoring את השימוש בכתובות IP של תת-הרשת לשרתי proxy בלבד באזור שבו השאילתות נכשלות. אם כמעט כל כתובות ה-IP ברשת המשנה כבר בשימוש, צריך לעבור לרשת משנה גדולה יותר שמשמשת רק לשרתי proxy, לפי השלבים שמפורטים בקטע שינוי רשת המשנה.

הגדרה שגויה של מדיניות המיקום הגיאוגרפי

מוודאים שמדיניות הניתוב לפי מיקום גיאוגרפי מכילה רשומה של האזור שבו נמצאת נקודת הקצה היוצאת. כדאי גם לבדוק אם יעד ה-FQDN באזור ההעברה תואם לשם ה-DNS של אזור המדיניות של המיקום הגיאוגרפי.

אי אפשר ליצור נקודת קצה יוצאת

בקטעים הבאים מוסבר למה יכול להיות שלא תצליחו ליצור נקודת קצה יוצאת.

ממשקי ה-API הנדרשים לא מופעלים

‫מוודאים שהממשקים Cloud DNS API (dns.googleapis.com),‏ Compute Engine API (compute.googleapis.com) ו-Network Services API (networkservices.googleapis.com) מופעלים בפרויקט.

בעיה בהרשאות IAM

מוודאים שלחשבון המשתמש או לחשבון השירות יש את התפקידים roles/dns.admin ו-roles/compute.networkAdmin (או הרשאות ל-dns.outboundEndpoints.create, ל-compute.networks.get, ל-compute.subnetworks.get ול-compute.subnetworks.use). ב-VPC משותף, צריך ליצור נקודות קצה לתעבורה יוצאת בפרויקט המארח (אי אפשר ליצור נקודת קצה לתעבורה יוצאת בפרויקט שירות).

מחרוזת כתובת ה-IP שצוינה בשדה endpointIp לא תואמת לטווח ה-CIDR של רשת המשנה הרגילה שצוינה, או שהיא בפורמט שגוי

בודקים את טווח ה-CIDR של רשת המשנה הרגילה שצוינה באזור היעד, ומוודאים שמחרוזת ה-IP שצוינה ב-endpointIp (--endpoint-ip) נמצאת בטווח ה-CIDR הראשי של רשת המשנה. חשוב גם לוודא שכתובת ה-IP היא לא כתובת IP שמורה ברשת המשנה (לדוגמה, שער או שידור).

מחרוזת כתובת ה-IP שצוינה תקינה, אבל משאב אחר כבר משתמש בה

בודקים במסוף Google Cloud את כתובות ה-IP של רשת ה-VPC, או משתמשים בפקודה gcloud compute addresses list ומציינים כתובת IPv4 אחרת שלא הוקצתה, מתוך רשת המשנה הרגילה עם --endpoint-ip.

המערכת לא מצאה רשת משנה פעילה של שרתי proxy אזוריים בלבד

חשוב לוודא שקיימת תת-רשת פעילה של שרת proxy בלבד באזור וברשת ה-VPC שצוינו. אם אין כזו, יוצרים רשת משנה אזורית של שרתי proxy בלבד (מינימום /26) עם --purpose=REGIONAL_MANAGED_PROXY ו---role=ACTIVE (ראו רשתות משנה של שרתי proxy בלבד למאזני עומסים מבוססי-Envoy).

מחיקת המשאב נכשלה

אם אתם לא מצליחים למחוק משאב, יכול להיות שנקודת קצה יוצאת משתמשת בו.

ניסיון למחוק משאב שנמצא בשימוש פעיל

פועלים לפי השלבים שמפורטים במאמר ניהול משאבי רשת שמשויכים לנקודות קצה יוצאות.

המאמרים הבאים