‫NAT פרטי ל-NCC spokes

‫Private NAT מאפשר ליצור שער Cloud NAT שפועל בשילוב עם רכזות Network Connectivity Center כדי לבצע תרגום כתובות רשת (NAT) בין הרשתות הבאות:

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

המידע בדף הזה רלוונטי רק לתנועת נתונים ב-IPv4. לגבי תנועה ב-IPv6, אפשר לעיין במאמר NAT64 ב-NAT פרטי.

מפרטים

בנוסף למפרטים הכלליים של NAT פרטי, המפרטים של NAT פרטי עבור רכזות NCC הם:

  • ‫NAT פרטי משתמש בהגדרת NAT של type=PRIVATE כדי לאפשר תקשורת בין רשתות עם טווחי כתובות IP חופפים של תת-רשתות. עם זאת, רק רשתות משנה שלא חופפות יכולות להתחבר זו לזו.
  • צריך ליצור כלל NAT מותאם אישית על ידי הפניה ל-NCC Hub. כלל ה-NAT מציין טווח כתובות IP ל-NAT מרשת משנה עם ייעוד PRIVATE_NAT, ש-Private NAT משתמש בו כדי לבצע NAT בתעבורה בין הרשתות המחוברות.
  • כשיוצרים מכונה וירטואלית בטווח של רשת משנה שחל עליה NAT פרטי, כל תעבורת הנתונים היוצאת מהמכונה הווירטואלית הזו מתורגמת על ידי השער אם הרשת המסתעפת של היעד נמצאת באותו מרכז NCC כמו השער. ‫NAT פרטי מתרגם את התעבורה ל-spokes של יעד באותו אזור כמו שער ה-NAT הפרטי, וגם בין אזורים שונים.
  • שער NAT פרטי משויך לטווחים של כתובות IP ברשת משנה באזור יחיד ברשת VPC יחידה. המשמעות היא ששער NAT פרטי שנוצר ברשת VPC אחת לא מספק שירותי NAT למכונות וירטואליות ב-spokes אחרים של רכזת NCC, גם אם המכונות הווירטואליות נמצאות באותו אזור כמו השער.

תעבורה בין רשתות VPC

המפרטים הנוספים הבאים חלים על תעבורת נתונים בין רשתות VPC (NAT בין רשתות VPC):

  • כדי להפעיל NAT בין רשתות VPC בין שתי רשתות VPC, כל רשת VPC צריכה להיות מוגדרת כרשת מסוג spoke של VPC במרכז NCC. צריך לוודא שאין חפיפה בין טווחי כתובות ה-IP ברשתות ה-VPC מסוג Hub and Spoke. מידע נוסף זמין במאמר יצירת רשת מסוג Spoke ב-VPC.
  • למרכז NCC שמשויך לשער NAT פרטי צריכים להיות לפחות שני מרכזי VPC, שאחד מהם הוא רשת ה-VPC של שער ה-NAT הפרטי.
  • ‫NAT בין רשתות VPC תומך ב-NAT רק בין רשתות מסוג Hub and Spoke של NCC, ולא בין רשתות VPC שמקושרות באמצעות קישור בין רשתות VPC שכנות (peering).

תנועה בין רשתות VPC ורשתות אחרות

המפרטים הנוספים הבאים חלים על תעבורה בין רשתות VPC ורשתות מחוץ ל- Google Cloud:

מידע על הדרישות לשימוש ב-VPC spokes וב-hybrid spokes באותו מרכז NCC זמין במאמר החלפת מסלולים עם VPC spokes.

הגדרה בסיסית ותהליך עבודה

בתרשים הבא מוצגת תצורת NAT פרטית בסיסית לתנועה בין שני רכזות VPC:

‫ דוגמה לתרגום NAT בין רשתות VPC.
דוגמה לתרגום NAT בין רשתות VPC (לחצו כדי להגדיל).

בדוגמה הזו, ה-NAT הפרטי מוגדר באופן הבא:

  • pvt-nat-gw השער מוגדר ב-vpc-a כך שיחול על כל טווחי כתובות ה-IP של subnet-a באזור us-east1. באמצעות טווחי כתובות ה-IP של NAT‏ pvt-nat-gw, מופע של מכונה וירטואלית (VM) ב-subnet-a של vpc-a יכול לשלוח תנועה למכונה וירטואלית ב-subnet-b של vpc-b, גם אם subnet-a של vpc-a חופף ל-subnet-c של vpc-b.
  • גם vpc-a וגם vpc-b מוגדרים כסניפים של רכזת NCC.
  • שער pvt-nat-gw מוגדר לספק NAT בין רשתות VPC שמוגדרות כרשתות משנה (spoke) של VPC באותו מרכז (hub) של NCC.

דוגמה לתהליך עבודה

בתרשים שלמעלה, vm-a עם כתובת ה-IP הפנימית 192.168.1.2 ב-subnet-a של vpc-a צריך להוריד עדכון מ-vm-b עם כתובת ה-IP הפנימית 192.168.2.2 ב-subnet-b של vpc-b. שתי רשתות ה-VPC מחוברות לאותו מרכז NCC בתור רשתות Spoke של VPC. נניח ש-vpc-b מכיל רשת משנה נוספת 192.168.1.0/24 שחופפת לרשת המשנה ב-vpc-a. כדי ש-subnet-a של vpc-a יוכל לתקשר עם subnet-b של vpc-b, צריך להגדיר שער NAT פרטי, pvt-nat-gw, ב-vpc-a באופן הבא:

  • רשת משנה פרטית של NAT: לפני שמגדירים שער NAT פרטי, צריך ליצור רשת משנה פרטית של NAT עם המטרה PRIVATE_NAT, לדוגמה, 10.1.2.0/29. מוודאים שאין חפיפה בין התת-רשת הזו לבין תת-רשת קיימת באחד ממרכזי ה-VPC שמחוברים לאותו מרכז NCC.

  • כלל NAT שערך nexthop.hub שלו תואם לכתובת ה-URL של ה-hub ב-NCC.

  • ‫NAT לכל טווחי הכתובות של subnet-a.

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

שם הרשת רכיב רשת כתובת IP/טווח אזור
vpc-a

 subnet-a 192.168.1.0/24 us-east1
vm-a 192.168.1.2
pvt-nat-gw 10.1.2.0/29
vpc-b

 subnet-b 192.168.2.0/24 us-west1
vm-b 192.168.2.2
subnet-c 192.168.1.0/24
vm-c 192.168.1.3

ה-NAT הפרטי עבור רכזות NCC פועל לפי התהליך של הקצאת יציאות כדי להקצות את כתובת ה-IP של מקור ה-NAT ואת הטופלים של יציאת המקור לכל אחת מהמכונות הווירטואליות ברשת. לדוגמה, שער NAT פרטי שומר 64 יציאות מקור ל-vm-a: 10.1.2.2:34000 עד 10.1.2.2:34063.

כשמכונה וירטואלית משתמשת בפרוטוקול TCP כדי לשלוח חבילת נתונים לשרת העדכון 192.168.2.2 ביציאת היעד 80, מתרחשים הדברים הבאים:

  1. המכונה הווירטואלית שולחת מנה של בקשה עם המאפיינים הבאים:

    • כתובת ה-IP של המקור: 192.168.1.2, כתובת ה-IP הפנימית של מכונת ה-VM
    • יציאת מקור: 24000, יציאת המקור האפימרית שנבחרה על ידי מערכת ההפעלה של המכונה הווירטואלית
    • כתובת היעד: 192.168.2.2, כתובת ה-IP של שרת העדכון
    • יציאת היעד: 80, יציאת היעד לתעבורת HTTP לשרת העדכון
    • פרוטוקול: TCP

  2. שער pvt-nat-gw מבצע תרגום של כתובת הרשת של המקור (SNAT או source NAT) לתעבורה יוצאת, וכותב מחדש את כתובת ה-IP של המקור ב-NAT ואת יציאת המקור של חבילת הבקשה:

    • כתובת ה-IP של המקור ב-NAT: 10.1.2.2, מאחת מהמכונות הווירטואליות ששמורות לכתובת ה-IP של המקור ב-NAT ומהטופלים של יציאת המקור
    • יציאת המקור: 34022, יציאת מקור לא בשימוש מאחד הטפלים של יציאות המקור השמורות של המכונה הווירטואלית
    • כתובת היעד: 192.168.2.2, ללא שינוי
    • יציאת היעד: 80, ללא שינוי
    • פרוטוקול: TCP, ללא שינוי

  3. שרת העדכון שולח מנה של תגובה שמגיעה לשער pvt-nat-gw עם המאפיינים הבאים:

    • כתובת ה-IP של המקור: 192.168.2.2, כתובת ה-IP הפנימית של שרת העדכון
    • יציאת המקור: 80, תגובת ה-HTTP משרת העדכונים
    • כתובת היעד: 10.1.2.2, שזהה לכתובת ה-IP המקורית של המקור ב-NAT של חבילת הבקשה
    • יציאת היעד: 34022, שזהה ליציאת המקור של חבילת הבקשה
    • פרוטוקול: TCP, ללא שינוי

  4. שער pvt-nat-gw מבצע תרגום כתובת רשת של יעד (DNAT) בחבילת התגובה, וכותב מחדש את כתובת היעד ואת יציאת היעד של חבילת התגובה, כך שהחבילה מועברת למכונה הווירטואלית שביקשה את העדכון עם המאפיינים הבאים:

    • כתובת ה-IP של המקור: 192.168.2.2, ללא שינוי
    • יציאת המקור: 80, ללא שינוי
    • כתובת היעד: 192.168.1.2, כתובת ה-IP הפנימית של המכונה הווירטואלית
    • יציאת היעד: 24000, זהה ליציאת המקור האפמרית המקורית של חבילת הבקשה
    • פרוטוקול: TCP, ללא שינוי

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