טווחים של כתובות IP חלופיות
Cloud de Confiance by S3NS אפשר להשתמש בטווחים של כתובות IP חלופיות כדי להקצות טווחים של כתובות IP פנימיות ככתובות חלופיות לממשקי רשת של מכונה וירטואלית (VM). האפשרות הזו שימושית אם יש לכם כמה שירותים שפועלים במכונה וירטואלית ואתם רוצים להקצות לכל שירות כתובת IP שונה. טווחים של כתובות IP של כינויים פועלים גם עם GKE Pods.
אם יש לכם רק שירות אחד שפועל במכונה וירטואלית, אתם יכולים להפנות אליו באמצעות כתובת ה-IP הראשית של הממשק. אם יש לכם כמה שירותים שפועלים במכונה וירטואלית, יכול להיות שתרצו להקצות לכל אחד מהם כתובת IP פנימית שונה. אפשר לעשות את זה באמצעות טווחי IP של כינויים.
טווחי CIDR ראשיים ומשניים של רשתות משנה
לכל תת-הרשתות עם טווחי כתובות IPv4 יש טווח CIDR ראשי, שהוא טווח כתובות ה-IP הפנימיות שמגדירות את תת-הרשת. כל מכונה וירטואלית מקבלת את כתובת ה-IP הפנימית הראשית שלה מהטווח הזה. אפשר גם להקצות טווחי IP חלופיים מהטווח הראשי הזה, או להוסיף טווח משני לתת-הרשת ולהקצות טווחי IP חלופיים מהטווח המשני. השימוש בטווחים של כתובות IP של כינויים לא מחייב טווחים משניים של רשתות משנה. טווחים משניים של רשתות משנה משמשים רק ככלי ארגוני.
טווחים של כתובות IP של כינוי שמוגדרים בממשק רשת של מכונה וירטואלית
באמצעות כינוי IP, אתם יכולים להגדיר כמה כתובות IP פנימיות שמייצגות קונטיינרים או אפליקציות שמתארחים במכונה וירטואלית, בלי להגדיר ממשק רשת נפרד. אפשר להקצות טווחי IP של כתובות IP וירטואליות למכונות וירטואליות מהטווחים הראשיים או המשניים של תת-הרשת.
הגדרת טווחי כתובות IP חלופיות מתארת פקודות להגדרת רשת משנה עם טווחים משניים ולהקצאת כתובות IP חלופיות למכונות וירטואליות.
בתרשים הבא מוצגת דוגמה בסיסית לטווחים של כתובות CIDR ראשיות ומשניות ולטווחים של כתובות IP של כינויי מכונות וירטואליות בממשק הראשי של המכונה הווירטואלית:
- טווח CIDR ראשי
10.1.0.0/16מוגדר כחלק מרשת משנה. - טווח CIDR משני
10.2.0.0/20מוגדר כחלק מרשת משנה. - כתובת ה-IP הראשית של מכונת ה-VM
10.1.0.2מוקצית מטווח ה-CIDR הראשי,10.1.0.0/16, בעוד שטווח כתובות IP של כינוי, 10.2.1.0/24, מוקצה במכונת ה-VM מטווח ה-CIDR המשני, 10.2.0.0/20. - הכתובות בטווח כתובות ה-IP של הכינוי משמשות ככתובות ה-IP של המאגדים שמארחים במכונה הווירטואלית.
היתרונות העיקריים של טווחי כתובות IP של כינויים
כשמגדירים טווחי IP של כינויים, Cloud de Confiance מערכת Google Cloud מתקינה אוטומטית נתיבים של רשתות ענן וירטואלי פרטי (VPC) לטווחי ה-IP הראשיים ולטווחי ה-IP של הכינויים עבור תת-הרשת של ממשק הרשת הראשי. אין צורך שמנהל התזמור של הקונטיינר יציין קישוריות לרשת VPC עבור המסלולים האלה. כך קל יותר להפנות תנועה ולנהל את מאגרי התגים. צריך לבצע הגדרה בתוך האורח, כמו שמתואר במאמר מאפייני מפתח של טווחי כתובות IP של כינויים.
כשכתובות ה-IP של הקונטיינרים מוקצות על ידי Cloud de Confiance, תהליכי האימות ב- Cloud de Confianceמוודאים שכתובות ה-IP של פודים של קונטיינרים לא מתנגשות עם כתובות ה-IP של מכונות וירטואליות.
כשמוגדרות כתובות IP של כינוי, מתבצעות בדיקות נגד זיוף של התעבורה, כדי לוודא שהתעבורה שיוצאת מהמכונות הווירטואליות משתמשת בכתובות ה-IP של המכונות הווירטואליות ובכתובות ה-IP של הפודים ככתובות מקור. בדיקות נגד זיוף מוודאות שמכונות וירטואליות לא שולחות תנועה עם כתובות IP שרירותיות של מקורות. שימוש בניתוב סטטי ברשתות של קונטיינרים הוא גישה פחות מאובטחת בהשוואה לשימוש בכינויי IP, כי הוא מחייב השבתה של בדיקות נגד זיוף במכונות וירטואליות של מארחי קונטיינרים (הבדיקות נגד זיוף מושבתות כשמופעלת העברת IP).
אפשר להפנות טווחים של כתובות IP של כינויים בתוך Cloud de Confiance הרשת הווירטואלית בלי שיידרשו מסלולים נוספים. לא צריך להוסיף נתיב לכל כינוי IP, ואין צורך להתחשב במכסות הנתיבים.
אפשר לפרסם כתובות IP של כינויים באמצעות Cloud Router ברשת מקומית שמחוברת באמצעות VPN או Interconnect.
יש יתרונות בהקצאת טווחי כתובות IP של כינויים מטווח CIDR משני. אם מקצים כתובות מטווח שונה מהטווח שמשמש לכתובות IP ראשיות, אפשר להפריד בין התשתית (מכונות וירטואליות) לבין השירותים (קונטיינרים). כשמגדירים מרחבי כתובות נפרדים לתשתית ולשירותים, אפשר להגדיר אמצעי בקרה של חומת אש לכתובות IP של כינוי של מכונה וירטואלית בנפרד מאמצעי הבקרה של חומת אש לכתובות ה-IP הראשיות של מכונה וירטואלית. לדוגמה, אתם יכולים לאפשר תעבורה מסוימת לפודים של קונטיינרים ולדחות תעבורה דומה לכתובת ה-IP הראשית של המכונה הווירטואלית.
ארכיטקטורת קונטיינרים ב Cloud de Confiance
נניח שאתם רוצים להגדיר שירותים מבוססי-קונטיינר על גבי Cloud de Confiance. צריך ליצור את המכונות הווירטואליות שיארחו את השירותים, וגם את הקונטיינרים.
בתרחיש הזה, אתם רוצים להפנות את התנועה מהקונטיינרים ואליהם אל מיקומים מקומיים שמחוברים דרך VPN. עם זאת, אתם לא רוצים שיהיה אפשר להגיע לכתובות ה-IP של מכונות וירטואליות ראשיות דרך ה-VPN. כדי ליצור את ההגדרה הזו, טווח כתובות ה-IP של הקונטיינר צריך להיות ניתן לניתוב דרך ה-VPN, אבל לא טווח כתובות ה-IP הראשי של המכונה הווירטואלית. בזמן יצירת המכונה הווירטואלית, אתם רוצים גם להקצות באופן אוטומטי מאגר של כתובות IP שמשמשות את הקונטיינר.
כדי ליצור את ההגדרה הזו:
- כשיוצרים את רשת המשנה, מגדירים את
- טווח CIDR ראשי אחד, לדוגמה,
10.128.0.0/16 - טווח CIDR משני אחד, לדוגמה,
172.16.0.0/16
- טווח CIDR ראשי אחד, לדוגמה,
- משתמשים בתבנית של הגדרות מכונה כדי ליצור מכונות וירטואליות ולהקצות לכל אחת מהן באופן אוטומטי את הפרטים הבאים:
- כתובת IP ראשית מהטווח
10.128.0.0/16 - טווח של כתובות IP וירטואליות
/24ממרחב ה-CIDR המשני172.16.0.0/16, כדי שתוכלו להקצות לכל מאגר במכונה וירטואלית כתובת IP מטווח ה-CIDR/24המשני
- כתובת IP ראשית מהטווח
- יוצרים שני כללים לחומת האש.
- כלל אחד שדוחה תנועה שעוברת דרך ה-VPN ממיקום מקומי, ומגיעה לטווח ה-CIDR הראשי של תת-הרשת.
- כלל אחד שמאפשר לתעבורת נתונים שעוברת דרך ה-VPN משרת מקומי להגיע לטווח ה-CIDR המשני של תת-הרשת.
דוגמה: הגדרת מאגרי תגים עם טווחי כתובות IP חלופיות
באמצעות טווחי כתובות IP של כינוי, אפשר להקצות כתובות IP של מאגר מטווח CIDR משני ולהגדיר אותן ככתובות IP של כינוי במכונה הווירטואלית שמארחת את המאגר.
כדי ליצור את ההגדרה שמוצגת למעלה:
יוצרים תת-רשת עם טווח CIDR 10.128.0.0/16, שממנו מוקצות כתובות IP של מכונות וירטואליות, וטווח CIDR משני 172.16.0.0/20 לשימוש בלעדי של הקונטיינרים, שיוגדר כטווחים של כתובות IP של כינויים במכונה הווירטואלית שמארחת אותם:
gcloud compute networks subnets create subnet-a \ --network network-a \ --range 10.128.0.0/16 \ --secondary-range container-range=172.16.0.0/20יצירת מכונות וירטואליות עם כתובת IP ראשית מהטווח 10.128.0.0/16 וטווח כתובות IP של כינוי 172.16.0.0/24 מטווח ה-CIDR המשני 172.16.0.0/20 לשימוש במאגרי המידע במכונה הווירטואלית:
gcloud compute instances create vm1 [...] \ --network-interface subnet=subnet-a,aliases=container-range:172.16.0.0/24 gcloud compute instances create vm2 [...] \ --network-interface subnet=subnet-a,aliases=container-range:172.16.1.0/24כתובות ה-IP של הקונטיינרים מוגדרות ב- Cloud de Confiance ככתובות IP של כינויים. בהגדרה הזו, אפשר להגיע גם לכתובות ה-IP הראשיות וגם לכתובות ה-IP החלופיות דרך מנהרת ה-VPN. אם Cloud Router מוגדר, הוא יפרסם אוטומטית את טווח רשת המשנה המשני 172.16.0.0/20.
מידע נוסף על הפקודות שמשמשות ליצירת ההגדרה הזו זמין במאמר הגדרת טווחים וכתובות IP של כינויים.
דוגמה: כמה טווחי כתובות IP של כינויים שהוגדרו במופע מכונה וירטואלית יחיד
טווחים של כתובות IP של כינויים מאפשרים לכם לנהל הקצאת כתובות IP לאפליקציות שפועלות במכונות וירטואליות, כולל בקונטיינרים.
יכול להיות שיש לכם פריסה שבה חלק מהקונטיינרים ניתנים להעברה בין מכונות וירטואליות וחלק לא. אפשר להגדיר את המאגרי התגים שניתנים להעברה באמצעות טווחי /32, כך שקל להעביר אותם בנפרד. אפשר להגדיר את המאגרי התגים שלא ניתן להעביר באמצעות טווח גדול יותר, כי הם יישארו ביחד.
בפריסות מהסוג הזה, יכול להיות שתצטרכו יותר מטווח אחד של כתובות IP של כינוי לכל מכונה וירטואלית. לדוגמה, /27 למאגרי מידע שלא ניתן להעביר ו- /32 למאגרי מידע שניתן להעביר.
כדי להגדיר את הדוגמה הזו, משתמשים בפקודות gcloud הבאות:
gcloud compute networks create vpc1 --subnet-mode custom
gcloud compute networks subnets create subnet1 --region us-central1 --network vpc1 --range 10.128.0.0/16 --secondary-range secondaryrange1=172.16.0.0/20
gcloud compute instances create vm1 --zone us-central1-a --network-interface "subnet=subnet1,aliases=secondaryrange1:172.16.0.0/27;secondaryrange1:172.16.1.0/32"
gcloud compute instances create vm2 --zone us-central1-a --network-interface "subnet=subnet1,aliases=secondaryrange1:172.16.0.32/27;secondaryrange1:172.16.1.1/32"
כתובות IP של כינוי ברשתות ובתת-רשתות של VPC במצב אוטומטי
לכל אחת מהרשתות המשנה שנוצרות באופן אוטומטי ברשתות VPC במצב אוטומטי יש טווח CIDR ראשי, אבל אין טווח משני. כדי להשתמש בכתובת IP של כינוי ברשת VPC במצב אוטומטי, אפשר להקצות טווחי כתובות IP של כינוי מתוך טווח ה-CIDR הראשי של תת-הרשת שנוצרה באופן אוטומטי, או להוסיף טווח משני לתת-הרשת שנוצרה באופן אוטומטי ולהקצות טווחי כתובות IP של כינוי מתוך הטווח המשני החדש.
לחלופין, אפשר ליצור תת-רשת חדשה עם טווחים משניים ברשת VPC במצב אוטומטי, כל עוד אף אחד מהטווחים שלה לא חופף ל-10.128.0.0/9. לאחר מכן תוכלו ליצור מכונות וירטואליות בתת-הרשת החדשה ולהקצות טווחי כתובות IP של כינויים מכל טווח בתת-הרשת הזו.
אם רוצים להוסיף טווחי משנה לרשת המשנה, אפשר לעיין במאמר בנושא הוספת טווחי CIDR משניים לרשת משנה קיימת.
כתובות IP של כינויים ברשתות וברשתות משנה במצב מותאם אישית
ברשתות במצב מותאם אישית:
- כל רשתות המשנה נוצרות באופן ידני
- חובה לציין טווח CIDR ראשי אחד.
- אפשר גם ליצור טווחי CIDR משניים.
מאפיינים מרכזיים של טווחי IP של כינויים
המאפיינים הבאים חלים על טווחי כתובות IP של כינויים שהוגדרו במכונות וירטואליות:
- מנקודת המבט של מערכת ההפעלה של המכונה הווירטואלית, כתובת ה-IP הראשית ושער ברירת המחדל מוקצים בדרך כלל באמצעות DHCP. אפשר להגדיר כתובות IP של כינוי במערכת ההפעלה של המכונה הווירטואלית, שהיא בדרך כלל Linux או Windows, באופן ידני או באמצעות סקריפטים.
- כתובת ה-IP הראשית וטווח כתובות ה-IP של הכינוי של הממשק צריכים להיות מוקצים מטווחים של CIDR שהוגדרו כחלק מאותה תת-רשת.
חשוב לזכור את הדרישות הבאות:
- כתובת ה-IP הראשית חייבת להיות מוקצית מטווח ה-CIDR הראשי.
- אפשר להקצות את טווח כתובות ה-IP של הכינוי מטווח ה-CIDR הראשי או מטווח CIDR משני של אותה תת-רשת.
- במקרה של ממשק רשת של מכונה וירטואלית, כתובת ה-IP החלופית צריכה להיות מאותו משאב של תת-רשת שמספק את כתובת ה-IP לממשק הרשת הראשי. אי אפשר לבחור טווח CIDR ראשי או משני ממקור אחר של משאבי רשת משנה.
- כתובת ה-IP הראשית יכולה להיות כתובת IP פנימית סטטית או זמנית.
- טווחים של כתובות IP של כינויים הם אופציונליים ולא מתווספים באופן אוטומטי. אפשר להגדיר טווח כתובות IP של כינוי במהלך יצירת המכונה או השינוי שלה.
- אפשר להגדיר טווח של כתובות IP של כינוי כטווח CIDR מפורש (לדוגמה,
10.128.1.0/24), ככתובת IP יחידה (לדוגמה,10.128.7.29/32) או כמסכת רשת (/24). אפשר לציין טווח של כתובות IP של כינוי באופן מלא או להקצות אותו באופן אוטומטי על ידי ציון מסכת הרשת. - כדי להשתמש בכתובת IP אחת בטווח כתובות IP של כינוי, משתמשים ב
/32netmask. - מכיוון שכל תת-הרשתות ברשת VPC חולקות שער ברירת מחדל יחיד, כל כתובות ה-IP של הכינויים בממשק חולקות את אותו שער ברירת מחדל כמו כתובת ה-IP הראשית.
- אי אפשר לשריין כתובת IP פנימית מטווח של תת-רשת משנית.
- אפשר לשמור כתובת IP פנימית מטווח ראשי של תת-רשת ולהשתמש בה כ
/32טווח IP של כתובת אימייל חלופית.
DNS עם כתובות IP של כינויים
Cloud de Confiance מגדיר באופן אוטומטי DNS פנימי לכתובת ה-IP הראשית של הממשק הראשי של כל מופע של מכונת VM. כך משייכים את שם המארח של המופע לכתובת ה-IP הראשית של הממשק הראשי. עם זאת, חיפוש ה-DNS בשם המארח הזה פועל רק ברשת שמכילה את הממשק הראשי.
Cloud de Confiance לא משייך באופן אוטומטי כתובות IP אחרות לשם המארח. Cloud de Confiance לא משייך כתובות IP חלופיות בממשק הראשי לשם המארח, ולא משייך כתובות IP של ממשקים משניים לשם המארח.
אפשר להגדיר DNS באופן ידני כדי לשייך כתובות IP אחרות.
חומות אש
כל תעבורת הנתונים הנכנסת או היוצאת, כולל תעבורת נתונים לטווחים של כתובות IP של כינוי, נבדקת על ידי כלל חומת אש של VPC כדי למצוא תג יעד או חשבון שירות יעד שתואמים לה. פרטים על יעדים וכתובות IP חלופיות מופיעים במאמר יעדים וכתובות IP.
כשמציינים מקורות לכלל חומת אש של תעבורת כניסה באמצעות תגי מקור או חשבונות שירות של מקור, טווחי כתובות IP של כינויים לא נכללים.
מסלולים סטטיים
כשיוצרים מסלול סטטי שמשתמש במכונה של הצעד הבא שצוינה על ידי כתובת IPv4 פנימית,המערכת בודקת שכתובת ה-IP של המכונה הווירטואלית של הצעד הבא מתאימה לטווח כתובות ה-IPv4 של רשת משנה ברשת ה-VPC של המסלול. Cloud de Confiance עם זאת, Cloud de Confiance התוכנה מתכנתת את המסלול רק אם כתובת הניתוב הבאה היא כתובת IPv4 פנימית ראשית שהוקצתה לכרטיס רשת (NIC) של מכונה וירטואלית ברשת ה-VPC של המסלול (לא ברשת VPC שכנה).
אפשר ליצור מסלול שכתובת הצעד הבא שלו היא כתובת IPv4 פנימית שנמצאת בטווח של כתובת IP של כינוי,אבל Cloud de Confiance לא מתכנת את המסלול הזה –Cloud de Confiance מחשיב את הצעד הבא כלא פעיל. יכול להיות שמנות נתונים שנשלחות ליעד של המסלול יימחקו, בהתאם לשאלה אם קיימים מסלולים אחרים לאותו יעד בדיוק, ולשאלה אם במסלולים האחרים האלה יש מעברים הבאים שפועלים.
למידע נוסף:
קישור בין רשתות VPC שכנות (peering)
קישור בין רשתות VPC שכנות מאפשר לקשר בין שתי רשתות VPC כדי שהמכונות הווירטואליות בשתי הרשתות יוכלו לתקשר באמצעות כתובות IP פנימיות ופרטיות.
מכונות וירטואליות ברשתות מקושרות יכולות להגיע לטווח ה-IP הראשי והמשני של תת-רשת.
בדיקות של חפיפה בין רשתות משנה ברשתות מקבילות מוודאות שטווחים ראשיים ומשניים לא חופפים לטווחים מקבילים.
שיקולים לגבי רשתות VPC של RoCE
כשמשתמשים בכתובות IP של כינוי עם MRDMA כרטיסי vNIC שמצורפים לרשתות RoCE VPC, כדאי לשים לב לנקודות הבאות:
סוג רשת VPC עם תמיכה ב-RoCE: התמיכה בטווחים של כתובות IP עם כינוי חלה רק על רשתות VPC עם RoCE למכונות וירטואליות, שנוצרות באמצעות פרופיל הרשת
roce. לא ניתן להשתמש בטווחים של כתובות IP וירטואליות ברשתות RoCE VPC למכונות Bare Metal שנוצרות באמצעות פרופיל הרשתroce-metal.מגבלת חיבורים ברשתות VPC של RoCE: ברשת VPC נתונה של RoCE יש מגבלת מערכת על המספר המקסימלי של חיבורים. מידע נוסף על מגבלת מספר החיבורים לרשתות RoCE VPC
שיקולים לגבי מרחב שמות עבור RDMA: מומלץ להשתמש במצב IPVLAN L2 לקישוריות RDMA. המכשירים יכולים להיות במרחב השמות של רשת הבסיס או במרחב השמות שאינו בסיס (למשל, pods או containers). דוגמה מופיעה בקטע הבא.
דוגמה: מצב IPVLAN L2 עם מרחב שמות
בדוגמה הבאה מוסבר איך להגדיר ידנית IPVLAN L2 עם מרחב שמות ברשת:
# 1. Create a network namespace named 'example_ns'
sudo ip netns add example_ns
# 2. Create the ipvlan interface 'gpu0rdma0_ipvlanl2' linked to 'gpu0rdma0' in L2 mode
# L3 mode handles packets at the network layer; no MAC address or ARP is used.
sudo ip link add gpu0rdma0_ipvlanl2 link gpu0rdma0 type ipvlan mode l2
# 3. Move the 'gpu0rdma0_ipvlanl2' interface into 'example_ns'
sudo ip link set gpu0rdma0_ipvlanl2 netns example_ns
# 4. Bring up the loopback interface inside the namespace for local process communication
sudo ip netns exec example_ns ip link set lo up
# 5. Assign the IP address to the custom interface
# Using a /32 is common in L2 mode as it acts as a point-to-point endpoint.
sudo ip netns exec example_ns ip addr add 172.16.1.0/32 dev gpu0rdma0_ipvlanl2
# 6. Set the interface state to 'up' inside the namespace
sudo ip netns exec example_ns ip link set gpu0rdma0_ipvlanl2 up
# 7. Verification: Check the interface configuration inside the namespace
sudo ip netns exec example_ns ip addr show gpu0rdma0_ipvlanl2