הגדרת Agent Gateway עם קישוריות ל-VPC

במאמר הזה מוסבר איך להגדיר קישוריות VPC כשפורסים Agent Gateway, כדי שהוא יוכל לתקשר באופן פרטי עם רשת VPC בארגון.

הגדרת קישוריות VPC מאפשרת לכם:

• אכיפת יציאה (egress) של תנועה מה-VPC: ניתוב תנועה שמגיעה מהסוכנים שלכם דרך רכיב ה-Private Service Connect שלכם אל רשת ה-VPC שלכם באמצעות מצב PRIVATE_RANGES_ONLY או ALL_TRAFFIC.
• טווח כתובות IP סטטיות של המקור: תעבורת היציאה משתמשת בטווח כתובות ה-IP הפרטיות של רשת המשנה של קובץ ה-attachment של Private Service Connect בתור כתובת ה-IP של המקור. טווח כתובות ה-IP הסטטיות של המקור מאפשר לכם להגדיר מדיניות חומת אש לרשת ה-VPC כדי לשלוט בתעבורת הנתונים שמגיעה מהשער.
• פענוח DNS בהתאמה אישית: פענוח של שמות דומיינים פנימיים פרטיים ושמות דומיינים חיצוניים ישירות מהסוכנים באמצעות קישור בין רשתות שכנות (peering) ב-Cloud DNS.
• אבטחת היקף: הגנה על התקשורת של הסוכן באמצעות אזורי אבטחה של VPC Service Controls.
• אימות של אישור פרטי או אישור בחתימה עצמית: חיבור ליעדים שמשתמשים ברשויות אישורים פרטיות או באישורים בחתימה עצמית.

כדי להגדיר קישוריות VPC, יוצרים תבנית קישוריות של Agent Gateway (AgentConnectivityTemplate) שבה מגדירים ומנהלים את הגדרות הרשת של יציאת הנתונים (egress) עבור מופעי Agent Gateway.

איך פועלת הקישוריות של VPC

כשפורסים Agent Gateway עם תבנית קישוריות, השער משתמש בממשק Private Service Connect כדי לנתב תעבורת נתונים יוצאת של סוכן לרשת ה-VPC המיועדת.

מצבי תעבורת נתונים יוצאת (egress) ב-VPC

אתם מגדירים איך השער מנתב את תעבורת הנתונים דרך מחבר הרשת באמצעות ההגדרה vpcEgress בתבנית הקישוריות.

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

  • ‫RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • ‫RFC 6598: 100.64.0.0/10
  • Class E: 240.0.0.0/4
  • private.googleapis.com: 199.36.153.8/30
  • restricted.googleapis.com: 199.36.153.4/30
  • נקודות קצה של PSC לממשקי Google APIs: אם פורסים נקודת קצה מותאמת אישית של Private Service Connect לממשקי Google APIs באמצעות כתובת IP פנימית פרטית ברשת ה-VPC, התנועה לנקודת הקצה הזו מנותבת דרך רשת ה-VPC. מוודאים ששירות Cloud DNS peering מוגדר בתבנית הקישוריות, כדי ש-Agent Gateway יפתור נכון את דומייני Google API לכתובת ה-IP של נקודת הקצה הפנימית של PSC.

  בקשות לממשקי API ציבוריים רגילים של Google מטופלות באופן אוטומטי באמצעות גישה פרטית ל-Google, ותעבורת נתונים שמיועדת לאינטרנט מנותבת ישירות דרך Agent Gateway ולא דרך רשת ה-VPC.

• תנועה לכל טווחי כתובות ה-IP‏ (ALL_TRAFFIC): המערכת מנתבת את כל התנועה היוצאת שמגיעה מהסוכנים שלכם דרך רשת ה-VPC, כולל האינטרנט הציבורי, ממשקי API חיצוניים של SaaS וכתובות שאינן RFC 1918.

  • ניתוב ואבטחה: מכיוון שההגדרה הזו מנתבת את כל התנועה היוצאת ל-VPC, אתם אחראים לניהול הניתוב והאבטחה שלה. מוודאים שברשת ה-VPC יש נתיב ברירת מחדל (0.0.0.0/0) להעברת התעבורה הזו אל שערים יוצאים או אל מכשירי אבטחה (כמו חומות אש של הניתור הבא או ממשקי Cloud Interconnect).
  • תעבורת נתונים יוצאת (egress) לאינטרנט הציבורי: Agent Gateway שולח תעבורה יוצאת לרשת ה-VPC שלכם, שממנה היא יוצאת לאינטרנט הציבורי דרך שער Cloud NAT ברשת המשנה של קובץ המצורף לרשת Private Service Connect. אם מקצים כתובות IP חיצוניות סטטיות לשער Cloud NAT, שירותים מרוחקים יכולים להוסיף לרשימת ההיתרים את תעבורת הנתונים היוצאת של הסוכנים על סמך כתובות ה-IP האלה כמקור.
  • ‫VPC Service Controls: כדי לתמוך בהיקפי אבטחה של שירותים ב-VPC Service Controls, צריך להגדיר את מצב התעבורה היוצאת (egress) ל-ALL_TRAFFIC.

פענוח DNS וניתוב תעבורת נתונים

כברירת מחדל, Agent Gateway מפענח שמות דומיינים באמצעות DNS ציבורי רקורסיבי. אם הסוכנים שלכם צריכים לגשת לעומסי עבודה פנימיים, לכלים פרטיים או לממשקי Google API שמתארחים בשמות דומיין פרטיים ברשת ה-VPC שלכם (כמו corp.internal. או נקודות קצה של PSC), אתם יכולים להגדיר קישור בין רשתות שכנות (peering) ב-Cloud DNS כדי להעביר שאילתות DNS לאזורים המנוהלים הפרטיים של Cloud DNS ברשת שלכם.

בטבלה הבאה מפורטות דרישות ה-peering של Cloud DNS והתנהגות הניתוב של התנועה ליעדים שונים כשקישוריות ה-VPC מוגדרת במצב ALL_TRAFFIC:

הדרישות לגבי אישור TLS

כשמנתבים תעבורת נתונים יוצאת (egress) דרך HTTPS, Agent Gateway מאמת את שרשרת אישורי ה-TLS של שרת היעד במהלך לחיצת יד בפרוטוקול TLS. דרישות האישורים לחיבורי HTTPS תלויות בנקודות הקצה של היעד. אם הן משתמשות ברשויות אישורים (CA) מהימנות לציבור או ברשויות אישורים פרטיות או בחתימה עצמית.

• רשויות אישורים ציבוריות: כברירת מחדל, Agent Gateway סומך על אישורים שהונפקו על ידי רשויות אישורים ציבוריות מהימנות שעומדות בדרישות התקן של אישורי שרת (כולל שם נושא חלופי (SAN) שתואם לשם המארח של היעד).

• רשויות אישורים פרטיות ואישורים בחתימה עצמית: אם יעד היעד (סוכנים, כלים או שרתי MCP ברשת ה-VPC) משתמש ברשות אישורים פרטית או ב-PKI פנימי, אפשר להגדיר עוגני אמון מותאמים אישית באמצעות ההגדרה tlsConfig בתבנית הקישוריות. באמצעות הפניה למשאב של TrustConfigCertificate Manager, אפשר להגדיר את Agent Gateway כך שיסמוך רק על רשויות אישורים פרטיות ספציפיות, או לשלב רשויות אישורים פרטיות עם רשויות אישורים שמהימנות על ידי הציבור כדי ליצור מהימנות גם עבור נקודות קצה ציבוריות וגם עבור נקודות קצה פרטיות.

  כשמשתמשים ב-trustConfig כדי לנתב תעבורה ליעדים שמשתמשים ב-CA פרטי, צריך להחליף את קובצי ה-PEM באופן ידני. אין תמיכה ברוטציה אוטומטית של קובצי PEM באמצעות כלי ניהול סודות, כמו Secret Manager שלCloud de Confiance.

אם Agent Gateway לא מצליח לאמת את שרשרת האישורים, החיבור נכשל.

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

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

פריסות של פרויקטים עצמאיים

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

פריסות ב-VPC משותף או פריסות בין פרויקטים

אם אתם משתמשים ב-VPC משותף או בהגדרה חוצת-פרויקטים שבה רשת ה-VPC, קובץ ה-Network Attachment או אזורי ה-DNS הפרטיים נמצאים בפרויקט מארח מרכזי (TARGET_VPC_PROJECT_ID), אתם צריכים את התפקידים הבאים בנוסף להרשאות הרגילות של Agent Gateway:

הגדרת קישוריות ל-VPC

כדי לפרוס Agent Gateway עם תבנית קישוריות:

1. יוצרים קובץ מצורף עם הרשת של Private Service Connect ברשת ה-VPC של היעד.

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

   • העדפת חיבור: מגדירים את מחבר הרשת כך שהחיבורים יאושרו באופן אוטומטי (--connection-preference=ACCEPT_AUTOMATIC).
   • דרישה לגבי אותה רשת VPC: תת-הרשת של קובץ ה-Network Attachment ורשת היעד שהוגדרה עבור שיתוף DNS (targetNetwork) צריכות להיות באותה רשת VPC בדיוק. אם רשת המשנה של הקובץ המצורף לרשת שייכת לרשת אחרת מרשת היעד של שיתוף ה-DNS, אימות ההגדרה ייכשל.
   • דרישות לגבי תת-רשת: חשוב לשים לב לדרישות הבאות לגבי תת-הרשת של צירוף הרשת:
     • טווח רשת המשנה: רשת המשנה של מחבר הרשת תומכת בכל הטווחים התקינים.
     • גודל רשת המשנה: Agent Gateway דורש רשת משנה בגודל מינימלי עבור מחבר הרשת./28 /28 תת-רשת מספקת 12 כתובות IP שניתנות לשימוש, וזה מספיק למופע יחיד של Agent Gateway. אם אתם מתכננים לחבר כמה שערים לאותו קובץ מצורף לרשת או לאותה רשת משנה, כדאי להשתמש ברשת משנה גדולה יותר (למשל /26 או /24) כדי להימנע ממיצוי של כתובות ה-IP.
     • דרישה לגישה פרטית ל-Google: צריך להפעיל גישה פרטית ל-Google (private_ip_google_access = true) ברשת המשנה שמארחת את הקובץ המצורף לרשת.
   • פריסות של VPC משותף: למידע על פריסות של VPC משותף, אפשר לעיין בטופולוגיות של פריסות של VPC משותף.

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

2. הגדרת קישור בין רשתות שכנות (peering) ב-DNS (אופציונלי): קישור בין רשתות שכנות ב-DNS מאפשר ל-Agent Gateway לפתור שמות DNS באמצעות רשומות מאזור מנוהל פרטי של Cloud DNS ברשת ה-VPC שלכם. הצמדת DNS נדרשת רק אם הסוכנים צריכים לפתור שמות דומיין פנימיים פרטיים (כמו corp.internal.) או לאכוף VPC Service Controls עבור ממשקי API של Google‏ (googleapis.com.). היא לא נדרשת עבור דומיינים באינטרנט הציבורי או ממשקי API רגילים של Google ללא VPC Service Controls.

   ‫Agent Gateway תומך בחיבור DNS טרנזיטיבי רק עד קפיצה טרנזיטיבית אחת, כלומר עד שלוש רשתות VPC. לדוגמה, vpc-net-a (רשת הדיירים של Agent Gateway) יכולה לבצע פעולת Peering עם vpc-net-b (רשת מצורפת), שבתורה מבצעת פעולת Peering עם vpc-net-c (רשת מרוחקת) כדי לפתור שאילתות DNS לאורך השרשרת.

   כדי להגדיר קישור בין רשתות שכנות (peering) ב-DNS:

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

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

      • ‫Target network URI (targetNetwork): ה-URI המלא של המשאב של רשת ה-VPC היעד. זו צריכה להיות אותה רשת VPC שמכילה את מחבר הרשת.

      • שמות דומיינים: סיומת דומיין אחת או יותר לצורך קישור בין רשתות שכנות (peering) ב-DNS. כל דומיין צריך להסתיים בנקודה (.) (לדוגמה, corp.internal. או googleapis.com.).

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

3. הגדרת אמון ב-TLS (רק ליעדים עם רשויות אישורים פרטיות ואישורים בחתימה עצמית):

   אם יעד ההעברה משתמש ב-CA פרטי או באישור בחתימה עצמית, צריך ליצור משאב TrustConfig בניהול האישורים. במשאב TrustConfig מוגדרים ישויות עוגן אמינות ותעודות ש-Agent Gateway משתמש בהם כדי לאמת חיבורי TLS.

   1. מכינים את קובצי האישורים בפורמט PEM:

      • מאגר האישורים המהימנים: אישורי CA בסיסיים או אישורי ביניים בפורמט PEM. Agent Gateway סומך על כל אישור שרת ששרשרת האמון שלו מובילה לאחד מאישורי רשות האישורים האלה. מאגר האישורים צריך להכיל לפחות אישור CA אחד של שורש או של ביניים.
      • אישורים ברשימת ההיתרים (אופציונלי) : אישורים של שרתים בפורמט PEM שרוצים לתת להם אמון באופן מפורש, כמו אישור בחתימה עצמית.

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

      gcloud certificate-manager trust-configs create TRUST_CONFIG_NAME \
        --location=LOCATION \
        --trust-store="trust-anchors=ROOT_CERT_FILE" \
        --allowlisted-certificates=ALLOWLISTED_CERT_FILE
      

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

      • ‫TRUST_CONFIG_NAME: שם למשאב TrustConfig.
      • ‫LOCATION: האזור של הגדרת האמון (לדוגמה, europe-west1). האזור הזה צריך להיות זהה לאזור של Agent Gateway ולתבנית הקישוריות.
      • ‫ROOT_CERT_FILE: הנתיב לאישור CA בסיסי או ביניים שמקודד ב-PEM.
      • ‫ALLOWLISTED_CERT_FILE: (אופציונלי) הנתיב לאישור בקידוד PEM שרוצים להגדיר לו אמון באופן מפורש. אם אתם לא משתמשים באישור שנוסף לרשימת ההיתרים, אל תכללו את הדגל הזה.

      מידע נוסף על ניהול הגדרות אמון זמין במאמר יצירה וניהול של הגדרות אמון.

4. פריסת Agent Gateway

   1. יוצרים את קובץ התצורה של תבנית הקישוריות:

      יוצרים קובץ YAML בשם agw-connectivity-template.yaml:

      name: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
      accessPath: AGENT_TO_ANYWHERE
      deploymentModel: CENTRALIZED
      egressNetworkConfig:
        networkAttachment: PSC_NETWORK_ATTACHMENT_URI
        dnsPeeringConfig:
          domains:
            - DOMAIN_NAME
          targetNetwork: TARGET_VPC_NETWORK_URI
        vpcEgress: VPC_EGRESS_MODE
        tlsConfig:
          trustConfig: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
          additionalRoots: ADDITIONAL_ROOTS_OPTION
      

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

      • ‫AGENT_GATEWAY_PROJECT_NUMBER: מספר הפרויקט המספרי של Cloud de Confiance הפרויקט שבו שער הגישה נפרס. כדי לאחזר את מספר הפרויקט, מריצים את הפקודה: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • ‫LOCATION: האזור של תבנית הקישוריות (לדוגמה, europe-west1).

      • ‫CONNECTIVITY_TEMPLATE_NAME: השם של משאב תבנית הקישוריות.

      • ‫accessPath: נתיב הגישה המנוהלת לתבנית הקישוריות. הערך שמוגדר הוא AGENT_TO_ANYWHERE (תבניות קישוריות נתמכות רק עבור שערים של תעבורת נתונים יוצאת).

      • ‫deploymentModel: מודל הפריסה של השער. הערך שהוגדר הוא CENTRALIZED.

      • ‫PSC_NETWORK_ATTACHMENT_URI: מחבר הרשת של ממשק PSC לקישוריות לרשתות VPC. אם יצרתם את רכיב Network Attachment בפרויקט אחר מזה שבו פרסתם את השער (למשל, בפרויקט מארח של VPC משותף), צריך להעביר את הנתיב המלא של רכיב Network Attachment: projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME.

      • ‫DOMAIN_NAME: (אופציונלי) סיומת דומיין אחת או יותר לצורך שיתוף פעולה בין שרתי DNS (לדוגמה, corp.internal.,‏ googleapis.com. או .). מוסיפים פריט לרשימה בקטע domains לכל סיומת דומיין שרוצים לשתף. כל ערך חייב להסתיים בנקודה (.) ולכלול אזור מנוהל של Cloud DNS פרטי שתואם לרשת היעד.

        הנחיות נוספות להגדרת השדה domains זמינות במאמר תבניות של דומיינים ב-DNS Peering.

      • ‫TARGET_VPC_NETWORK_URI: רשת ה-VPC של היעד שבה יצרתם את רכיב Network Attachment. הערך צריך להיות בפורמט הבא: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. תמיד מציינים את targetNetwork באמצעות מזהה הפרויקט (TARGET_VPC_PROJECT_ID) ולא באמצעות מספר הפרויקט.

      • ‫VPC_EGRESS_MODE: הגדרת מצב ניתוב התנועה היוצאת. הערך צריך להיות PRIVATE_RANGES_ONLY או ALL_TRAFFIC.

      • ‫tlsConfig: (אופציונלי) הגדרת ה-TLS לאימות של אישור השרת כשמתחברים לנקודות קצה פרטיות באמצעות HTTPS:

        • ‫TRUST_CONFIG_NAME: השם של משאב TrustConfig Certificate Manager שמכיל את אישורי ה-CA הפרטיים או את נקודות האמון.
        • ‫ADDITIONAL_ROOTS_OPTION: מציין אם צריך לסמוך על רשויות אישורי בסיס מהימנות ציבוריות בנוסף להגדרת האמון המותאמת אישית. הערך שמוגדר כברירת מחדל הוא PUBLICLY_TRUSTED_ROOTS, כך שגם אישורים שאומתו על ידי הפרמטר trustConfig וגם כל רשויות האישורים הציבוריות המהימנות נחשבים מהימנים. מגדירים את הערך NO_ADDITIONAL_ROOTS כדי לתת אמון רק באישורים שאומתו על ידי הפרמטר trustConfig.

   2. יוצרים את תבנית הקישוריות:

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

      gcloud network-services agent-connectivity-templates import CONNECTIVITY_TEMPLATE_NAME \
          --source="agw-connectivity-template.yaml" \
          --location=LOCATION
      

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

      • ‫CONNECTIVITY_TEMPLATE_NAME: השם של משאב תבנית הקישוריות.
      • ‫LOCATION: המיקום שבו רוצים ליצור את משאב תבנית הקישוריות. לדוגמה, europe-west1.

   3. הגדרת משאב Agent Gateway:

      מגדירים משאב חדש של Agent Gateway במצב AGENT_TO_ANYWHERE על ידי יצירת קובץ הגדרות של שער ב-YAML (לדוגמה, my-agent-gateway-vpc-egress.yaml) שמפנה לתבנית הקישוריות:

      name: AGENT_GATEWAY_NAME
      protocols:
        - MCP
      googleManaged:
        governedAccessPath: AGENT_TO_ANYWHERE
      agentConnectivityTemplate: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
      registries:
        - AGENT_REGISTRY_PATH
      

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

      • ‫AGENT_GATEWAY_NAME: השם של משאב Agent Gateway.

      • ‫AGENT_GATEWAY_PROJECT_NUMBER: מספר הפרויקט המספרי של Cloud de Confiance הפרויקט שבו יצרתם את השער ואת תבנית הקישוריות. כדי לאחזר את מספר הפרויקט, מריצים את הפקודה: gcloud projects describe PROJECT_ID --format="value(projectNumber)".

      • ‫LOCATION: המיקום של תבנית הקישוריות (לדוגמה, europe-west1).

      • ‫CONNECTIVITY_TEMPLATE_NAME: השם של משאב תבנית הקישוריות.

      • ‫AGENT_REGISTRY_PATH: הנתיב ל-Agent Registry. אפשר להגדיר עד שני רשומות עבור Agent Gateway. כשמגדירים שני מאגרי מידע, אחד מהם חייב להיות מאגר מידע גלובלי, והשני יכול להיות מאגר מידע אזורי או רב-אזורי. הפורמט של נתיבי הרישום צריך להיות כזה:

        • רישומים אזוריים: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • מאגרי מידע גלובליים: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • רישומים במספר אזורים: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

   4. ייבוא ופריסה של Agent Gateway:

      מריצים את הפקודה הבאה כדי ליצור את משאב Agent Gateway על סמך מפרט ה-YAML:

      gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
          --source="my-agent-gateway-vpc-egress.yaml" \
          --location=LOCATION
      

      מחליפים את LOCATION במיקום שבו רוצים ליצור את משאב Agent Gateway. לדוגמה, europe-west1.

שיקולים לגבי ארכיטקטורה ורשת

בקטע הזה מפורטות הנחיות לגבי ארכיטקטורה ודפוסי רשת מתקדמים לפריסת Agent Gateway עם קישוריות VPC.

עדכון הגדרות של תעבורת נתונים יוצאת (egress) ב-VPC

אי אפשר לשנות תבנית קישוריות אם יש הפניה אליה ב-Agent Gateway.

• כדי לעדכן הגדרות יוצאות של VPC שאפשר לשנות (כמו הגדרות של שילוב DNS, מצב יציאה של VPC או הגדרות TLS), צריך ליצור תבנית קישוריות חדשה שמשתמשת באותו networkAttachment ולעדכן את Agent Gateway כך שיפנה לתבנית החדשה.

• אחרי שמגדירים את networkAttachment ב-Agent Gateway, אי אפשר לשנות אותו. כדי לעבור לחיבור רשת אחר (או לרשת VPC יעד אחרת), צריך ליצור תבנית קישוריות חדשה ושער סוכן חדש.

טופולוגיות פריסה של VPC משותף

באמצעות ארכיטקטורת VPC משותף, אפשר ליצור את רכיב Network Attachment בפרויקט השירות (מומלץ) או בפרויקט המארח:

• מומלץ: צירוף רשת בפרויקט שירות:
  1. יוצרים את רשת המשנה בפרויקט המארח.
  2. יוצרים את קובץ הרשת המצורף בפרויקט השירות, עם הפניה לרשת המשנה של פרויקט המארח.
• צירוף רשת בפרויקט המארח:
  1. יוצרים את רשת המשנה בפרויקט המארח.
  2. יוצרים את הקובץ המצורף של הרשת בפרויקט המארח.

תאימות ל-VPC Service Controls

כדי לאכוף את גבולות הגזרה של VPC Service Controls בתקשורת של הסוכן, צריך לוודא את הדברים הבאים:

• מגדירים את vpcEgress ל-ALL_TRAFFIC בתבנית הקישוריות.

• בקשות ישירות ל-Google API לטווח כתובות ה-IP‏ restricted.googleapis.com (199.36.153.4/30) או לנקודת קצה פנימית של Private Service Connect ל-Google APIs.

• הגדרת פענוח DNS ל-googleapis.com. יוצרים תחום DNS פרטי של Cloud DNS במיפוי רשת ה-VPC שלכם *.googleapis.com אל restricted.googleapis.com, וכוללים את googleapis.com. בשדה domains של תבנית הקישוריות.

  פרטים נוספים על הגדרת DNS זמינים במאמר הגדרת DNS עבור googleapis.com במסמכי גישה פרטית ל-Google.

• בפריסות של VPC משותף, הפרויקט המארח שבבעלותו רשת המשנה של מחבר הרשת dnsPeeringConfig.targetNetwork חייב להיות באותו גבולות גזרה לשירות כמו הפרויקט שבו פורסים את Agent Gateway. זה נכון גם כשיוצרים את רשת ה-VPC המצורפת בפרויקט השירות, כי תת-הרשת ורשת ה-VPC עדיין שייכות לפרויקט המארח. אם אזורי ה-DNS הפרטיים מתארחים בפרויקט DNS נפרד, צריך לכלול גם את הפרויקט הזה בהיקף.

תבניות של דומיינים ב-DNS

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

הגדרת שם הדומיין: מגדירים את השדה domains בתבנית הקישוריות בהתאם לשיקולים הבאים:

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

• DNS עם אופק חצוי (דומיין ציבורי עם כתובת IP מסוג RFC 1918): אם אתם משתמשים ב<b>תחום DNS</b> ציבורי לאירוח רשומות שמפנות לכתובות IP פרטיות פנימיות (לדוגמה, mcp.example.com שמוגדרת ככתובת RFC 1918 עבור אישורים ציבוריים של Certificate Manager), השער יפתור את הרשומות האלה באופן אוטומטי באמצעות DNS רקורסיבי ציבורי, בלי שיהיה צורך בקישור בין רשתות שכנות (peering) ב-DNS.

• ‫Cloud de Confiance APIs with VPC Service Controls: When ALL_TRAFFIC is configured to enforce VPC Service Controls, Google API requests must resolve to the restricted.googleapis.com IP range (199.36.153.4/30) or to internal PSC endpoints. יוצרים תחום DNS פרטי ב-Cloud DNS במיפוי רשת ה-VPC‏ *.googleapis.com אל restricted.googleapis.com, וכוללים את googleapis.com. בשדה domains של תבנית הקישוריות.

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

  • יצירת קשר בין כמה דומיינים נפרדים: מציינים רשימה של סיומות דומיין בשדה domains של dnsPeeringConfig (לדוגמה, corp.internal., prod.internal. ו-googleapis.com.). כל דומיין ברשימה חייב להסתיים בנקודה (.) ולהיות לו אזור פרטי תואם שמנוהל על ידי Cloud DNS ומורשה לרשת ה-VPC של היעד.
  • איחוד סיומת של דומיין הורה (מומלץ): איחוד של שירותים פנימיים תחת סיומת משותפת של דומיין הורה (כמו *.internal. או *.corp.internal.) והוספה של דומיין ההורה לרשימה domains.

  • קישור בין רשתות שכנות (peering) של דומיין הבסיס עם אזור העברה פרטי: כוללים את "." בשדה domains של תבנית הקישוריות, ומגדירים אזור העברה פרטי ב-Cloud DNS לדומיין הבסיס (.) ברשת ה-VPC שמפנה לפתרון רקורסיבי במעלה הזרם (כמו 8.8.8.8 או פתרון פנימי של ארגון). אזורים פרטיים ספציפיים יותר ב-VPC שלכם מותאמים קודם לפי ההתאמה הארוכה ביותר של הסיומת, בעוד ששאילתות ציבוריות שלא נמצאה להן התאמה נפתרות באמצעות המפנה לשרתים במעלה הזרם.

הדרישות לגבי תחום DNS ופירינג בין פרויקטים

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

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

• אזור פרטי מהימן
• אזור העברה
• אזור שכנות ב-Cloud DNS: צריך להיות משויך לרשת ה-VPC של הפרויקט המארח ולכוון לרשת VPC של יעד. רשת ה-VPC של היעד חייבת לפתור את השאילתה ישירות באמצעות אזור פרטי סמכותי. העברת השאילתה לאזור אחר של DNS peering (שרשור) לא נתמכת וגורמת לשגיאה NXDOMAIN.

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