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

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

תחומים פרטיים

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

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

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

לא ניתן ליצור תחום פרטי, לא ניתן לרשום או ליצור מדיניות

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

תחומים פרטיים שלא מתבצעת להם פתרון באותה רשת VPC

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

מכונה וירטואלית (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 בשאילתה תואם לאזור שלכם

Trusted Cloud פותר רשומה בהתאם לסדר פענוח השמות, תוך שימוש בתחום עם הסיומת הארוכה ביותר כדי לקבוע באיזה תחום לשלוח שאילתה לגבי שם DNS נתון. חשוב לוודא שהסיומת של הרשומה שאליה שולחים את השאילתה תואמת לאזור פרטי אחד לפחות שאפשר לגשת אליו ברשת ה-VPC. לדוגמה, Trusted 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 ישירות ל Trusted Cloud שרת המטא-נתונים, 169.254.169.254:

dig DNS_NAME @169.254.169.254

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

dig DNS_NAME

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

תחומים פרטיים שלא מתבצעת להם פתרון באמצעות Cloud VPN או Cloud Interconnect

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

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

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

אפשר להשתמש בכל פרוטוקול, כמו ping (ICMP), כדי לבדוק את הקישוריות למכונה וירטואלית לדוגמה ברשת ה-VPC מהאתר המקומי. בקשות של Cloud DNS לא נשלחות למכונות וירטואליות מסוג Trusted Cloud , אבל בדיקת הקישוריות למכונה וירטואלית לדוגמה מאפשרת לאמת את הקישוריות דרך מנהרה של Cloud VPN או חיבור של Cloud Interconnect. חשוב להגדיר כלל חומת אש מתאים של הרשאה לתעבורת נתונים נכנסת (ingress) למכונה הווירטואלית לדוגמהTrusted 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 לא מופיעה ברשת או באזור שציפיתם להם, תוכלו לשלוח פנייה לTrusted Cloud תמיכה.

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

dig DNS_NAME @10.150.0.1 # address returned by previous command

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

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

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

תחומים של חיפוש הפוך

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

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

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

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

אזורי העברה

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

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

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

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

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

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

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

  • (VPN קלאסי בלבד) ברשת ה-VPC של הבעלים מוגדר נתיב סטטי ששולח תנועה שמיועדת לשרתי השמות המקומיים דרך המנהרה של ה-VPN הקלאסי. ברשת ה-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 מהאתר המקומי. צריך גם לנסות לשלוח שאילתה לשרת השמות המקומי ישירות ממכונתTrusted Cloud VM לדוגמה, באמצעות כלי כמו dig:

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

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

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

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

מוודאים שחומת האש המקומית מוגדרת כך שתאפשר תנועה נכנסת מ-177.222.82.0/25 ותנועה יוצאת אל 177.222.82.0/25.

בודקים את היומנים בחומת האש המקומית כדי לחפש בקשות DNS מ-177.222.82.0/25. כדי להשתמש בביטוי regex לחיפוש, צריך להשתמש בקוד הבא:

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

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

מוודאים שלא הגדרתם ACL בשרת השמות המקומי שיחסום שאילתות מ-177.222.82.0/25.

בודקים את שרת השמות המקומי כדי לראות אם הוא מקבל חבילות מ-177.222.82.0/25. אם יש לכם גישה ל-shell, תוכלו להשתמש בכלי כמו tcpdump כדי לחפש גם חבילות נכנסות מ-177.222.82.0/25 וגם חבילות יוצאות אל 177.222.82.0/25:

sudo tcpdump port 53 and tcp -vv

אימות מסלולי ההחזרה

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

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

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

העברה יוצאת ל-NIC משני נכשלת

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

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

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

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

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

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

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

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

נתונים לא צפויים כששולחים שאילתה לגבי קבוצות של רשומות משאבים שנמצאות בתחום

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

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

  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.

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

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

סוג משאב אזורי לא נתמך

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

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

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