נדרשת רשת כדי שהמשאבים יוכלו לתקשר בתוך הארגון שלכם Google Cloud ובתוך סביבת הענן וסביבת השרתים המקומיים. בקטע הזה מתוארת המבנה בתוכנית הבסיסית לרשתות VPC, מרחב כתובות IP, DNS, מדיניות חומת אש וקישוריות לסביבה המקומית.
הטופולוגיה של הרשת
מאגר התוכניות מספק את האפשרויות הבאות לטופולוגיית הרשת שלכם:
- שימוש ברשתות VPC משותפות נפרדות לכל סביבה, בלי לאפשר תנועת נתונים ברשת ישירות בין הסביבות.
- משתמשים במודל hub-and-spoke שמוסיף רשת hub כדי לחבר כל סביבה ב- Google Cloud, עם תנועת רשת בין סביבות שמוגבלת על ידי מכשיר וירטואלי לרשת (NVA).
בוחרים באפשרות Shared VPC network for each environment topology (רשת VPC משותפת לכל טופולוגיית סביבה) אם לא רוצים קישוריות רשת ישירה בין סביבות. בוחרים באפשרות hub-and-spoke network topology (טופולוגיית רשת מסוג hub-and-spoke) אם רוצים לאפשר קישוריות רשת בין סביבות שמסוננת על ידי NVA, למשל אם מסתמכים על כלים קיימים שדורשים נתיב רשת ישיר לכל שרת בסביבה.
שתי הטופולוגיות משתמשות ב-VPC משותף כבסיס לבניית הרשת, כי הוא מאפשר הפרדה ברורה של האחריות. אדמינים של רשתות מנהלים משאבים ברשת בפרויקט מארח מרכזי, וצוותים של עומסי עבודה פורסים משאבים של אפליקציות ומשתמשים במשאבים ברשת בפרויקטים של שירות שמצורפים לפרויקט המארח.
רשת VPC משותפת לכל טופולוגיית סביבה
אם אתם צריכים לבודד את הרשתות של סביבת הפיתוח, הסביבה ללא ייצור וסביבת הייצור ב- Google Cloud, מומלץ להשתמש ברשת VPC משותפת לכל טופולוגיית סביבה. הטופולוגיה הזו לא מאפשרת תעבורת רשת בין סביבות.
הדיאגרמה הבאה מציגה את רשת ה-VPC המשותפת לכל טופולוגיית סביבה.
בתרשים מתוארים מושגי המפתח הבאים של VPC משותף לכל טופולוגיית סביבה:
- לכל סביבה (ייצור, לא ייצור ופיתוח) יש רשת VPC משותפת אחת. בתרשים הזה מוצגת רק סביבת הייצור, אבל אותו דפוס חוזר על עצמו בכל סביבה.
- לכל רשת VPC משותפת יש שתי תת-רשתות, וכל תת-רשת נמצאת באזור אחר.
- הקישוריות למשאבים מקומיים מופעלת באמצעות ארבעה קבצים מצורפים של VLAN למופע Dedicated Interconnect עבור כל רשת Shared VPC, באמצעות ארבעה שירותי Cloud Router (שניים בכל אזור לצורך יתירות). מידע נוסף זמין במאמר קישוריות היברידית בין סביבה מקומית לבין Google Cloud.
הטופולוגיה הזו לא מאפשרת לתנועת הרשת לזרום ישירות בין הסביבות. אם אתם צריכים שתנועת הרשת תזרום ישירות בין הסביבות, אתם צריכים לבצע פעולות נוספות כדי לאפשר את נתיב הרשת הזה. לדוגמה, אפשר להגדיר נקודות קצה של Private Service Connect כדי לחשוף שירות מרשת VPC אחת לרשת VPC אחרת. אפשרות אחרת היא להגדיר את הרשת המקומית כך שתאפשר תנועה מסביבתGoogle Cloud אחת לסביבה המקומית ואז לסביבת Google Cloud אחרת.
טופולוגיית רשת מסוג Hub-and-spoke
אם אתם פורסים משאבים ב Google Cloud שדורשים נתיב רשת ישיר למשאבים בסביבות מרובות, מומלץ להשתמש בטופולוגיית רשת מסוג hub-and-spoke.
טופולוגיית רכזת-הסתעפות משתמשת בכמה מהמושגים שקשורים לרשת VPC משותפת לכל טופולוגיית סביבה, אבל משנה את הטופולוגיה כדי להוסיף רשת רכזת. בתרשים הבא מוצגת טופולוגיית רכזת-הסתעפות.
בתרשים מוסברים המושגים המרכזיים האלה של טופולוגיית רשת מסוג hub-and-spoke:
- במודל הזה נוספת רשת מרכזית, וכל אחת מהרשתות לפיתוח, בסביבה ללא ייצור ובסביבת הייצור (רשתות משנה) מחוברת לרשת המרכזית באמצעות קישור בין רשתות VPC שכנות. לחלופין, אם אתם צופים שתחרגו ממגבלת המכסה, אתם יכולים להשתמש במקום זאת בשער HA VPN.
- הקישוריות לרשתות מקומיות מותרת רק דרך רשת ה-Hub. כל הרשתות המקושרות יכולות לתקשר עם משאבים משותפים ברשת המרכזית ולהשתמש בנתיב הזה כדי להתחבר לרשתות מקומיות.
- רשתות ה-Hub כוללות NVA לכל אזור, שנפרס באופן מיותר מאחורי מופעים פנימיים של מאזן עומסי רשת. ה-NVA הזה משמש כשער כדי לאפשר או לדחות תעבורת נתונים בין רשתות Spoke.
- רשת מרכז המכשירים מארחת גם כלים שנדרש חיבור שלהם לכל הרשתות האחרות. לדוגמה, אפשר לפרוס כלים במכונות וירטואליות לניהול הגדרות בסביבה המשותפת.
כדי לאפשר תעבורת נתונים בין רשתות spoke, התוכנית פורסת NVAs ברשת ה-VPC המשותפת של הרכזת, שפועלות כשערים בין הרשתות. הנתיבים מועברים מרשתות VPC מסוג Hub לרשתות VPC מסוג Spoke באמצעות העברת נתיבים מותאמים אישית. בתרחיש הזה, הקישוריות בין הרשתות ההסתעפותיות צריכה להיות מנותבת דרך ה-NVA, כי קישור בין רשתות VPC שכנות הוא לא טרנזיטיבי, ולכן רשתות ה-VPC ההסתעפותיות לא יכולות להחליף נתונים ביניהן ישירות. צריך להגדיר את המכשירים הווירטואליים כך שיאפשרו תעבורה בין רשתות ה-spoke באופן סלקטיבי.
דפוסי פריסה של פרויקטים
כשיוצרים פרויקטים חדשים לעומסי עבודה, צריך להחליט איך המשאבים בפרויקט הזה יתחברו לרשת הקיימת. בטבלה הבאה מתוארים דפוסי הפריסה של פרויקטים שמשמשים בתוכנית הפעולה.
| דוגמת קוד | תיאור | דוגמה לשימוש |
|---|---|---|
| פרויקטים של שירות VPC משותף | הפרויקטים האלה מוגדרים כפרויקטים של שירותים בפרויקט מארח של VPC משותף. משתמשים בתבנית הזו כשהמשאבים בפרויקט עומדים בקריטריונים הבאים:
|
example_shared_vpc_project.tf |
| פרויקטים צפים | פרויקטים צפים לא מחוברים לרשתות VPC אחרות בטופולוגיה שלכם. משתמשים בתבנית הזו כשהמשאבים בפרויקט עומדים בקריטריונים הבאים:
יכול להיות שתרצו להפריד את רשת ה-VPC של פרויקט צף מטופולוגיית רשת ה-VPC הראשית, אבל גם לחשוף מספר מוגבל של נקודות קצה בין הרשתות. במקרה כזה, מפרסמים שירותים באמצעות Private Service Connect כדי לשתף גישה לרשת לנקודת קצה (endpoint) ספציפית ברשתות VPC בלי לחשוף את הרשת כולה. |
example_floating_project.tf |
| פרויקטים של קישור בין רשתות שכנות (peering) | פרויקטים של קישור בין רשתות יוצרים רשתות VPC משלהם ומקשרים אותן לרשתות VPC אחרות בטופולוגיה שלכם. משתמשים בתבנית הזו כשהמשאבים בפרויקט עומדים בקריטריונים הבאים:
אם יוצרים פרויקטים של קישור בין רשתות שכנות (peering), באחריותכם להקצות טווחי כתובות IP שלא מתנגשים ולתכנן את מכסה לקבוצת קישור בין רשתות שכנות (peering). |
example_peering_project.tf |
הקצאת כתובות IP
בקטע הזה מוסבר איך ארכיטקטורת התוכנית מחלקת טווחי כתובות IP. יכול להיות שתצטרכו לשנות את טווחי כתובות ה-IP הספציפיים שבהם נעשה שימוש, בהתאם לזמינות של כתובות ה-IP בסביבה ההיברידית הקיימת.
בטבלה הבאה מפורט מרחב כתובות ה-IP שהוקצה לתוכנית הבסיסית. סביבת ה-Hub רלוונטית רק לטופולוגיית Hub-and-Spoke.
| מטרה | אזור | סביבת המרכז | סביבת פיתוח | סביבה שאינה סביבת ייצור | סביבת ייצור |
|---|---|---|---|---|---|
| טווחים של רשתות משנה ראשיות | אזור 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 מחולקת לטווחים לכל שילוב של מטרה, אזור וסביבה.
- חלק מהמשאבים הם גלובליים ולא צריך לחלק אותם לפי אזורים.
- כברירת מחדל, כשמדובר במשאבים אזוריים, תוכנית הפריסה נפרסת בשני אזורים. בנוסף, יש טווחי כתובות IP שלא נמצאים בשימוש, כך שאפשר להרחיב את הפריסה לשישה אזורים נוספים.
- הרשת של ה-Hub משמשת רק בטופולוגיית רשת מסוג Hub and Spoke, בעוד שסביבות הפיתוח, הסביבות שאינן סביבות ייצור וסביבות הייצור משמשות בשתי טופולוגיות הרשת.
בטבלה הבאה מוסבר איך משתמשים בכל סוג של טווח כתובות IP.
| מטרה | תיאור |
|---|---|
| טווחים של רשתות משנה ראשיות | משאבים שאתם פורסים ברשת ה-VPC, כמו מכונות וירטואליות, משתמשים בכתובות IP פנימיות מהטווחים האלה. |
| גישה לשירותים פרטיים | שירותים מסוימים, כמו Cloud SQL, דורשים הקצאה מראש של טווח כתובות ברשת משנה לגישה לשירותים פרטיים. Google Cloud התוכנית מגדירה טווח של /21 באופן גלובלי לכל אחת מרשתות ה-VPC המשותפות, כדי להקצות כתובות IP לשירותים שנדרשת להם גישה לשירותים פרטיים. כשיוצרים שירות שתלוי בגישה לשירותים פרטיים, מקצים תת-רשת אזורית מסוג /24 מתוך הטווח השמור מסוג /21. |
| התחברות לשירות פרטי | התוכנית מספקת לכל רשת VPC נקודת קצה של Private Service Connect כדי לתקשר עם Cloud APIs של Google. נקודת הקצה הזו מאפשרת למשאבים ברשת ה-VPC להגיע ל-Cloud APIs של Google בלי להסתמך על תעבורה יוצאת לאינטרנט או על טווחים של כתובות IP באינטרנט שפורסמו באופן ציבורי. |
| מאזני עומסים מבוססי-proxy | בסוגים מסוימים של מאזני עומסים של אפליקציות, צריך להקצות מראש רשתות משנה ל-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 אל Google Cloud מגיעות קודם למרכז ה-DNS, ואז הוא מפענח רשומות משרתי DNS עמיתים.
- שרתים ב- Google Cloud יכולים לפענח רשומות DNS בסביבה המקומית באמצעות אזורי העברה שמבצעים שאילתות בשרתים מקומיים. כל בקשות ה-DNS לסביבה המקומית מגיעות ממרכז ה-DNS. מקור בקשת ה-DNS הוא 35.199.192.0/19.
מדיניות חומת אש
Google Cloud יש כמה סוגים של מדיניות חומת אש. מדיניות חומת אש היררכית נאכפת ברמת הארגון או התיקייה כדי להעביר בירושה את כללי המדיניות של חומת האש באופן עקבי לכל המשאבים בהיררכיה. בנוסף, אפשר להגדיר מדיניות חומת אש בין רשתות לכל רשת VPC. התוכנית משלבת בין כללי המדיניות האלה של חומת האש כדי לאכוף הגדרות משותפות בכל הסביבות באמצעות כללי מדיניות היררכיים של חומת האש, וכדי לאכוף הגדרות ספציפיות יותר בכל רשת VPC בנפרד באמצעות כללי מדיניות של חומת אש ברשת.
התוכנית לא משתמשת בכללים של חומת אש ב-VPC מדור קודם. מומלץ להשתמש רק במדיניות חומת אש ולהימנע משימוש משולב עם כללי חומת אש מדור קודם של VPC.
מדיניות חומת אש היררכית
תוכנית האב מגדירה מדיניות אחת של חומת אש היררכית ומצרפת את המדיניות לכל אחד מהתיקיות 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 |
כללי מדיניות של חומת אש בין רשתות
תוכנית האב מגדירה מדיניות של חומת אש ברשת לכל רשת. כל מדיניות חומת אש בין רשתות מתחילה עם קבוצה מינימלית של כללים שמאפשרים גישה לשירותים ומונעים יציאה לכל כתובות ה-IP האחרות. Google Cloud
במודל של רשת מרכזית ורשתות היקפיות, מדיניות חומת אש בין רשתות מכילה כללים נוספים שמאפשרים תקשורת בין הרשתות ההיקפיות. מדיניות חומת אש בין רשתות מאפשרת תנועה יוצאת מרשת היקפית אחת לרשת המרכזית או לרשת היקפית אחרת, ותנועה נכנסת מ-NVA ברשת המרכזית.
בטבלה הבאה מפורטים הכללים במדיניות חומת אש בין רשתות גלובלית שנפרסה לכל רשת VPC בתוכנית השרטוט.
| תיאור הכלל | כיוון התנועה | מסנן | פרוטוקולים ויציאות |
|---|---|---|---|
| מאפשרים תנועה יוצאת לממשקי Google Cloud API. | Egress |
נקודת הקצה של Private Service Connect שמוגדרת לכל רשת בנפרד. מידע נוסף זמין במאמר בנושא גישה פרטית ל-Google APIs. | tcp:443 |
| דחיית תנועה יוצאת שלא תואמת לכללים אחרים. | Egress |
all | all |
מתן הרשאה לתנועה יוצאת מ-spoke אחד ל-spoke אחר (רק במודל hub-and-spoke). | Egress | הצבירה של כל כתובות ה-IP שמשמשות בטופולוגיה של רשת מרכזית ורשתות היקפיות. תעבורת נתונים שיוצאת מרשת VPC היקפית מנותבת קודם ל-NVA ברשת המרכזית. | all |
התרת תנועה נכנסת ל-spoke מ-NVA ברשת hub (רק למודל hub-and-spoke). |
Ingress |
תנועה שמקורה במכשירי NVA ברשת המרכז. | all |
כשפורסים את התוכנית לראשונה, מכונה וירטואלית ברשת VPC יכולה לתקשר עם שירותי Google Cloud , אבל לא עם משאבי תשתית אחרים באותה רשת VPC. כדי לאפשר למכונות וירטואליות לתקשר, צריך להוסיף כללים נוספים למדיניות חומת האש של הרשת ותגים שמאפשרים למכונות הווירטואליות לתקשר באופן מפורש. התגים מתווספים למכונות הווירטואליות, והתנועה נבדקת מול התגים האלה. בנוסף, לתגים יש אמצעי בקרה של IAM, כך שאפשר להגדיר אותם באופן מרכזי ולהקצות את השימוש בהם לצוותים אחרים.
בתרשים הבא מוצגת דוגמה לאופן שבו אפשר להוסיף תגים מותאמים אישית וכללים של מדיניות חומת אש ברשת כדי לאפשר לעומסי עבודה לתקשר בתוך רשת VPC.
בתרשים מוצגים המושגים הבאים מהדוגמה הזו:
- מדיניות חומת האש של הרשת מכילה את כלל 1 שדוחה תעבורה יוצאת מכל המקורות בעדיפות 65530.
- מדיניות חומת האש בין רשתות מכילה את כלל 2 שמאפשר תעבורה נכנסת ממופעים עם התג
service=frontendלמופעים עם התגservice=backendבעדיפות 999. - המכונה הווירטואלית instance-2 יכולה לקבל תעבורה מ-instance-1 כי התעבורה תואמת לתגים שמותרים לפי כלל 2. כלל 2 תואם לפני שכלל 1 נבדק, על סמך ערך העדיפות.
- המכונה הווירטואלית instance-3 לא מקבלת תעבורת נתונים. כלל מדיניות חומת האש היחיד שתואם לתעבורת הנתונים הזו הוא כלל 1, ולכן תעבורת הנתונים היוצאת מ-instance-1 נדחית.
גישה פרטית לממשקי Google Cloud APIs
כדי לאפשר למשאבים ברשתות ה-VPC או בסביבה המקומית שלכם להגיע לשירותים שלGoogle Cloud , מומלץ להשתמש בקישוריות פרטית במקום בתעבורת אינטרנט יוצאת לנקודות קצה של API ציבורי. התוכנית מגדירה גישה פרטית ל-Google בכל רשת משנה, יוצרת נקודות קצה (endpoints) פנימיות באמצעות Private Service Connect כדי לתקשר עם שירותי Google Cloud , ומגדירה מדיניות של חומת אש ורשומות DNS כדי לאפשר תנועה לנקודות הקצה האלה. השימוש המשותף באמצעי הבקרה האלה מאפשר ליצור נתיב פרטי לשירותי Google Cloud , בלי להסתמך על תעבורת נתונים יוצאת באינטרנט או על טווחי אינטרנט שפורסמו באופן ציבורי.
תוכנית ה-blueprint מגדירה נקודות קצה (endpoints) של 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.
בתרשים הבא מוצגת קישוריות היברידית בין סביבה מקומית לרשת ענן וירטואלי פרטי של 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 משתמש בניתוב equal cost multi-path (ECMP) כדי לחלק את התעבורה היוצאת בין כל הנתיבים האפשריים. Google Cloud
שינויים בהגדרות של שרת מקומי
כדי להגדיר קישוריות בין הסביבה המקומית לביןGoogle Cloud, צריך לבצע שינויים נוספים בסביבה המקומית. קוד Terraform בתוכנית ה-blueprint מגדיר באופן אוטומטי משאבי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 מקומיים כדי שיגיבו לשאילתות ממארחים מקומיים לשירותים עם כתובות ה-IP שמוגדרות בגישה פרטית ל-Cloud APIs. Google Cloud
- כדי להצפין נתונים במעבר בחיבור Dedicated Interconnect, צריך להגדיר MACsec ל-Cloud Interconnect או להגדיר HA VPN דרך Cloud Interconnect להצפנת IPsec.
מידע נוסף זמין במאמר גישה פרטית ל-Google למארחים מקומיים.
המאמרים הבאים
- מידע נוסף על אמצעי בקרה לזיהוי (המסמך הבא בסדרה)