נדרשת רשת כדי שהמשאבים יוכלו לתקשר בתוך הארגון שלכם Google Cloud ובענן וגם בסביבה המקומית. בקטע הזה מתוארת המבנה בתוכנית ה-blueprint של רשתות VPC, מרחב כתובות IP, DNS, כללי מדיניות של חומת אש וקישוריות לסביבה המקומית.
הטופולוגיה של הרשת
מאגר התוכניות מספק את האפשרויות הבאות לטופולוגיה של הרשת:
- שימוש ברשתות VPC משותפות נפרדות לכל סביבה, בלי לאפשר תעבורת נתונים ישירות בין הסביבות.
- משתמשים במודל hub-and-spoke שמוסיף רשת hub כדי לחבר כל סביבה ב- Google Cloud, כאשר התנועה ברשת בין הסביבות מוגבלת על ידי מכשיר וירטואלי ברשת (NVA).
בוחרים באפשרות רשת VPC משותפת לכל טופולוגיית סביבה כשלא רוצים קישוריות רשת ישירה בין סביבות. בוחרים בטופולוגיית רשת מסוג hub-and-spoke כשרוצים לאפשר קישוריות בין סביבות שמסוננות על ידי NVA, למשל כשמסתמכים על כלים קיימים שדורשים נתיב רשת ישיר לכל שרת בסביבה.
שתי הטופולוגיות משתמשות ב-VPC משותף כבסיס לבניית הרשת, כי הוא מאפשר הפרדה ברורה בין תחומי האחריות. אדמינים של רשתות מנהלים משאבי רשת בפרויקט מארח מרכזי, וצוותים של עומסי עבודה פורסים משאבי אפליקציות משלהם ומשתמשים במשאבי הרשת בפרויקטים של שירות שמצורפים לפרויקט המארח.
רשת VPC משותפת לכל טופולוגיית סביבה
אם אתם צריכים בידוד רשת בין רשתות הפיתוח, הסביבה ללא ייצור והייצור ב- Google Cloud, מומלץ להשתמש ברשת VPC משותפת לכל טופולוגיית סביבה. הטופולוגיה הזו לא מאפשרת תעבורת רשת בין סביבות.
הדיאגרמה הבאה מציגה את רשת ה-VPC המשותפת לכל טופולוגיית סביבה.
בתרשים מתוארים מושגי המפתח הבאים של VPC משותף לכל טופולוגיית סביבה:
- לכל סביבה (ייצור, לא ייצור ופיתוח) יש רשת VPC משותפת אחת. בתרשים הזה מוצגת רק סביבת הייצור, אבל אותו דפוס חוזר על עצמו בכל סביבה.
- לכל רשת VPC משותפת יש שתי תת-רשתות, וכל תת-רשת נמצאת באזור אחר.
- הקישוריות למשאבים מקומיים מופעלת באמצעות ארבעה קבצים מצורפים של VLAN למופע Dedicated Interconnect לכל רשת VPC משותפת, באמצעות ארבעה שירותי Cloud Router (שניים בכל אזור לצורך יתירות). מידע נוסף זמין במאמר בנושא קישוריות היברידית בין סביבה מקומית לבין Google Cloud.
הטופולוגיה הזו לא מאפשרת לתנועה ברשת לזרום ישירות בין הסביבות. אם אתם צריכים שתנועת הרשת תזרום ישירות בין הסביבות, אתם צריכים לבצע פעולות נוספות כדי לאפשר את נתיב הרשת הזה. לדוגמה, אתם יכולים להגדיר נקודות קצה של Private Service Connect כדי לחשוף שירות מרשת VPC אחת לרשת VPC אחרת. אפשרות אחרת היא להגדיר את הרשת המקומית כך שתאפשר תנועה מסביבתGoogle Cloud אחת לסביבה המקומית ואז לסביבת Google Cloud אחרת.
טופולוגיית רשת מסוג Hub-and-spoke
אם אתם פורסים משאבים Google Cloud שדורשים נתיב רשת ישיר למשאבים בכמה סביבות, מומלץ להשתמש בטופולוגיית רשת מסוג hub-and-spoke.
טופולוגיית ה-hub-and-spoke משתמשת בכמה מהמושגים שקשורים לרשת VPC משותפת לכל טופולוגיית סביבה, אבל משנה את הטופולוגיה כדי להוסיף רשת hub. התרשים הבא מציג את טופולוגיית ה-hub-and-spoke.
בתרשים מוסברים המושגים המרכזיים האלה של טופולוגיית רשת מסוג Hub-and-Spoke:
- במודל הזה יש רשת מרכזית, וכל אחת מהרשתות לפיתוח, לא לייצור ולייצור (spokes) מחוברת לרשת המרכזית באמצעות קישור בין רשתות VPC שכנות. לחלופין, אם אתם צופים שתחרגו ממגבלת המכסה, תוכלו להשתמש במקום זאת בשער HA VPN.
- הקישוריות לרשתות מקומיות מותרת רק דרך רשת ה-hub. כל הרשתות המקושרות יכולות לתקשר עם משאבים משותפים ברשת המרכזית ולהשתמש בנתיב הזה כדי להתחבר לרשתות מקומיות.
- רשתות ה-Hub כוללות NVA לכל אזור, שמוצבים בצורה מיותרת מאחורי מופעים פנימיים של מאזן עומסי רשת. ה-NVA משמש כשער שמאפשר או חוסם תנועה בין רשתות מסוג Spoke.
- רשת ה-hub מארחת גם כלים שנדרש חיבור לכל הרשתות האחרות כדי להשתמש בהם. לדוגמה, אפשר לפרוס כלים במכונות וירטואליות לניהול הגדרות בסביבה המשותפת.
כדי לאפשר תעבורת נתונים בין רשתות spoke, התוכנית פורסת מכשירי NVA ברשת ה-VPC המשותפת של הרכזת, שפועלים כשערים בין הרשתות. הנתיבים מועברים מרשתות VPC מסוג Hub לרשתות VPC מסוג Spoke באמצעות העברת נתיבים מותאמים אישית. בתרחיש הזה, הקישוריות בין הרשתות המרכזיות חייבת להיות מנותבת דרך ה-NVA, כי הקישור בין רשתות VPC שכנות הוא לא טרנזיטיבי, ולכן רשתות ה-VPC המרכזיות לא יכולות להחליף נתונים ביניהן ישירות. צריך להגדיר את המכשירים הווירטואליים כך שיאפשרו תעבורה בין רשתות ה-spoke באופן סלקטיבי.
דפוסי פריסה של פרויקטים
כשיוצרים פרויקטים חדשים לעומסי עבודה, צריך להחליט איך המשאבים בפרויקט הזה יתחברו לרשת הקיימת. בטבלה הבאה מפורטים דפוסי הפריסה של הפרויקטים שמשמשים בתוכנית הפריסה.
| דוגמת קוד | תיאור | דוגמאות לשימוש |
|---|---|---|
| פרויקטים של שירות VPC משותף | הפרויקטים האלה מוגדרים כפרויקטים של שירותים בפרויקט מארח של VPC משותף. משתמשים בתבנית הזו כשהמשאבים בפרויקט עומדים בקריטריונים הבאים:
|
example_shared_vpc_project.tf |
| פרויקטים צפים | פרויקטים צפים לא מחוברים לרשתות VPC אחרות בטופולוגיה שלכם. משתמשים בתבנית הזו כשהמשאבים בפרויקט עומדים בקריטריונים הבאים:
יכול להיות שתרצו להפריד את רשת ה-VPC של פרויקט זמני מטופולוגיית רשת ה-VPC הראשית, אבל גם לחשוף מספר מוגבל של נקודות קצה בין הרשתות. במקרה כזה, מפרסמים שירותים באמצעות Private Service Connect כדי לשתף גישה לרשת לנקודת קצה ספציפית ברשתות VPC בלי לחשוף את הרשת כולה. |
example_floating_project.tf |
| פרויקטים של קישור בין רשתות שכנות (peering) | פרויקטים של קישור בין רשתות שכנות (peering) יוצרים רשתות VPC משלהם ומקשרים אותן לרשתות VPC אחרות בטופולוגיה שלכם. משתמשים בתבנית הזו כשהמשאבים בפרויקט עומדים בקריטריונים הבאים:
אם יוצרים פרויקטים של שותפות, האחריות היא שלכם להקצות טווחי כתובות IP שלא מתנגשים ולתכנן את הקצאה לקבוצת שותפות. |
example_peering_project.tf |
הקצאת כתובות IP
בקטע הזה מוסבר איך ארכיטקטורת התוכנית מחלקת טווחי כתובות IP. יכול להיות שתצטרכו לשנות את טווחי כתובות ה-IP הספציפיים שבהם נעשה שימוש על סמך הזמינות של כתובות ה-IP בסביבה ההיברידית הקיימת.
בטבלה הבאה מפורט מרחב כתובות ה-IP שהוקצה לתוכנית. סביבת ה-Hub רלוונטית רק לטופולוגיית Hub-and-Spoke.
| מטרה | אזור | סביבת Hub | סביבת פיתוח | סביבה שאינה סביבת ייצור | סביבת ייצור |
|---|---|---|---|---|---|
| טווחים של רשתות משנה ראשיות | אזור 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 |
| אזור 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | |
| לא מוקצה | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | |
| גישה לשירותים פרטיים | עולמי | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 |
| נקודות קצה של Private Service Connect | עולמי | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 |
| תת-רשתות של שרתי proxy בלבד | אזור 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 |
| אזור 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | |
| לא הוקצה | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | |
| טווחים של רשתות משנה משניות | אזור 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 |
| אזור 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | |
| לא הוקצה | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
בטבלה שלמעלה מוצגים המושגים האלה לגבי הקצאת טווחי כתובות IP:
- הקצאת כתובות IP מחולקת לטווחים לכל שילוב של מטרה, אזור וסביבה.
- חלק מהמשאבים הם גלובליים ולא נדרשים חלוקות משנה לכל אזור.
- כברירת מחדל, כשמדובר במשאבים אזוריים, תוכנית ה-Blueprint נפרסת בשני אזורים. בנוסף, יש טווחי כתובות IP שלא נמצאים בשימוש, כך שאפשר להרחיב את הפעילות לשישה אזורים נוספים.
- רשת ה-hub משמשת רק בטופולוגיית רשת מסוג hub-and-spoke, בעוד שסביבות הפיתוח, הסביבות שאינן סביבות ייצור וסביבות הייצור משמשות בשתי טופולוגיות הרשת.
בטבלה הבאה מוסבר איך משתמשים בכל סוג של טווח כתובות IP.
| מטרה | תיאור |
|---|---|
| טווחים של רשתות משנה ראשיות | משאבים שפורסים ברשת ה-VPC, כמו מכונות וירטואליות, משתמשים בכתובות IP פנימיות מהטווחים האלה. |
| גישה לשירותים פרטיים | בשירותים מסוימים Google Cloud , כמו Cloud SQL, צריך להקצות מראש טווח של כתובות ברשת משנה לגישה לשירותים פרטיים. התוכנית מגדירה טווח של /21 באופן גלובלי לכל אחת מרשתות ה-VPC המשותפות, כדי להקצות כתובות IP לשירותים שנדרשת להם גישה לשירותים פרטיים. כשיוצרים שירות שתלוי בגישה לשירותים פרטיים, מקצים רשת משנה אזורית מסוג /24 מתוך טווח /21 השמור. |
| התחברות לשירות פרטי | תוכנית ה-blueprint מספקת לכל רשת VPC נקודת קצה (endpoint) של Private Service Connect כדי לתקשר עם Google Cloud APIs. נקודת הקצה הזו מאפשרת למשאבים ברשת ה-VPC להגיע לממשקי Google Cloud API בלי להסתמך על תנועה יוצאת לאינטרנט או על טווחי אינטרנט שפורסמו לציבור. |
| מאזני עומסים מבוססי-proxy | בסוגים מסוימים של מאזני עומסים של אפליקציות (ALB) צריך להקצות מראש תת-רשתות של שרת proxy בלבד. למרות שהתוכנית לא פורסת מאזני עומסים של אפליקציות שדורשים את הטווח הזה, הקצאת טווחים מראש עוזרת לצמצם את החיכוך בעומסי עבודה כשהם צריכים לבקש טווח חדש של רשתות משנה כדי להפעיל משאבים מסוימים של מאזן עומסים. |
| טווחים של רשתות משנה משניות | במקרים מסוימים, כמו עומסי עבודה מבוססי-קונטיינרים, נדרשים טווחים משניים. למרות שהתוכנית לא פורסת שירותים שדורשים טווחים משניים, היא מקצה טווחים ממרחב כתובות ה-IP של RFC 6598 לטווחים משניים. לחלופין, אם קשה לכם להקצות בלוקים גדולים מספיק של CIDR לשירותים האלה, אתם יכולים לשקול לפרוס את השירותים האלה בדפוס הפרויקט הצף שמוצג בקטע דפוסי פריסה של פרויקטים. |
הגדרה מרכזית של DNS
לרזולוציית DNS בין סביבות Google Cloud לבין סביבות מקומיות, מומלץ להשתמש בגישה היברידית עם שתי מערכות DNS סמכותיות. בגישה הזו, Cloud DNS מטפל בפענוח DNS סמכותי עבור סביבתGoogle Cloud שלכם, ושרתי ה-DNS הקיימים שלכם בפריסה מקומית מטפלים בפענוח DNS סמכותי עבור משאבים בפריסה מקומית. הסביבה המקומית שלכם והסביבה של Google Cloud מבצעות בדיקות DNS בין סביבות באמצעות בקשות להעברה.
בתרשים הבא מוצגת טופולוגיית ה-DNS בכמה רשתות VPC שנעשה בהן שימוש בתוכנית הפעולה.
הדיאגרמה מתארת את הרכיבים הבאים של עיצוב ה-DNS שנפרס על ידי תוכנית ה-Blueprint:
- מרכז ה-DNS הוא הנקודה המרכזית של חילופי DNS בין הסביבה המקומית לבין סביבת Google Cloud. הכוונה של DNS משתמשת באותם מופעים של Dedicated Interconnect ו-Cloud Routers שכבר הוגדרו בטופולוגיית הרשת שלכם.
- ברשת ה-VPC המשותפת של כל טופולוגיית סביבה, פרויקט ה-DNS זהה לפרויקט המארח של ה-VPC המשותף של סביבת הייצור.
- בטופולוגיית רכזת וחישורים, פרויקט רכזת ה-DNS זהה לפרויקט המארח של ה-VPC המשותף של הרכזת.
- שרתים בכל רשת VPC משותפת יכולים לפתור רשומות DNS מרשתות אחרות של VPC משותף באמצעות העברת DNS, שמוגדרת בין Cloud DNS בכל פרויקט מארח של VPC משותף לבין מרכז ה-DNS.
- שרתים מקומיים יכולים לפענח רשומות DNS בסביבות Google Cloud באמצעות מדיניות שרתי DNS שמאפשרת שאילתות משרתים מקומיים. תוכנית האב מגדירה מדיניות שרתים נכנסת במרכז ה-DNS כדי להקצות כתובות IP, ושרתי ה-DNS המקומיים מעבירים בקשות לכתובות האלה. כל בקשות ה-DNS מגיעות קודם למרכז ה-DNS, שפותר רשומות משרתי DNS עמיתים. Google Cloud
- שרתים ב- Google Cloud יכולים לפענח רשומות DNS בסביבה המקומית באמצעות אזורי העברה שמבצעים שאילתות בשרתים מקומיים. כל בקשות ה-DNS לסביבה המקומית מגיעות ממרכז ה-DNS. מקור בקשת ה-DNS הוא 35.199.192.0/19.
מדיניות חומת אש
Google Cloud יש כמה סוגים של מדיניות חומת אש. מדיניות חומת אש היררכית נאכפת ברמת הארגון או התיקייה כדי להחיל את כללי המדיניות של חומת האש באופן עקבי על כל המשאבים בהיררכיה. בנוסף, אפשר להגדיר מדיניות של חומת אש בין רשתות לכל רשת VPC. תוכנית ה-blueprint משלבת את מדיניות חומת האש הזו כדי לאכוף הגדרות נפוצות בכל הסביבות באמצעות מדיניות חומת אש היררכית, וכדי לאכוף הגדרות ספציפיות יותר בכל רשת VPC בנפרד באמצעות מדיניות חומת אש של רשת.
התוכנית לא משתמשת בכללי חומת אש מדור קודם ב-VPC. מומלץ להשתמש רק במדיניות חומת אש ולהימנע משימוש משולב עם כללי חומת אש מדור קודם של VPC.
מדיניות היררכית של חומת אש
תוכנית ה-Blueprint מגדירה מדיניות חומת אש היררכית אחת ומצרפת את המדיניות לכל אחת מהתיקיות production, non-production, development, bootstrap ו-common. מדיניות חומת האש ההיררכית הזו מכילה את הכללים שצריכים להיות נאכפים באופן נרחב בכל הסביבות, ומעבירה את ההערכה של כללים מפורטים יותר למדיניות חומת האש בין רשתות עבור כל סביבה בנפרד.
בטבלה הבאה מתוארים הכללים ההיררכיים של מדיניות חומת האש שנפרסו באמצעות תוכנית ה-Blueprint.
| תיאור הכלל | כיוון התנועה | מסנן (טווח IPv4) | פרוטוקולים ויציאות | פעולה |
|---|---|---|---|---|
| העברת ההערכה של תנועת גולשים נכנסת מ-RFC 1918 לרמות נמוכות יותר בהיררכיה. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| כדאי להעביר את ההערכה של תנועת הגולשים היוצאת ל-RFC 1918 לרמות נמוכות יותר בהיררכיה. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| IAP להעברת TCP | Ingress |
35.235.240.0/20 |
tcp:22,3389 |
Allow |
| הפעלה של Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| בדיקות תקינות ל-Cloud Load Balancing | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
כללי מדיניות של חומת אש בין רשתות
תוכנית הפעולה מגדירה מדיניות חומת אש בין רשתות לכל רשת. כל מדיניות חומת אש בין רשתות מתחילה עם קבוצה מינימלית של כללים שמאפשרים גישה לשירותים ומסרבים לתעבורת נתונים יוצאת (egress) לכל כתובות ה-IP האחרות. Google Cloud
במודל 'רכזת וחישורים', מדיניות חומת האש של הרשת מכילה כללים נוספים שמאפשרים תקשורת בין החישורים. מדיניות חומת האש ברשת מאפשרת תעבורת נתונים יוצאת מנקודה אחת למרכז או ל-spoke אחר, ומאפשרת תעבורת נתונים נכנסת מ-NVA ברשת המרכזית.
בטבלה הבאה מפורטים הכללים במדיניות חומת האש הגלובלית ברשת, שמוטמעת בכל רשת VPC בתוכנית ה-blueprint.
| תיאור הכלל | כיוון התנועה | מסנן | פרוטוקולים ויציאות |
|---|---|---|---|
| מאפשרים תנועה יוצאת לממשקי API של Google Cloud. | Egress |
נקודת הקצה של Private Service Connect שמגדירים לכל רשת בנפרד. מידע נוסף זמין במאמר בנושא גישה פרטית ל-Google APIs. | tcp:443 |
| דחיית תנועה יוצאת שלא תואמת לכללים אחרים. | Egress |
all | all |
מתן הרשאה לתנועה יוצאת מ-spoke אחד ל-spoke אחר (רק למודל hub-and-spoke). | Egress | הצבירה של כל כתובות ה-IP שמשמשות בטופולוגיית רכזת-הסתעפות. תעבורת נתונים שיוצאת מרשת VPC מסוג Spoke מנותבת קודם ל-NVA ברשת Hub. | all |
התרת תנועה נכנסת ל-spoke מ-NVA ברשת hub (רק למודל hub-and-spoke). |
Ingress |
תנועה שמקורה במכשירי NVA ברשת המרכזית. | all |
כשפורסים את תוכנית האב לראשונה, מכונה וירטואלית ברשת VPC יכולה לתקשר עם שירותים, אבל לא עם משאבי תשתית אחרים באותה רשת VPC. Google Cloud כדי לאפשר למופעי VM לתקשר ביניהם, צריך להוסיף כללים נוספים למדיניות חומת האש של הרשת ותגים שמאפשרים למופעי ה-VM לתקשר ביניהם באופן מפורש. התגים מתווספים למופעי מכונות וירטואליות, והתנועה מוערכת בהתאם לתגים האלה. לתגים יש גם אמצעי בקרה של IAM, כך שאפשר להגדיר אותם באופן מרכזי ולהאציל את השימוש בהם לצוותים אחרים.
בתרשים הבא מוצגת דוגמה לאופן שבו אפשר להוסיף תגים מותאמים אישית וכללים של מדיניות חומת אש ברשת כדי לאפשר לעומסי עבודה לתקשר בתוך רשת VPC.
בתרשים מוצגים המושגים הבאים מהדוגמה הזו:
- מדיניות חומת אש בין רשתות מכילה את כלל 1 שדוחה תעבורה יוצאת מכל המקורות בעדיפות 65530.
- מדיניות חומת האש ברשת מכילה את כלל 2 שמאפשר תעבורה נכנסת ממופעים עם התג
service=frontendלמופעים עם התגservice=backendבעדיפות 999. - המכונה הווירטואלית instance-2 יכולה לקבל תנועה מהמכונה הווירטואלית instance-1 כי התנועה תואמת לתגים שמותרים לפי כלל 2. כלל 2 תואם לפני שכלל 1 נבדק, על סמך ערך העדיפות.
- המכונה הווירטואלית instance-3 לא מקבלת תעבורה. כלל מדיניות חומת האש היחיד שתואם לתעבורה הזו הוא כלל 1, ולכן התעבורה היוצאת ממופע 1 נדחית.
גישה פרטית לממשקי Google Cloud API
כדי לאפשר למשאבים ברשתות ה-VPC או בסביבה המקומית שלכם להגיע לשירותים שלGoogle Cloud , מומלץ להשתמש בקישוריות פרטית במקום בתעבורת אינטרנט יוצאת לנקודות קצה של API ציבורי. תוכנית האב מגדירה גישה פרטית ל-Google בכל רשת משנה, יוצרת נקודות קצה פנימיות באמצעות Private Service Connect כדי לתקשר עם שירותי Google Cloud , ומגדירה מדיניות חומת אש ורשומות DNS כדי לאפשר תנועה לנקודות הקצה האלה. האמצעים האלה מאפשרים ליצור נתיב פרטי לשירותי Google Cloud , בלי להסתמך על תעבורת נתונים יוצאת באינטרנט או על טווחי אינטרנט שפורסמו באופן ציבורי.
התוכנית מגדירה נקודות קצה של Private Service Connect עם חבילת ה-API שנקראת vpc-sc, שמאפשרת גישה ל Google Cloud שירותים
שנתמכים על ידי ה-VIP המוגבל. האמצעי הזה עוזר לצמצם את הסיכון להעברת נתונים לא מורשית על ידי מניעת גישה לממשקי Google API אחרים שלא קשורים ל- Google Cloud. הבדיקה הזו היא גם שלב חובה להפעלת VPC Service Controls. מידע נוסף על השלבים האופציונליים להפעלת VPC Service Controls זמין במאמר הגנה על המשאבים באמצעות VPC Service Controls.
בטבלה הבאה מתוארות נקודות הקצה של Private Service Connect שנוצרות לכל רשת.
| סביבה | חבילת API | כתובת ה-IP של נקודת הקצה של Private Service Connect | ||
|---|---|---|---|---|
| נפוץ | vpc-sc |
10.17.0.5/32 | ||
| פיתוח | vpc-sc |
10.17.0.6/32 | ||
| סביבה שאינה סביבת ייצור | vpc-sc |
10.17.0.7/32 | ||
| ייצור | vpc-sc |
10.17.0.8/32 | ||
כדי לוודא שהתנועה לשירותים Google Cloud כוללת חיפוש DNS לנקודת הקצה הנכונה, התוכנית מגדירה אזורי DNS פרטיים לכל רשת VPC. בטבלה הבאה מתוארים אזורי ה-DNS הפרטיים האלה.
| שם האזור הפרטי | שם DNS | סוג הרשומה | נתונים |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
restricted.googleapis.com. |
restricted.googleapis.com |
A |
כתובת ה-IP של נקודת הקצה של Private Service Connect עבור רשת ה-VPC הזו. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
כתובת ה-IP של נקודת הקצה של Private Service Connect עבור רשת ה-VPC הזו. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
כתובת ה-IP של נקודת הקצה של Private Service Connect עבור רשת ה-VPC הזו. |
בתוכנית ה-blueprint יש הגדרות נוספות שמבטיחות שימוש עקבי בנקודות הקצה האלה של Private Service Connect. בנוסף, כל רשת VPC משותפת אוכפת את הפעולות הבאות:
- כלל במדיניות חומת אש בין רשתות שמאפשר תעבורה יוצאת מכל המקורות לכתובת ה-IP של נקודת הקצה של Private Service Connect ב-TCP:443.
- כלל במדיניות חומת אש בין רשתות שדוחה תנועה יוצאת אל 0.0.0.0/0, שכולל את הדומיינים שמוגדרים כברירת מחדל שמשמשים לגישה לשירותי Google Cloud .
חיבור לאינטרנט
תוכנית האב לא מאפשרת תנועה נכנסת או יוצאת בין רשתות ה-VPC שלה לבין האינטרנט. עבור עומסי עבודה שנדרש להם חיבור לאינטרנט, צריך לבצע שלבים נוספים כדי לתכנן את נתיבי הגישה הנדרשים.
עבור עומסי עבודה שדורשים תעבורה יוצאת לאינטרנט, מומלץ לנהל את התעבורה היוצאת באמצעות Cloud NAT כדי לאפשר תעבורה יוצאת ללא חיבורים נכנסים לא רצויים, או באמצעות Secure Web Proxy כדי לקבל שליטה מפורטת יותר ולאפשר תעבורה יוצאת רק לשירותי אינטרנט מהימנים.
לעומסי עבודה שדורשים תנועה נכנסת מהאינטרנט, מומלץ לתכנן את עומס העבודה עם Cloud Load Balancing ועם Google Cloud Armor כדי ליהנות מהגנה מפני מתקפות DDoS ומ-WAF.
אנחנו לא ממליצים לתכנן עומסי עבודה שמאפשרים קישוריות ישירה בין האינטרנט לבין מכונה וירטואלית באמצעות כתובת IP חיצונית במכונה הווירטואלית.
קישוריות היברידית בין סביבה מקומית לבין Google Cloud
כדי ליצור קישוריות בין הסביבה המקומית לביןGoogle Cloud, מומלץ להשתמש ב-Dedicated Interconnect כדי למקסם את האבטחה והמהימנות. חיבור Dedicated Interconnect הוא קישור ישיר בין הרשת המקומית שלכם לביןGoogle Cloud.
בתרשים הבא מוצגת קישוריות היברידית בין סביבה מקומית לבין רשת של ענן וירטואלי פרטי (VPC) ב-Google.
בתרשים מתוארים הרכיבים הבאים של התבנית לזמינות של 99.99% ל-Dedicated Interconnect:
- ארבעה חיבורי Dedicated Interconnect, עם שני חיבורים באזור מטרופוליטני אחד ושני חיבורים באזור מטרופוליטני אחר. בכל אזור מטרו יש שני אזורים נפרדים במתקן האירוח.
- החיבורים מחולקים לשני זוגות, וכל זוג מחובר למרכז נתונים נפרד מקומי.
- חיבורי VLAN משמשים לחיבור כל מכונה של Dedicated Interconnect ל-Cloud Routers שמצורפים לטופולוגיה של ה-VPC המשותף.
- לכל רשת VPC משותפת יש ארבעה נתבי Cloud Router, שניים בכל אזור, ומצב הניתוב הדינמי מוגדר ל-
global, כך שכל Cloud Router יכול לפרסם את כל רשתות המשנה, ללא קשר לאזור.
בניתוב דינמי גלובלי, Cloud Router מפרסם מסלולים לכל תת-הרשתות ברשת ה-VPC. Cloud Router מפרסם נתיבים לתת-רשתות מרוחקות (תת-רשתות מחוץ לאזור של Cloud Router) עם עדיפות נמוכה יותר בהשוואה לתת-רשתות מקומיות (תת-רשתות שנמצאות באזור של Cloud Router). אפשר גם לשנות את הקידומות והעדיפויות שמתפרסמות כשמגדירים את סשן ה-BGP עבור Cloud Router.
תנועה מ Google Cloud אל סביבה מקומית משתמשת ב-Cloud Router שהכי קרוב למשאבי הענן. באזור יחיד, לכמה נתיבים לרשתות מקומיות יש אותו ערך של אפליה בין כמה נקודות יציאה (MED), והמערכת Google Cloud משתמשת Google Cloud בניתוב שווה-עלות של כמה נתיבים (ECMP) כדי לחלק את התנועה היוצאת בין כל הנתיבים האפשריים.
שינויים בהגדרות של פתרון מקומי
כדי להגדיר קישוריות בין הסביבה המקומית לביןGoogle Cloud, צריך לבצע שינויים נוספים בסביבה המקומית. קוד Terraform בתוכנית הבסיסית מגדיר באופן אוטומטיGoogle Cloud משאבים, אבל לא משנה אף אחד מהמשאבים ברשת המקומית.
חלק מהרכיבים לקישוריות היברידית מהסביבה המקומית שלכם אלGoogle Cloud מופעלים אוטומטית על ידי התוכנית, כולל הרכיבים הבאים:
- Cloud DNS מוגדר עם העברת DNS בין כל רשתות ה-VPC המשותפות למרכז יחיד, כפי שמתואר בהגדרת DNS. מדיניות שרת Cloud DNS מוגדרת עם כתובות IP של מעבירי נתונים נכנסים.
- Cloud Router מוגדר לייצא מסלולים לכל רשתות המשנה ולמסלולים מותאמים אישית לכתובות ה-IP שמשמשות את נקודות הקצה של Private Service Connect.
כדי להפעיל קישוריות היברידית, צריך לבצע את השלבים הנוספים הבאים:
- הזמנת חיבור Dedicated Interconnect
- מגדירים נתבים וחומות אש מקומיים כך שיאפשרו תנועה יוצאת למרחב כתובות ה-IP הפנימי שהוגדר בהקצאת מרחב כתובות IP.
- מגדירים את שרתי ה-DNS המקומיים להעברת חיפושי DNS שמוגבלים ל-Google Cloud אל כתובות ה-IP של מעביר הדואר הנכנס שכבר הוגדר על ידי התוכנית.
- מגדירים את שרתי ה-DNS, חומות האש והנתבים המקומיים כך שיקבלו שאילתות DNS מאזור ההעברה של Cloud DNS (35.199.192.0/19).
- מגדירים שרתי DNS מקומיים כדי שישיבו לשאילתות ממארחים מקומיים ל Google Cloud שירותים עם כתובות ה-IP שמוגדרות בגישה פרטית ל-Cloud APIs.
- כדי להצפין נתונים במעבר בחיבור Dedicated Interconnect, צריך להגדיר MACsec ל-Cloud Interconnect או להגדיר HA VPN דרך Cloud Interconnect להצפנת IPsec.
מידע נוסף זמין במאמר גישה פרטית ל-Google למארחים מקומיים.
המאמרים הבאים
- מידע נוסף על אמצעי בקרה לזיהוי (המסמך הבא בסדרה)