סקירה כללית על נקודות קצה יוצאות

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

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

היכולות של נקודות קצה יוצאות

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

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

מידע נוסף על העברת הגדרת העברת Cloud DNS קיימת אל Outbound Endpoints זמין במאמר העברת הגדרת העברת Cloud DNS קיימת אל Outbound Endpoints.

ארכיטקטורה של נקודות קצה יוצאות וניתוב שאילתות

נקודת קצה ליציאה נוצרת ברשת VPC ספציפית, וכתובת ה-IP של המקור שלה היא רשת משנה של פרוקסי בלבד של אותה רשת.

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

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

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

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

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

בכל פרויקט אפשר להגדיר עד 10 נקודות קצה יוצאות לכל אזור, אבל אם צריך, אפשר לבקש הגדלה של המכסה במסוף Google Cloud . אפשר לצרף עד 100 נקודות קצה יוצאות לאזור העברה או למדיניות שרת.

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

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

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

  • יוצרים אזור עם מדיניות מיקום גיאוגרפי: יוצרים אזור פרטי חדש ב-Cloud DNS עבור FQDN שאתם שולטים בו (לדוגמה, onprem-resolvers.example.com) עם הרשאה לרשת ה-VPC שלכם. באזור הזה, יוצרים רשומות A לכתובות ה-IP של שרת ה-DNS המקומי ומחילים מדיניות ניתוב לפי מיקום גיאוגרפי. מגדירים את המדיניות כך שתחזיר כתובות IP של פותרי DNS לשאילתות שמקורן באזור הספציפי הזה. לדוגמה, החזרת כתובות IP של פותרי DNS אירופיים לשאילתות שמקורן באזורים Google Cloud באירופה.
  • שימוש ב-FQDN כיעד להעברה: באזור ההעברה, משתמשים ב-FQDN שיצרתם (onprem-resolvers.example.com) בתור שרת ה-DNS של היעד.
  • הגדרת נקודות קצה יוצאות: משייכים את נקודות הקצה היוצאות האזוריות (לדוגמה, אחת באזור בארה"ב ואחת באזור באירופה) לאזור ההעברה הזה.

כשמכונה וירטואלית באזור מסוים שולחת שאילתה, המערכת מבצעת תהליך ניתוב דו-שלבי:

  • בחירת נקודת קצה: מערכת Cloud DNS מעריכה את רשימת נקודות הקצה לתעבורה יוצאת שמשויכות לאזור ההעברה, ובוחרת את נקודת הקצה הכי מתאימה (לדוגמה, סביר להניח שתיבחר נקודת קצה באירופה לשאילתה ממכונה וירטואלית באירופה).
  • רזולוציית היעד: נקודת הקצה היוצאת שנבחרה פותרת את ה-FQDN של היעד (onprem-resolvers.example.com). מכיוון שנקודת הקצה היוצאת היא משאב אזורי שנמצא באזור שצוין, מדיניות המיקום הגיאוגרפי מזהה את מקור השאילתה כאזור הזה ומחזירה את כתובת ה-IP הספציפית שהגדרתם לאזור הזה. לאחר מכן, נקודת הקצה היוצאת מעבירה את השאילתה המקורית לכתובת ה-IP של שרת ה-DNS המטורגט.

מידע נוסף זמין במדריך העברה יוצאת של DNS ב-Cloud DNS FQDN.

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

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

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

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

  1. יצירת נקודת קצה יוצאת בכל רשת VPC: מידע נוסף זמין במאמר יצירת נקודת קצה יוצאת.
  2. יצירת אזור העברה או מדיניות שרת בכל רשת VPC: מאשרים את אזור ההעברה או את מדיניות השרת רק לרשת ה-VPC הזו, ומשתמשים רק בנקודת הקצה לתעבורה יוצאת של רשת ה-VPC הזו.

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

העברה מאוחדת בין רשתות VPC שונות (Hub-and-Spoke)

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

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

  1. יוצרים נקודת קצה יוצאת ברשת ה-VPC של הרכזת.
  2. יוצרים אזור העברה או מדיניות שרת ברשת ה-VPC של ה-spoke ומגדירים אותם לשימוש בנקודת הקצה היוצאת של רשת ה-hub.

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

תמיכה ב-VPC משותף

נקודות קצה יוצאות תומכות בפריסות של VPC משותף. נקודת הקצה ורשת המשנה שמשויכת אליה ומשמשת רק לשרתי proxy נוצרות באופן מרכזי בפרויקט המארח. לאחר מכן, בפרויקטים של השירות אפשר ליצור אזורי העברה פרטיים או מדיניות שרתים, ולקשר אותם בין פרויקטים לנקודת הקצה המרכזית ליציאה בפרויקט המארח (נדרש dns.outboundEndpoints.bindPrivateDNSZone או dns.outboundEndpoints.bindPrivateDNSPolicy בפרויקט המארח).

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

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

מחיקה של רשת משנה או רשת VPC שמוגדרות כ-proxy בלבד, כשהן בשימוש של נקודת קצה יוצאת

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

  1. עדכון ההגדרה של Cloud DNS: עורכים את אזורי ההעברה או את מדיניות השרת שמשתמשים בנקודת הקצה היוצאת ומסירים אותה מההגדרה כדי שלא ייעשה בה יותר שימוש.
  2. מחיקת נקודת הקצה (endpoint) היוצאת: אחרי שנקודת הקצה לא בשימוש, אפשר למחוק אותה. הפעולה הזו מבטלת את התלות ברשת המשנה של ה-proxy בלבד.
  3. מחיקת רשת המשנה של ה-proxy בלבד: אחרי שמוודאים שאין משאבים אחרים שמשתמשים ברשת המשנה, מוחקים אותה.
  4. מחיקת רשת ה-VPC: אחרי שמסירים את כל התלות ברשת ה-VPC, אפשר למחוק אותה.

שינוי רשת משנה

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

כדי לשנות רשת משנה שמשמשת נקודת קצה יוצאת:

  1. יצירת רשת משנה לגיבוי: יוצרים רשת משנה חדשה של שרתי proxy בלבד באותו אזור ורשת VPC. במהלך היצירה, צריך להגדיר את התפקיד של רשת המשנה הזו ל-BACKUP.
  2. מפעילים את רשת המשנה החדשה: מעדכנים את התפקיד של רשת המשנה החדשה ל-ACTIVE. הפעולה הזו תגדיר אוטומטית את רשת המשנה המקורית לתפקיד BACKUP ותתחיל לנתק ממנה חיבורים פעילים.
  3. ‫Wait for draining: המתנה עד להשלמת תהליך (connection draining).
  4. מחיקת רשת המשנה הישנה: עכשיו אפשר למחוק את רשת המשנה המקורית, אחרי שהיא בתפקיד BACKUP ואין לה חיבורים פעילים.

חיזוי של כתובות IP ייעודיות למקור עבור חומות אש מקומיות

אם חומות האש של ה-DNS המקומי דורשות טווח כתובות IP ייעודי וצפוי של מקור, שמבודד לתנועת DNS, מומלץ להשתמש בארכיטקטורה הבאה:

  • פריסה ברשת VPC ייעודית לתעבורת נתונים יוצאת: יוצרים רשת VPC ייעודית עם תת-רשת רגילה (לכתובת ה-IP של נקודת הקצה לתעבורת נתונים יוצאת) ותת-רשת אזורית של שרת proxy בלבד, ששמורה באופן בלעדי ל-Cloud DNS ‏ (--purpose=REGIONAL_MANAGED_PROXY ו---role=ACTIVE).
  • בידוד רשתות ה-VPC של האפליקציה: אל תבצעו התאמת רשתות או ניתוב של רשתות ה-VPC של האפליקציה לרשת הייעודית הזו לתעבורת נתונים יוצאת. ‫Cloud DNS מנתב שאילתות באופן פנימי בתוך התשתית של Google Cloud, כך שלא נדרש קישוריות רשת ישירה בין רשתות ה-VPC האלה.
  • חיבור רשת ה-VPC הייעודית לתעבורת נתונים יוצאת ליעדי העברה חיצוניים: מגדירים קישוריות רק בין רשת ה-VPC הייעודית לתעבורת נתונים יוצאת לבין שרתי השמות החיצוניים או המקומיים של היעד. כדי ליצור את הנתיב הזה, משתמשים בפקודות הבאות:
    • קישור בין רשתות VPC שכנות (peering) לרשת VPC קיימת למעבר: זו הגישה המומלצת והמשתלמת ביותר. אם לארגון שלכם כבר יש רשת VPC מרכזית להעברה עם Cloud Interconnect או Cloud VPN לרשת מקומית, צריך להגדיר את רשת ה-VPC הייעודית ל-DNS כרשת שכנה של מרכז ההעברה הזה. הגישה הזו מאפשרת להימנע מהקצאת מעגלים היברידיים מיותרים ומצמצום העלויות.
    • קישוריות היברידית ישירה: Dedicated Interconnect,‏ Cross-Cloud Interconnect או Cloud VPN שמסתיים ישירות ברשת ה-VPC הייעודית של DNS.

מגבלות

לנקודות קצה יוצאות יש את המגבלות הבאות:

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

  • אין תמיכה בקישור ישיר (direct peering) לרשתות משנה שמשמשות רק כפרוקסי: אי אפשר לבצע קישור ישיר לרשת משנה שמשמשת רק כפרוקסי. צריך ליצור קישוריות לרשת לשרתי שמות חיצוניים באמצעות ניתוב VPC רגיל, כמו Cloud Interconnect, ‏ Cloud VPN או VPC Network Peering.

  • תמיכה ב-IPv4 בלבד: כתובת ה-IP של המקור של נקודת קצה יוצאת היא IPv4 בלבד, ואפשר להעביר שאילתות רק ליעדי IPv4 או ליעדי העברה של FQDN באזורי העברה שמפנים לכתובות IPv4.

  • אי אפשר לקשר נקודות קצה יוצאות לרשת בפרויקטים שונים: אי אפשר ליצור נקודת קצה יוצאת בפרויקט שירות שמקושר לרשת VPC משותפת של פרויקט מארח. נקודות קצה יוצאות צריכות להיות באותו הפרויקט כמו רשת ה-VPC ורשת המשנה שאליהן הן מצורפות.

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

  • היקף אזורי: נקודות קצה יוצאות הן משאבים אזוריים. צריך ליצור נקודות קצה בכל אזור שמתכוונים להשתמש בהן.

  • מנגנון העברה יחיד בלבד: מנגנון ההעברה (טווח ברירת המחדל 35.199.192.0/19 או נקודות קצה יוצאות) מוגדר ברמת אזור ההעברה או מדיניות השרת. עם זאת, אי אפשר להשתמש בשתי השיטות בו-זמנית לאותו אזור או לאותה מדיניות.

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