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

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

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

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

בעיות באזורים פרטיים בפרויקטים של שירות 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 בשאילתה תואם לאזור שלכם

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

dig DNS_NAME @169.254.169.254

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

dig DNS_NAME

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

אזורים פרטיים לא נפתרים באמצעות Cloud VPN או Cloud Interconnect

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

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

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

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

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

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

gcloud dns policies list

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

מוודאים שהרשת המורשית היא רשת 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 ברשת או באזור שציפיתם, שלחו כרטיס תמיכה אל Cloud de Confiance Support.

מריצים את הפקודה 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 לחיפוש הפוך (reverse lookup zone). חלק מהבעיות באזורים פרטיים רלוונטיות גם לתחומי 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 משתמשת באזור peering ששולח שאילתות לגבי example.com. אל רשת VPC2. נניח גם של-VPC2 יש אזור העברה פרטי של example.com. שמעביר את השאילתות לשרת שמות מקומי באמצעות מנהרת VPN קלאסי.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רשימה של משאבים ותכונות שנתמכים ב-Cloud DNS אזורי מופיעה במאמר תמיכה ב-Cloud 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: האזור שבו נמצאת נקודת הקצה

קישוריות רשת

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

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

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

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

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

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

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

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

מיצוי של רשת משנה מסוג Proxy-only

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

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

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

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

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

בעיה בהרשאות 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 שצוינה תקינה, אבל משאב אחר כבר משתמש בה

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

המערכת לא הצליחה למצוא רשת משנה פעילה שמוגדר בה רק פרוקסי אזורי

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

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

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

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

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

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