פתרון בעיות במכונות וירטואליות עם כמה ממשקי רשת

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

לא ניתן ליצור מכונה וירטואלית עם כמה ממשקים

יכול להיות שתופיע אחת מהודעות השגיאה הבאות:

Invalid value for field 'resource': ''. Too many network interfaces. The maximum number of network interfaces allowed for this machine type is.

אם מופיעה הודעת השגיאה הזו, סימן שניסיתם ליצור יותר ממשקים מהמספר המקסימלי של ממשקים שנתמכים על ידי סוג המכונה של המופע. אפשר לעיין בטבלה בנושא מספר הממשקים המקסימלי.
Subnetworks must be distinct for NICs attached to a VM.

אם קיבלתם את ההודעה הזו, סימן שניסיתם ליצור יותר מממשק אחד באותה רשת משנה. כל ממשק רשת צריך להיות מצורף לתת-רשת אחרת.
Networks must be distinct for non-default NICs attached to a VM.

אם קיבלתם את ההודעה הזו, סימן שניסיתם ליצור יותר מממשק אחד באותה רשת. כדאי לבדוק את הדברים הבאים:
- כדי לצרף כמה ממשקי רשת לאותה רשת VPC, כל ממשק רשת צריך להיות מצורף לאותה רשת כמו ממשק nic0.
- צירוף ממשקי רשת מרובים לאותה רשת VPC אינו נתמך עבור NICs דינמיים או ממשקי Private Service Connect.
Subnetwork CIDR ranges must be non-overlapping for NICs attached to a VM.

אם ההודעה הזו מופיעה, טווחי ה-CIDR שמשויכים לממשקי מכונת ה-VM חופפים. טווחי ה-CIDR האלה כוללים את כל הטווחי המשנה הראשיים שמשויכים לממשקי מכונות וירטואליות, וגם טווחי משנה משניים שמשמשים לטווחי כתובות IP חלופיות. כל ממשק מצורף לרשת משנה שאסור שתהיה חפיפה בינה לבין רשתות משנה של ממשקים אחרים. לדוגמה, אם אתם מנסים ליצור את המופע באזור REGION_A, אתם יכולים לבדוק את טווחי ה-CIDR הראשיים של רשתות המשנה באמצעות הפקודה הבאה או באמצעות מסוףGoogle Cloud .
```
gcloud compute networks subnets list --regions REGION_A
NAME                REGION      NETWORK          RANGE
default             REGION_A  default          10.138.0.0/20
overlapping-subnet  REGION_A  test-network     10.138.8.0/24
```
כדי לבדוק את טווחי ה-CIDR של רשתות המשנה המשניות, משתמשים בפקודה הבאה או במסוףGoogle Cloud .
```
gcloud compute networks subnets describe overlapping-subnet --region REGION_A
```
```
...
ipCidrRange: 10.128.8.0/24
...
secondaryIpRanges:
- ipCidrRange: 10.138.8.0/24
  rangeName: conflicting-range
```
הערה: לא מתבצעת בדיקה של טווחי כתובות משניים שנמצאים ברשת משנה שמשויכת לממשק של מכונה וירטואלית, אבל לא נמצאים בשימוש הממשק של המכונה הווירטואלית, כדי לראות אם יש חפיפה.
Multiple network interfaces are not supported on legacy networks.

אם ההודעה הזו מופיעה, סימן שאתם מנסים ליצור את המופע ברשת מדור קודם. מכונות עם כמה ממשקים לא נתמכות ברשתות מדור קודם. כדי לבדוק אם רשת היא רשת מדור קודם, אפשר להשתמש באחת מהשיטות הבאות:
- נכנסים לדף VPC Networks במסוף Google Cloud ובודקים את העמודה Mode.
- מריצים את הפקודה gcloud compute networks list ובודקים את השדה SUBNET_MODE.
Required 'compute.instances.create' permission for 'projects/PROJECT_ID/zones/ZONE/instances/test-inst'

אם מופיעה ההודעה הזו, לחשבון שאיתו התחברתם אין את הרשאות ה-IAM שנדרשות ליצירת מופע. מידע נוסף על התפקידים שנדרשים ליצירת מכונות זמינות במאמר הרשאות, IAM ומכונות עם כמה ממשקי רשת. אתם יכולים לבדוק אם מדיניות ה-IAM שמשויכת לפרויקט מעניקה לכם אחד מהתפקידים הבאים: OWNER, ‏ EDITOR או compute.instanceAdmin.v1. כדי ליצור מכונות וירטואליות ב-VPC משותף, צריך גם את התפקיד compute.networkUser. בדוגמה הבאה, לחשבון email2@gmail.com אין הרשאות IAM מספיקות ליצירת מכונה. הוראות מפורטות יותר זמינות במדריך IAM במאמר הענקה, שינוי וביטול של הרשאות גישה למשאבים.
```
gcloud projects get-iam-policy PROJECT_ID
bindings:
- members:
  - user:email1@gmail.com
    role: roles/owner
- members:
  - serviceAccount:our-project-123@appspot.gserviceaccount.com
  - serviceAccount:123456789012-compute@developer.gserviceaccount.com
    role: roles/editor
- members:
  - user:email2@gmail.com
    role: roles/viewer
etag: BwUjMhXbSPU=
version: 1
```
אתם יכולים לבקש מבעלי הפרויקט או מהעורכים שלו להקצות לכם את התפקיד OWNER, EDITOR או compute.instanceAdmin.v1. תצטרכו גם את התפקיד compute.networkUser אם אתם משייכים ממשק כלשהו לרשת משנה ששייכת ל-VPC משותף.
```
gcloud projects set-iam_policy --member user:email2@gmail.com --role roles/editor
```

לא הצלחתי להתחבר לכתובת ה-IP הפנימית של ממשק משני

בודקים את הכללים של חומת האש כדי לוודא שהם מאפשרים קישוריות לממשק המשני של המכונה הווירטואלית. כדי לבדוק את זה, אפשר לעיין בכללי חומת האש של הרשת שמצורפת לממשק המשני. אפשר לעשות את זה במסוף Google Cloud : לוחצים על רשת ה-VPC המתאימה. אפשר גם להשתמש בפקודה gcloud הבאה.
```
gcloud compute firewall-rules list --filter='network:NETWORK_NAME'
```
בודקים אם אתם מנסים להתחבר לממשק משני מכתובת אינטרנט או מחוץ לרשת של הממשק המשני. אפשר להתחבר לכתובת IP פנימית של ממשק רק מתוך הרשת שלו. אם אתם צריכים להגיע לממשק הזה מחוץ לרשת, אתם יכולים להקצות כתובת IP חיצונית לממשק המשני.
בודקים אם אתם מנסים להתחבר לכתובת ה-IP הפנימית של הממשק המשני מחוץ לרשת המשנה שהממשק המשני מצורף אליה, או מרשת משנה אחרת של אותה רשת או מרשת משותפת. במאמר Multiple Network Interfaces per instance מוסבר על האינטראקציה בין קישור בין רשתות שכנות (peering) של VPC לבין מכונות וירטואליות עם כמה ממשקים. כדי להגיע לממשקים משניים מחוץ לרשת המשנה של הממשק, יכול להיות שתצטרכו להגדיר נתיבים במכונה הווירטואלית. במאמר מפרטים מוסבר איך תוכניות DHCP מגדירות מסלולי ברירת מחדל במכונה הווירטואלית.
אם אתם מנסים לגשת לכתובת IPv6, כדאי לעיין גם במאמר לא מצליח להתחבר לכתובת IPv6 של ממשק משני.

לא הצלחתי להתחבר לממשק משני באמצעות כתובת IP חיצונית

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

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

אי אפשר להתחבר לכתובת IPv6 של ממשק משני

אם אתם מנסים לגשת לכתובת IPv6, צריך לוודא שבמכונה הווירטואלית מותקנת גרסה google-guest-agent‏20220603.00 ואילך. מידע נוסף על ניהול גרסאות זמין במאמר סביבת אורח.google-guest-agent

אם יש לכם גרסה קודמת של google-guest-agent, הממשקים המשניים לא מקבלים מסלול רשת משנה של IPv6. מומלץ לעדכן את סוכן האורח כדי שהנתיבים יוגדרו בצורה נכונה.

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

sudo sysctl -w net.ipv6.conf.INTERFACE_NAME.accept_ra_rt_info_max_plen=128

מחליפים את INTERFACE_NAME בשם הממשק, לדוגמה, eth1 או ens5.

נתקלתי בבעיות קישוריות כשהשתמשתי במסכת רשת שלא הייתה ‎ /32

כברירת מחדל, שרת המטא-נתונים של המכונה מגיב רק לבקשות ARP עבור שער ברירת המחדל.

כדי להגדיר ממשקים עם מסכת רשת שונה מ-/32, צריך ליצור תמונה באמצעות הדגל --guest-os-features MULTI_IP_SUBNET ולהשתמש בה כדי ליצור את המכונה. לדוגמה, אם אתם משתמשים בתמונה שמבוססת על debian-9, אתם יכולים ליצור תמונה באמצעות הפקודה הבאה:

gcloud compute images create debian-9-multi-ip-subnet \
     --source-disk debian-9-disk \
     --source-disk-zone ZONE_A \
     --guest-os-features MULTI_IP_SUBNET

כדי לראות את התכונות של האורח שהוגדרו באימג', מריצים את הפקודה gcloud compute images describe באימג' של האורח.

gcloud compute images describe debian-9-multi-ip-subnet

מידע נוסף על יצירת תמונות בהתאמה אישית זמין במאמר בנושא יצירה, מחיקה והוצאה משימוש של תמונות בהתאמה אישית.

לא ניתן לזהות את שם המארח הפנימי של מכונה וירטואלית עם כמה ממשקי רשת

כשמבצעים שאילתת DNS עם שם מארח פנימי, היא מתורגמת לממשק הרשת הראשי (nic0) של המכונה.

אם nic0 מצורף לרשת VPC ששונה מרשת ה-VPC של המופע ששולח את שאילתת ה-DNS, שאילתת ה-DNS תיכשל. רזולוציית DNS פנימית מתבצעת רק בתוך רשת VPC נתונה. מידע נוסף מופיע במאמר בנושא DNS פנימי ב-Compute Engine.

מוצגת שגיאה כשמנסים למחוק NIC דינמי על ידי עדכון של מאפייני המופע

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

אם נתקלתם בבעיה הזו, תוכלו לנסות את הפתרונות הבאים:

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

מופיעה שגיאה כשמוחקים NIC דינמי על ידי עדכון ההגדרות של MIG

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

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

פתרון בעיות באמצעות המסוף הטורי

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