Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ניהול חפיפה בין יעדים

בדף הזה מוסבר איך אדמינים של רשתות ספקים יכולים לנהל חפיפה של יעדים ברשת של ענן וירטואלי פרטי (VPC) שמשתמשת בממשק Private Service Connect.

Google Cloud מוודא שלרשתות משנה שהוקצו לממשקי רשת באותה מכונה וירטואלית (VM) לא יהיו טווחים חופפים של כתובות IP. עם זאת, רשתות משנה ברשתות ה-VPC של הצרכן והספק יכולות לחפוף, כמו שמוצג באיור 1. כשמשתמשים בממשק Private Service Connect עם טווחי כתובות IP של יעד חופפים, צריך לבצע הגדרה נוספת כדי לוודא שהתעבורה מגיעה ליעד הנכון ברשת הרצויה.

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

`Subnet-a` ברשת VPC של ספק שירות חופפת ל-`subnet-c` ברשת VPC של צרכן כי שתי רשתות המשנה משתמשות באותו טווח כתובות IP. המכונה הווירטואלית של היצרן צריכה להיות מסוגלת להגיע אל `10.0.1.5` בשתי הרשתות.

יש כמה דרכים לנהל טווחי כתובות IP חופפים של יעדים, והן מתוארות בפירוט בדף הזה:

משתמשים במרחבי שמות ברשת כדי ליצור טבלאות ניתוב נפרדות לכל אפליקציה.
החלת ניתוב על סמך מדיניות על מכונת ה-VM של הממשק כדי לנתב את התנועה על סמך יציאות היעד.

אפשר גם להשתמש בגישות הבאות כדי לנהל חפיפה של יעדים, אבל הן לא מתוארות בדף הזה:

משתמשים בספריית שקעים וב-bind() כדי לשלוט בניתוב.
משתמשים במרחב כתובות IP שלא חופף בכלל לרשת של היוצר.
אם כתובות ה-IP החופפות בצד של הספק מיועדות רק לנקודות קצה של API מהדומיין הנוכחי, אפשר להגדיר גישה פרטית ל-Google עבור מארחים מקומיים.
משתמשים בניתוב וירטואלי והעברה (VRF) כדי לבודד חפיפות בין מרחבי כתובות IP. מקצים מופע VRF לכל ממשק Private Service Connect. צריך להגדיר מסלולי ברירת מחדל לכל מופע של VRF כדי לוודא שהתנועה מגיעה ליעד המיועד.
אפשר להשתמש ב-eBPF כדי להתאים אישית כללי ניתוב מתקדמים על סמך קריטריונים שאינם כתובת IP. הגישה הזו מומלצת במקרים שבהם האפשרויות הקודמות לא מתאימות.

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

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

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

מתחברים למכונה הווירטואלית שיש לה ממשק Private Service Connect.
מציאת שם מערכת ההפעלה של האורח בממשק Private Service Connect.
כדי ליצור מרחב שמות ברשת לתנועה שמופנית לצרכנים, משתמשים בפקודה הבאה:
```
sudo ip netns add consumer-ns
```
מעבירים את הממשק של Private Service Connect למרחב השמות של רשת הצרכן. מריצים את הפקודות הבאות בנפרד:
```
sudo ip link set OS_INTERFACE_NAME netns consumer-ns
```
```
sudo ip netns exec consumer-ns ip link set OS_INTERFACE_NAME up
```
מחליפים את OS_INTERFACE_NAME בשם מערכת ההפעלה האורחת של ממשק Private Service Connect שמצאתם בשלב הקודם.
שחזור כתובת ה-IP של ממשק Private Service Connect:
```
sudo ip netns exec consumer-ns ip addr add INTERFACE_IP/32 dev OS_INTERFACE_NAME
```
מחליפים את INTERFACE_IP בכתובת ה-IP של ממשק Private Service Connect.
מאמתים את השינויים בממשק Private Service Connect:
```
sudo ip netns exec consumer-ns ip a
```
מוודאים ששם מערכת ההפעלה של האורח בממשק Private Service Connect מופיע בפלט של הפקודה. מוודאים שלממשק יש את כתובת ה-IP הנכונה.
מוסיפים נתיב לכתובת ה-IP של השער:
```
sudo ip netns exec consumer-ns ip route add GATEWAY_IP dev OS_INTERFACE_NAME scope link
```
מחליפים את GATEWAY_IP בכתובת ה-IP של שער ברירת המחדל של תת-הרשת של הממשק של Private Service Connect.

מוסיפים נתיב ברירת מחדל לממשק Private Service Connect:

sudo ip netns exec consumer-ns ip route add default via GATEWAY_IP dev OS_INTERFACE_NAME

מאמתים את טבלת הניתוב עבור מרחב השמות consumer-ns:
```
sudo ip netns exec consumer-ns ip route
```
מוודאים שבטבלת הניתוב יש רשומה בפורמט הבא:
```
default via GATEWAY_IP dev OS_INTERFACE_NAME
```
כדי לוודא שהממשק יכול להגיע למכונות וירטואליות בכל חלק של טווח כתובות ה-IP החופף, מבצעים את הפעולות הבאות:
1. מוודאים שכללי חומת האש מוגדרים כך שיאפשרו תעבורת נתונים נכנסת (ingress) ICMP למכונות הווירטואליות של היעד.
2. שולחים ICMP פינג מהמכונה הווירטואלית של הממשק למכונה וירטואלית של צרכן שנמצאת בטווח כתובות ה-IP החופף. משתמשים במרחב השמות של הצרכן:
```
sudo ip netns exec consumer-ns ping CONSUMER_IP_ADDRESS
```
  מחליפים את CONSUMER_IP_ADDRESS בכתובת ה-IP של מכונה וירטואלית של צרכן מתוך טווח כתובות ה-IP החופף.
3. שולחים ICMP פינג מהמכונה הווירטואלית של הממשק למכונה וירטואלית של יצרן שנמצאת בטווח כתובות ה-IP החופף. שימוש במרחב השמות שמוגדר כברירת מחדל:
```
ping PRODUCER_IP_ADDRESS
```
  מחליפים את PRODUCER_IP_ADDRESS בכתובת ה-IP של מכונה וירטואלית של ספק מתוך טווח כתובות ה-IP החופף.

ניהול חפיפה של כתובות יעד באמצעות ניתוב על סמך מדיניות

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

כשמגדירים ניתוב על סמך מדיניות כדי לנהל חפיפה ביעדים, בוחרים יציאות יעד לשימוש באפליקציות לצרכנים. תעבורה שמיועדת לאחת מהיציאות האלה עוברת דרך הממשק של Private Service Connect אל רשת המשנה של הצרכן, ותעבורה אחרת עוברת דרך ממשק ברירת המחדל אל רשת המשנה של הספק.

מתחברים ל-VM של ממשק Private Service Connect.
אם הפקודה iproute2 לא זמינה, מתקינים אותה.
מוודאים שיש לכם הרשאת כתיבה לקובץ הבא: /etc/iproute2/rt_tables
יוצרים טבלת ניתוב. מוסיפים נתיב ברירת מחדל לממשק Private Service Connect:
```
echo "200 pscnet" >> /etc/iproute2/rt_tables \
sudo ip route add default dev OS_INTERFACE_NAME table pscnet
```
מחליפים את OS_INTERFACE_NAME בשם מערכת ההפעלה האורחת של ממשק Private Service Connect, לדוגמה, ens5.
מוסיפים מסלול לטווח חופף של רשת משנה צרכנית דרך שער ברירת המחדל:
```
sudo ip route add CONSUMER_SUBNET_RANGE via GATEWAY_IP dev OS_INTERFACE_NAME table pscnet
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CONSUMER_SUBNET_RANGE: טווח כתובות ה-IP של רשת המשנה של הצרכן.
- ‫GATEWAY_IP: כתובת ה-IP של שער ברירת המחדל עבור רשת המשנה של הממשק Private Service Connect.
מעדכנים את טבלת הניתוב כך שמנות יוצאות מהמכונה הווירטואלית הזו ישתמשו בכתובת ה-IP של הממשק ככתובת ה-IP של המקור:
```
sudo ip route add GATEWAY_IP src INTERFACE_IP dev OS_INTERFACE_NAME table pscnet
```
מחליפים את INTERFACE_IP בכתובת ה-IP של ממשק Private Service Connect.
מוסיפים כלל IP שחל על כל התנועה שמיועדת ליעד של יציאת אפליקציית הצרכן:
```
sudo ip rule add dport CONSUMER_PORT table pscnet
```
מחליפים את CONSUMER_PORT ביציאה שהגדרתם לתעבורה למכונה הווירטואלית לצרכן.
כדי לוודא שהמערכת מנתבת מנות למכונה הווירטואלית הנכונה על סמך יציאת היעד שלהן, צריך לבצע את הפעולות הבאות:
1. יוצרים מכונות וירטואליות לבדיקה ברשתות של היצרן והצרכן, ששתיהן משתמשות באותה כתובת IP מטווח כתובות ה-IP החופף.
2. מגדירים שרת HTTP בכל מכונה וירטואלית לבדיקה. מגדירים את מכונת ה-VM לבדיקה של אפליקציית הצרכן להאזנה ביציאה שהגדרתם לאפליקציית הצרכן. מגדירים את המכונה הווירטואלית של הבדיקה של ה-Producer להאזנה ביציאה שונה מזו שהגדרתם לאפליקציית ה-Consumer.
3. מוודאים שכללי חומת האש מוגדרים כך שתעבורת HTTP מותרת למכונות הווירטואליות של הבדיקה.
4. באמצעות היציאה שהגדרתם לאפליקציית הצרכן, שולחים GETבקשה לכתובת ה-IP של הבדיקה, ואז מוודאים שהגעתם למופע הנכון:
```
curl TEST_IP_ADDRESS:CONSUMER_PORT
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫TEST_IP_ADDRESS: כתובת ה-IP של המכונות הווירטואליות לבדיקה.
  - ‫CONSUMER_PORT: היציאה של אפליקציית הלקוח.
5. משתמשים ביציאה שהגדרתם למכונה הווירטואלית של בדיקת ההפקה, GETשולחים בקשה לכתובת ה-IP של הבדיקה ומוודאים שהגעתם למופע הנכון:
```
curl IP_ADDRESS:PRODUCER_PORT
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫IP_ADDRESS: כתובת ה-IP של המכונות הווירטואליות לבדיקה.
  - ‫PRODUCER_PORT: היציאה שהגדרתם למכונה הווירטואלית של בדיקת הייצור.