הטמעה של עיצוב הרשת של אזור הנחיתה ב-Google Cloud

Last reviewed 2026-01-02 UTC

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

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

אפשרויות לעיצוב הרשת

בהתאם לעיצוב הרשת שבחרתם, מבצעים אחת מהפעולות הבאות:

אפשרות 1: יצירת רשת VPC משותפת לכל סביבה

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

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

הגבלת גישה חיצונית באמצעות מדיניות ארגונית

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

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

הגבלת העברת פרוטוקולים על סמך סוג כתובת ה-IP

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

האילוץ Restrict Protocol Forwarding Based on type of IP Address מונע יצירה של כללי העברה עם כתובות IP חיצוניות בכל הארגון. בפרויקטים שיש להם הרשאה להשתמש בכללי העברה חיצוניים, אפשר לשנות את האילוץ ברמת התיקייה או הפרויקט.

כדי להגדיר את המגבלה הזו, צריך להגדיר את הערכים הבאים:

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי המדיניות: מותאם אישית
  • סוג המדיניות: דחייה
  • ערך בהתאמה אישית: IS:EXTERNAL

הגדרה של כתובות IP חיצוניות שאושרו למכונות וירטואליות

כברירת מחדל, מכונות וירטואליות יכולות לקבל כתובות IP חיצוניות, שמאפשרות קישוריות יוצאת ונכנסת לאינטרנט.

החלת האילוץ Define allowed external IPs for VM instances מונעת את השימוש בכתובות IP חיצוניות עם מופעי מכונות וירטואליות. עבור עומסי עבודה שנדרשות להם כתובות IP חיצוניות במכונות וירטואליות ספציפיות, צריך לשנות את האילוץ ברמת התיקייה או הפרויקט כדי לציין את המכונות הווירטואליות הספציפיות. או לבטל את האילוץ בפרויקטים הרלוונטיים.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי מדיניות: דחיית כל האפליקציות

השבתת השימוש ב-IPv6 חיצוני ב-VPC

האילוץ Disable VPC External IPv6 usage, כשמוגדר ל-True, מונע את ההגדרה של רשתות משנה ב-VPC עם כתובות IPv6 חיצוניות למכונות וירטואליות.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

השבתה של ברירת המחדל ליצירת רשתות

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

מגדירים את האילוץ Skip default network creation כדי להשבית את יצירת ה-VPC כברירת מחדל בפרויקטים חדשים. אם צריך, אפשר ליצור ידנית את רשת ברירת המחדל בפרויקט.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

עיצוב כללים לחומת האש

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

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

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

טווח העדיפות של כלל חומת האש
מטרה

0-999
שמור לתגובה לאירועים

1000-1999
תנועה שנחסמת תמיד

2000-1999999999
כללים ספציפיים לעומס עבודה

2000000000-2100000000
כללים כלליים

2100000001-2147483643
שמור

הגדרה של מדיניות חומת אש היררכית

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

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

  • שרת proxy לאימות זהויות (IAP) להעברת TCP. השימוש ב-IAP להעברת TCP מותר באמצעות מדיניות אבטחה שמאפשרת תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ ‎35.235.240.0/20 ליציאות TCP‏ 22 ו-3389.
  • בדיקות תקינות ב-Cloud Load Balancing. הטווחים המוכרים שמשמשים לבדיקות תקינות מותרים.
    • ברוב המקרים של Cloud Load Balancing (כולל איזון עומסים פנימי של TCP/UDP, איזון עומסים פנימי של HTTP(S), איזון עומסים חיצוני של שרת proxy של TCP, איזון עומסים חיצוני של שרת proxy של SSL ואיזון עומסים של HTTP(S)), מוגדרת מדיניות אבטחה שמאפשרת תנועת נתונים נכנסת מטווחי כתובות ה-IP‏ 35.191.0.0/16 ו-130.211.0.0/22 ליציאות 80 ו-443.
    • באיזון עומסים ברשת, מוגדרת מדיניות אבטחה שמאפשרת בדיקות תקינות מדור קודם על ידי מתן גישה לתעבורת נתונים נכנסת מטווח כתובות ה-IP‏ 35.191.0.0/16,‏ 209.85.152.0/22 ו-209.85.204.0/22 ליציאות 80 ו-443.

הגדרת סביבת VPC משותף

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

  1. יוצרים פרויקט חדש עבור ה-VPC המשותף. בהמשך התהליך, הפרויקט הזה הופך לפרויקט המארח ומכיל את הרשתות ואת משאבי הרשת שמשותפים עם פרויקטי השירות.
  2. מפעילים את Compute Engine API בפרויקט המארח.
  3. מגדירים VPC משותף לפרויקט.
  4. יוצרים את רשת ה-VPC במצב מותאם אישית בפרויקט המארח.
  5. יוצרים רשתות משנה באזור שבו מתכננים לפרוס עומסי עבודה. בכל רשת משנה, מפעילים גישה פרטית ל-Google כדי לאפשר למכונות וירטואליות ללא כתובות IP חיצוניות להגיע לשירותי Google.

הגדרת Cloud NAT

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

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

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

אתם יכולים להשתמש ב-Dedicated Interconnect, ב-Partner Interconnect או ב-Cloud VPN כדי לספק קישוריות היברידית לאזור הנחיתה. השלבים הבאים יוצרים את המשאבים הראשוניים של קישוריות היברידית שנדרשים לאפשרות התכנון הזו:

  1. אם אתם משתמשים ב-Dedicated Interconnect, אתם צריכים לבצע את הפעולות הבאות. אם אתם משתמשים ב-Partner Interconnect או ב-Cloud VPN, אתם יכולים לדלג על השלבים האלה.
    1. יוצרים פרויקט נפרד ליציאות הפיזיות של הקישוריות.
    2. מפעילים את Compute Engine API בפרויקט.
    3. יצירת חיבורי Dedicated Interconnect
  2. לכל אזור שבו מסיימים את הקישוריות ההיברידית ברשת ה-VPC, מבצעים את הפעולות הבאות:
    1. יוצרים שני קבצים מצורפים של VLAN ייעודיים או של שותף, אחד לכל אזור זמינות של קצה הרשת. במסגרת התהליך הזה, בוחרים ב-Cloud Routers ויוצרים סשנים של BGP.
    2. מגדירים את הנתבים של רשת ה-peer (באותו ארגון או בענן אחר).

הגדרת פרויקטים של עומסי עבודה

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

  1. יוצרים פרויקט חדש שישמש כאחד הפרויקטים של השירותים עבור ה-VPC המשותף.
  2. מפעילים את Compute Engine API בפרויקט השירות.
  3. צירוף הפרויקט לפרויקט המארח
  4. מגדירים גישה לכל תת-הרשתות בפרויקט המארח או לחלק מתת-הרשתות בפרויקט המארח.

הגדרת ניראות (observability)

‫Network Intelligence Center מספק דרך מגובשת לעקוב אחרי סביבת הרשת בענן, לפתור בעיות בה ולהציג אותה באופן ויזואלי. אפשר להשתמש בה כדי לוודא שהעיצוב פועל בהתאם לכוונת המשתמש.

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

השלבים הבאים

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

אפשרות 2: טופולוגיית Hub-and-spoke עם מכשירים מרכזיים

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

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

הגבלת גישה חיצונית באמצעות מדיניות ארגונית

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

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

הגבלת העברת פרוטוקולים על סמך סוג כתובת ה-IP

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

האילוץ Restrict Protocol Forwarding Based on type of IP Address מונע יצירה של כללי העברה עם כתובות IP חיצוניות בכל הארגון. בפרויקטים שיש להם הרשאה להשתמש בכללי העברה חיצוניים, אפשר לשנות את האילוץ ברמת התיקייה או הפרויקט.

כדי להגדיר את המגבלה הזו, צריך להגדיר את הערכים הבאים:

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי המדיניות: מותאם אישית
  • סוג המדיניות: דחייה
  • ערך בהתאמה אישית: IS:EXTERNAL

הגדרה של כתובות IP חיצוניות שאושרו למכונות וירטואליות

כברירת מחדל, מכונות וירטואליות יכולות לקבל כתובות IP חיצוניות, שמאפשרות קישוריות יוצאת ונכנסת לאינטרנט.

החלת האילוץ Define allowed external IPs for VM instances מונעת את השימוש בכתובות IP חיצוניות עם מופעי מכונות וירטואליות. עבור עומסי עבודה שנדרשות להם כתובות IP חיצוניות במכונות וירטואליות ספציפיות, צריך לשנות את האילוץ ברמת התיקייה או הפרויקט כדי לציין את המכונות הווירטואליות הספציפיות. או לבטל את האילוץ בפרויקטים הרלוונטיים.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי מדיניות: דחיית כל האפליקציות

השבתת השימוש ב-IPv6 חיצוני ב-VPC

האילוץ Disable VPC External IPv6 usage, כשמוגדר ל-True, מונע את ההגדרה של רשתות משנה ב-VPC עם כתובות IPv6 חיצוניות למכונות וירטואליות.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

השבתה של ברירת המחדל ליצירת רשתות

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

מגדירים את האילוץ Skip default network creation כדי להשבית את יצירת ה-VPC כברירת מחדל בפרויקטים חדשים. אם צריך, אפשר ליצור ידנית את רשת ברירת המחדל בפרויקט.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

עיצוב כללים לחומת האש

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

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

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

טווח העדיפות של כלל חומת האש
מטרה

0-999
שמור לתגובה לאירועים

1000-1999
תנועה שנחסמת תמיד

2000-1999999999
כללים ספציפיים לעומס עבודה

2000000000-2100000000
כללים כלליים

2100000001-2147483643
שמור

הגדרה של מדיניות חומת אש היררכית

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

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

  • שרת proxy לאימות זהויות (IAP) להעברת TCP. השימוש ב-IAP להעברת TCP מותר באמצעות מדיניות אבטחה שמאפשרת תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ ‎35.235.240.0/20 ליציאות TCP‏ 22 ו-3389.
  • בדיקות תקינות ב-Cloud Load Balancing. הטווחים המוכרים שמשמשים לבדיקות תקינות מותרים.
    • ברוב המקרים של Cloud Load Balancing (כולל איזון עומסים פנימי של TCP/UDP, איזון עומסים פנימי של HTTP(S), איזון עומסים חיצוני של שרת proxy של TCP, איזון עומסים חיצוני של שרת proxy של SSL ואיזון עומסים של HTTP(S)), מוגדרת מדיניות אבטחה שמאפשרת תנועת נתונים נכנסת מטווחי כתובות ה-IP‏ 35.191.0.0/16 ו-130.211.0.0/22 ליציאות 80 ו-443.
    • באיזון עומסים ברשת, מוגדרת מדיניות אבטחה שמאפשרת בדיקות תקינות מדור קודם על ידי מתן גישה לתעבורת נתונים נכנסת מטווח כתובות ה-IP‏ 35.191.0.0/16,‏ 209.85.152.0/22 ו-209.85.204.0/22 ליציאות 80 ו-443.

הגדרת סביבת ה-VPC

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

  1. יוצרים פרויקט חדש לרשתות ה-VPC של המרכז והרשתות המקשרות. שתי רשתות ה-VPC הן חלק מאותו פרויקט כדי לתמוך בקישוריות דרך מכשירי הרשת הווירטואלית.
  2. מפעילים את Compute Engine API בפרויקט.
  3. יוצרים את רשת ה-VPC במצב מותאם אישית של רשת מעבר.
  4. ברשת ה-VPC של המעבר, יוצרים תת-רשת באזורים שבהם מתכננים לפרוס את מכשירי הרשת הווירטואלית.
  5. יוצרים רשת VPC במצב מותאם אישית של רכזת.
  6. ברשת ה-VPC של הרכזת, יוצרים רשת משנה באזורים שבהם מתכננים לפרוס את מכשירי הרשת הווירטואלית.
  7. מגדירים כללי מדיניות גלובליים או אזוריים של חומת אש ברשת כדי לאפשר תעבורת נתונים נכנסת ויוצאת למכשירי הרשת הווירטואליים.
  8. יוצרים קבוצה של מופעי מכונה מנוהלים עבור מכשירי הרשת הווירטואלית.
  9. מגדירים את משאבי איזון העומסים הפנימיים מסוג TCP/UDP עבור ה-VPC המעברי. מאזן העומסים הזה משמש לניתוב תעבורה מ-VPC של מעבר ל-VPC מרכזי דרך מכשירי הרשת הווירטואלית.
  10. מגדירים את משאבי איזון העומסים הפנימיים מסוג TCP/UDP עבור רשת ה-VPC המרכזית. מאזן העומסים הזה משמש לניתוב תנועה מ-VPC מרכזי ל-VPC למעבר דרך מכשירי רשת וירטואלית.
  11. מגדירים Private Service Connect ל-Google APIs לרשת ה-VPC המרכזית.
  12. משנים את המסלולים של ה-VPC כדי לשלוח את כל התנועה דרך המכשירים הווירטואליים ברשת:
    1. מוחקים את המסלול 0.0.0.0/0 עם ה-next-hop default-internet-gateway מרשת ה-VPC של ה-hub.
    2. מגדירים נתיב חדש עם יעד 0.0.0.0/0 וקפיצה הבאה של כלל ההעברה למאזן העומסים ברשת ה-VPC של הרכזת.

הגדרת Cloud NAT

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

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

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

אתם יכולים להשתמש ב-Dedicated Interconnect, ב-Partner Interconnect או ב-Cloud VPN כדי לספק קישוריות היברידית לאזור הנחיתה. השלבים הבאים יוצרים את המשאבים הראשוניים של קישוריות היברידית שנדרשים לאפשרות התכנון הזו:

  1. אם אתם משתמשים ב-Dedicated Interconnect, אתם צריכים לבצע את הפעולות הבאות. אם אתם משתמשים ב-Partner Interconnect או ב-Cloud VPN, אתם יכולים לדלג על השלבים האלה.
    1. יוצרים פרויקט נפרד ליציאות הפיזיות של הקישוריות.
    2. מפעילים את Compute Engine API בפרויקט.
    3. יצירת חיבורי Dedicated Interconnect
  2. לכל אזור שבו מסיימים את הקישוריות ההיברידית ברשת ה-VPC, מבצעים את הפעולות הבאות:
    1. יוצרים שני קבצים מצורפים של VLAN ייעודיים או של שותף, אחד לכל אזור זמינות של קצה הרשת. במסגרת התהליך הזה, בוחרים ב-Cloud Routers ויוצרים סשנים של BGP.
    2. מגדירים את הנתבים של רשת ה-peer (באותו ארגון או בענן אחר).
    3. מגדירים נתיבים מותאמים אישית שמוכרזים ב-Cloud Routers לטווחי תת-הרשתות ברשתות ה-VPC של הרכזת ועומס העבודה.

הגדרת פרויקטים של עומסי עבודה

יוצרים רשת VPC מסוג Spoke נפרדת לכל עומס עבודה:

  1. יוצרים פרויקט חדש לאירוח עומס העבודה.
  2. מפעילים את Compute Engine API בפרויקט.
  3. מגדירים קישור בין רשתות VPC שכנות (peering) בין רשת ה-VPC של מרכז הבקרה לבין רשת ה-VPC של עומס העבודה עם ההגדרות הבאות:
    • מפעילים ייצוא של נתיבים מותאמים אישית ב-VPC של ה-hub.
    • מפעילים ייבוא של נתיבים מותאמים אישית ב-VPC של עומס העבודה.
  4. יוצרים רשתות משנה באזורים שבהם מתכננים לפרוס עומסי עבודה. בכל רשת משנה, מפעילים גישה פרטית ל-Google כדי לאפשר למכונות וירטואליות (VM) עם כתובות IP פנימיות בלבד להגיע לשירותי Google.
  5. הגדרת Private Service Connect ל-Google APIs
  6. כדי לנתב את כל התעבורה דרך מכשירי הרשת הווירטואלית ברשת ה-VPC המרכזית, מוחקים את המסלול 0.0.0.0/0 עם הניתוב הבא default-internet-gateway מרשת ה-VPC של עומס העבודה.
  7. מגדירים מדיניות גלובלית או אזורית של חומת אש ברשת כדי לאפשר תעבורת נתונים נכנסת ויוצאת לעומס העבודה.

הגדרת ניראות (observability)

‫Network Intelligence Center מספק דרך מגובשת לעקוב אחרי סביבת הרשת בענן, לפתור בעיות בה ולהציג אותה באופן ויזואלי. אפשר להשתמש בה כדי לוודא שהעיצוב פועל בהתאם לכוונת המשתמש.

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

השלבים הבאים

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

אפשרות 3: טופולוגיית Hub-and-spoke בלי מכשירים

אם בחרתם ליצור טופולוגיית hub-and-spoke ללא מכשירים בקטע 'החלטה על עיצוב הרשת לאזור הנחיתה Google Cloud ', צריך לפעול לפי השלבים הבאים.

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

הגבלת גישה חיצונית באמצעות מדיניות ארגונית

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

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

הגבלת העברת פרוטוקולים על סמך סוג כתובת ה-IP

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

האילוץ Restrict Protocol Forwarding Based on type of IP Address מונע יצירה של כללי העברה עם כתובות IP חיצוניות בכל הארגון. בפרויקטים שיש להם הרשאה להשתמש בכללי העברה חיצוניים, אפשר לשנות את האילוץ ברמת התיקייה או הפרויקט.

כדי להגדיר את המגבלה הזו, צריך להגדיר את הערכים הבאים:

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי המדיניות: מותאם אישית
  • סוג המדיניות: דחייה
  • ערך בהתאמה אישית: IS:EXTERNAL

הגדרה של כתובות IP חיצוניות שאושרו למכונות וירטואליות

כברירת מחדל, מכונות וירטואליות יכולות לקבל כתובות IP חיצוניות, שמאפשרות קישוריות יוצאת ונכנסת לאינטרנט.

החלת האילוץ Define allowed external IPs for VM instances מונעת את השימוש בכתובות IP חיצוניות עם מופעי מכונות וירטואליות. עבור עומסי עבודה שנדרשות להם כתובות IP חיצוניות במכונות וירטואליות ספציפיות, צריך לשנות את האילוץ ברמת התיקייה או הפרויקט כדי לציין את המכונות הווירטואליות הספציפיות. או לבטל את האילוץ בפרויקטים הרלוונטיים.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי מדיניות: דחיית כל האפליקציות

השבתת השימוש ב-IPv6 חיצוני ב-VPC

האילוץ Disable VPC External IPv6 usage, כשמוגדר ל-True, מונע את ההגדרה של רשתות משנה ב-VPC עם כתובות IPv6 חיצוניות למכונות וירטואליות.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

השבתה של ברירת המחדל ליצירת רשתות

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

מגדירים את האילוץ Skip default network creation כדי להשבית את יצירת ה-VPC כברירת מחדל בפרויקטים חדשים. אם צריך, אפשר ליצור ידנית את רשת ברירת המחדל בפרויקט.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

עיצוב כללים לחומת האש

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

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

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

טווח העדיפות של כלל חומת האש
מטרה

0-999
שמור לתגובה לאירועים

1000-1999
תנועה שנחסמת תמיד

2000-1999999999
כללים ספציפיים לעומס עבודה

2000000000-2100000000
כללים כלליים

2100000001-2147483643
שמור

הגדרה של מדיניות חומת אש היררכית

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

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

  • שרת proxy לאימות זהויות (IAP) להעברת TCP. השימוש ב-IAP להעברת TCP מותר באמצעות מדיניות אבטחה שמאפשרת תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ ‎35.235.240.0/20 ליציאות TCP‏ 22 ו-3389.
  • בדיקות תקינות ב-Cloud Load Balancing. הטווחים המוכרים שמשמשים לבדיקות תקינות מותרים.
    • ברוב המקרים של Cloud Load Balancing (כולל איזון עומסים פנימי של TCP/UDP, איזון עומסים פנימי של HTTP(S), איזון עומסים חיצוני של שרת proxy של TCP, איזון עומסים חיצוני של שרת proxy של SSL ואיזון עומסים של HTTP(S)), מוגדרת מדיניות אבטחה שמאפשרת תנועת נתונים נכנסת מטווחי כתובות ה-IP‏ 35.191.0.0/16 ו-130.211.0.0/22 ליציאות 80 ו-443.
    • במקרה של איזון עומסים ברשת, מוגדרת מדיניות אבטחה שמאפשרת בדיקות תקינות מדור קודם על ידי מתן גישה לתעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ 35.191.0.0/16,‏ 209.85.152.0/22 ו-209.85.204.0/22 ליציאות 80 ו-443.

הגדרת סביבת ה-VPC של ה-hub

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

  1. יוצרים פרויקט חדש לרשת ה-VPC של הרכזת.
  2. מפעילים את Compute Engine API בפרויקט.
  3. יוצרים את הרכזת רשת VPC במצב בהתאמה אישית.
  4. מגדירים Private Service Connect ל-Google APIs לרשת ה-VPC המרכזית.

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

אתם יכולים להשתמש ב-Dedicated Interconnect, ב-Partner Interconnect או ב-Cloud VPN כדי לספק קישוריות היברידית לאזור הנחיתה. השלבים הבאים יוצרים את המשאבים הראשוניים של קישוריות היברידית שנדרשים לאפשרות התכנון הזו:

  1. אם אתם משתמשים ב-Dedicated Interconnect, אתם צריכים לבצע את הפעולות הבאות. אם אתם משתמשים ב-Partner Interconnect או ב-Cloud VPN, אתם יכולים לדלג על השלבים האלה.
    1. יוצרים פרויקט נפרד ליציאות הפיזיות של הקישוריות.
    2. מפעילים את Compute Engine API בפרויקט.
    3. יצירת חיבורי Dedicated Interconnect
  2. לכל אזור שבו מסיימים את הקישוריות ההיברידית ברשת ה-VPC, מבצעים את הפעולות הבאות:
    1. יוצרים שני קבצים מצורפים של VLAN ייעודיים או של שותף, אחד לכל אזור זמינות של קצה הרשת. במסגרת התהליך הזה, בוחרים ב-Cloud Routers ויוצרים סשנים של BGP.
    2. מגדירים את הנתבים של רשת ה-peer (באותו ארגון או בענן אחר).
    3. מגדירים נתיבים מותאמים אישית שמוכרזים ב-Cloud Routers לטווחי תת-הרשתות ברשתות ה-VPC של הרכזת ועומס העבודה.

הגדרת פרויקטים של עומסי עבודה

יוצרים רשת VPC מסוג Spoke נפרדת לכל עומס עבודה:

  1. יוצרים פרויקט חדש לאירוח עומס העבודה.
  2. מפעילים את Compute Engine API בפרויקט.
  3. מגדירים קישור בין רשתות VPC שכנות (peering) בין רשת ה-VPC של עומס העבודה לבין רשת ה-VPC המרכזית, עם ההגדרות הבאות:
    • מפעילים ייצוא של נתיבים מותאמים אישית ב-VPC של ה-hub.
    • מפעילים ייבוא של נתיבים מותאמים אישית ב-VPC של עומס העבודה.
  4. יוצרים רשתות משנה באזורים שבהם מתכננים לפרוס עומסי עבודה. בכל רשת משנה, מפעילים גישה פרטית ל-Google כדי לאפשר למכונות וירטואליות (VM) עם כתובות IP פנימיות בלבד להגיע לשירותי Google.
  5. הגדרת Private Service Connect ל-Google APIs

הגדרת Cloud NAT

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

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

הגדרת ניראות (observability)

‫Network Intelligence Center מספק דרך מגובשת לעקוב אחרי סביבת הרשת בענן, לפתור בעיות בה ולהציג אותה באופן ויזואלי. אפשר להשתמש בה כדי לוודא שהעיצוב פועל בהתאם לכוונת המשתמש.

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

השלבים הבאים

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

אפשרות יצירה 4: חשיפת שירותים במודל צרכן-ספק באמצעות Private Service Connect

אם בחרתם לחשוף שירותים במודל צרכן-יצרן באמצעות Private Service Connect לאזור הנחיתה שלכם, כמו שמתואר במאמר בנושא בחירת עיצוב הרשת לאזור הנחיתהGoogle Cloud , אתם צריכים לפעול לפי השלבים הבאים.

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

הגבלת גישה חיצונית באמצעות מדיניות ארגונית

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

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

הגבלת העברת פרוטוקולים על סמך סוג כתובת ה-IP

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

האילוץ Restrict Protocol Forwarding Based on type of IP Address מונע יצירה של כללי העברה עם כתובות IP חיצוניות בכל הארגון. בפרויקטים שיש להם הרשאה להשתמש בכללי העברה חיצוניים, אפשר לשנות את האילוץ ברמת התיקייה או הפרויקט.

כדי להגדיר את המגבלה הזו, צריך להגדיר את הערכים הבאים:

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי המדיניות: מותאם אישית
  • סוג המדיניות: דחייה
  • ערך בהתאמה אישית: IS:EXTERNAL

הגדרה של כתובות IP חיצוניות שאושרו למכונות וירטואליות

כברירת מחדל, מכונות וירטואליות יכולות לקבל כתובות IP חיצוניות, שמאפשרות קישוריות יוצאת ונכנסת לאינטרנט.

החלת האילוץ Define allowed external IPs for VM instances מונעת את השימוש בכתובות IP חיצוניות עם מופעי מכונות וירטואליות. עבור עומסי עבודה שנדרשות להם כתובות IP חיצוניות במכונות וירטואליות ספציפיות, צריך לשנות את האילוץ ברמת התיקייה או הפרויקט כדי לציין את המכונות הווירטואליות הספציפיות. או לבטל את האילוץ בפרויקטים הרלוונטיים.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפת המדיניות: החלפה
  • ערכי מדיניות: דחיית כל האפליקציות

השבתת השימוש ב-IPv6 חיצוני ב-VPC

האילוץ Disable VPC External IPv6 usage, כשמוגדר ל-True, מונע את ההגדרה של רשתות משנה ב-VPC עם כתובות IPv6 חיצוניות למכונות וירטואליות.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

השבתה של ברירת המחדל ליצירת רשתות

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

מגדירים את האילוץ Skip default network creation כדי להשבית את יצירת ה-VPC כברירת מחדל בפרויקטים חדשים. אם צריך, אפשר ליצור ידנית את רשת ברירת המחדל בפרויקט.

  • איפה הכלל מיושם? התאמה אישית
  • אכיפה: מופעלת

עיצוב כללים לחומת האש

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

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

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

טווח העדיפות של כלל חומת האש
מטרה

0-999
שמור לתגובה לאירועים

1000-1999
תנועה שנחסמת תמיד

2000-1999999999
כללים ספציפיים לעומס עבודה

2000000000-2100000000
כללים כלליים

2100000001-2147483643
שמור

הגדרה של מדיניות חומת אש היררכית

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

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

  • שרת proxy לאימות זהויות (IAP) להעברת TCP. השימוש ב-IAP להעברת TCP מותר באמצעות מדיניות אבטחה שמאפשרת תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ ‎35.235.240.0/20 ליציאות TCP‏ 22 ו-3389.
  • בדיקות תקינות ב-Cloud Load Balancing. הטווחים המוכרים שמשמשים לבדיקות תקינות מותרים.
    • ברוב המקרים של Cloud Load Balancing (כולל איזון עומסים פנימי של TCP/UDP, איזון עומסים פנימי של HTTP(S), איזון עומסים חיצוני של שרת proxy של TCP, איזון עומסים חיצוני של שרת proxy של SSL ואיזון עומסים של HTTP(S)), מוגדרת מדיניות אבטחה שמאפשרת תנועת נתונים נכנסת מטווחי כתובות ה-IP‏ 35.191.0.0/16 ו-130.211.0.0/22 ליציאות 80 ו-443.
    • במקרה של איזון עומסים ברשת, מוגדרת מדיניות אבטחה שמאפשרת בדיקות תקינות מדור קודם על ידי מתן גישה לתעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ 35.191.0.0/16,‏ 209.85.152.0/22 ו-209.85.204.0/22 ליציאות 80 ו-443.

הגדרת סביבת ה-VPC

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

  1. יוצרים פרויקט חדש לרשת ה-VPC המרכזית.
  2. מפעילים את Compute Engine API בפרויקט.
  3. יוצרים את רשת ה-VPC במצב מותאם אישית למעבר.
  4. יוצרים תת-רשת של Private Service Connect בכל אזור שבו מתכננים לפרסם שירותים שפועלים ב-VPC המרכזי או בסביבה המקומית. כשמחליטים על תוכנית הקצאת כתובות IP, כדאי לקחת בחשבון את גודל רשת המשנה של Private Service Connect.
  5. לכל שירות מקומי שרוצים לחשוף לעומסי עבודה שפועלים ב-Google Cloud, יוצרים מאזן עומסים פנימי מסוג HTTP(S) או שרת proxy של TCP וחושפים את השירותים באמצעות Private Service Connect.
  6. מגדירים Private Service Connect ל-Google APIs ל-VPC של המעבר.

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

אתם יכולים להשתמש ב-Dedicated Interconnect, ב-Partner Interconnect או ב-Cloud VPN כדי לספק קישוריות היברידית לאזור הנחיתה. השלבים הבאים יוצרים את המשאבים הראשוניים של קישוריות היברידית שנדרשים לאפשרות התכנון הזו:

  1. אם אתם משתמשים ב-Dedicated Interconnect, אתם צריכים לבצע את הפעולות הבאות. אם אתם משתמשים ב-Partner Interconnect או ב-Cloud VPN, אתם יכולים לדלג על השלבים האלה.
    1. יוצרים פרויקט נפרד ליציאות הפיזיות של הקישוריות.
    2. מפעילים את Compute Engine API בפרויקט.
    3. יצירת חיבורי Dedicated Interconnect
  2. לכל אזור שבו מסיימים את הקישוריות ההיברידית ברשת ה-VPC, מבצעים את הפעולות הבאות:
    1. יוצרים שני קבצים מצורפים של VLAN ייעודיים או של שותף, אחד לכל אזור זמינות של קצה הרשת. במסגרת התהליך הזה, בוחרים ב-Cloud Routers ויוצרים סשנים של BGP.
    2. מגדירים את הנתבים של רשת ה-peer (באותו ארגון או בענן אחר).

הגדרת פרויקטים של עומסי עבודה

ליצור VPC נפרד לכל עומס עבודה:

  1. יוצרים פרויקט חדש לאירוח עומס העבודה.
  2. מפעילים את Compute Engine API בפרויקט.
  3. יוצרים רשת VPC במצב מותאם אישית.
  4. יוצרים רשתות משנה באזורים שבהם מתכננים לפרוס עומסי עבודה. בכל רשת משנה, מפעילים גישה פרטית ל-Google כדי לאפשר למכונות וירטואליות (VM) עם כתובות IP פנימיות בלבד להגיע לשירותי Google.
  5. הגדרת Private Service Connect ל-Google APIs
  6. לכל עומס עבודה שאתם צורכים מ-VPC אחר או מהסביבה המקומית שלכם, צריך ליצור נקודת קצה (endpoint) של צרכן Private Service Connect.
  7. לכל עומס עבודה שאתם יוצרים עבור VPC אחר או עבור סביבה מקומית, צריך ליצור מאזן עומסים פנימי וחיבור שירות לשירות. כשמחליטים על תוכנית הקצאת כתובות IP, כדאי לקחת בחשבון את גודל רשת המשנה של Private Service Connect.
  8. אם רוצים שהשירות יהיה נגיש מהסביבה המקומית, צריך ליצור נקודת קצה (endpoint) של צרכן Private Service Connect ב-VPC המעבר.

הגדרת Cloud NAT

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

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

הגדרת ניראות (observability)

‫Network Intelligence Center מספק דרך מגובשת לעקוב אחרי סביבת הרשת בענן, לפתור בעיות בה ולהציג אותה באופן ויזואלי. אפשר להשתמש בה כדי לוודא שהעיצוב פועל בהתאם לכוונת המשתמש.

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

השלבים הבאים

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

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