פתרון בעיות בהגדרות (original) (raw)

פתרון בעיות בהגדרות

המדריך הזה יכול לעזור לכם לפתור בעיות נפוצות ב-Cloud NAT.

בעיות נפוצות

מכונות וירטואליות יכולות לגשת לאינטרנט באופן לא צפוי, ללא Cloud NAT

אם המכונות הווירטואליות (VM) או מופעי הקונטיינרים יכולים לגשת לאינטרנט בלי Cloud NAT, אבל אתם לא רוצים שהם יוכלו, כדאי לבדוק את הבעיות הבאות:

• בודקים אם לממשק הרשת של המכונה הווירטואלית יש כתובת IP חיצונית. אם לממשק הרשת מוקצית כתובת IP חיצונית,‏ Google Cloudמבצע באופן אוטומטי NAT אחד-לאחד למנות שהמקורות שלהן תואמים לכתובת ה-IP הפנימית הראשית של הממשק. מידע נוסף זמין במאמר מפרטים של Cloud NAT.
  כדי לבדוק אם למכונה וירטואלית יש כתובת IP חיצונית, אפשר לעיין במאמר בנושא שינוי או הקצאה של כתובת IP חיצונית למכונה קיימת.
• מוודאים שאשכול Google Kubernetes Engine ‏ (GKE) הוא אשכול פרטי. לכל מכונה וירטואלית של צומת באשכול לא פרטי יש כתובת IP חיצונית, כך שכל צומת יכול להשתמש בנתיבים ברשת הענן הווירטואלי הפרטי (VPC) שהקפיצה הבאה שלהם היא שער האינטרנט שמוגדר כברירת מחדל, בלי להסתמך על Cloud NAT. למידע נוסף, כולל איך אשכולות לא פרטיים פועלים עם שערים של Cloud NAT, אפשר לעיין במאמר בנושא אינטראקציה עם Compute Engine.
• מציגים את המסלולים ברשת הענן הווירטואלי הפרטי (VPC) ומחפשים מסלולים שיכולים לספק קישוריות לאינטרנט דרך קפיצה הבאה ששונה משער ברירת המחדל לאינטרנט. לדוגמה:
  • מסלולים סטטיים שהקפיצות הבאות שלהם הן מכונות וירטואליות, מאזני עומסים פנימיים של רשתות מסוג passthrough או מנהרות Cloud VPN, עשויים לספק קישוריות לאינטרנט באופן עקיף. לדוגמה, למכונות וירטואליות של הצעד הבא או למכונות וירטואליות של בק-אנד של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי יכולות להיות כתובות IP חיצוניות משלהן, או שמנהרת Cloud VPN יכולה להתחבר לרשת שמציעה גישה לאינטרנט.
  • מסלולים דינמיים שנלמדו מרשתות מקומיות על ידי נתבי Cloud ברשת ה-VPC שלכם עשויים להתחבר לרשת שמציעה גישה לאינטרנט.
• חשוב לזכור שלמסלולים מותאמים אישית אחרים ברשת ה-VPC שלכם עשויים להיות סדרי עדיפויות גבוהים יותר מאשר למסלולים שה-next hop שלהם הם שערים של אינטרנט שמוגדרים כברירת מחדל. מידע על האופן שבוGoogle Cloud מעריך מסלולים זמין במאמר בנושא החלת ניתוב וסדר.

לא נוצרים יומנים

• מוודאים שהרישום ביומן של NAT מופעל.
• חשוב לוודא שהתצוגה של היומנים לא מסננת את היומנים שאתם מחפשים. הוראות מפורטות מופיעות במאמר צפייה ביומנים.
• מוודאים שכלל חומת אש לא חוסם את התנועה. כללי חומת אש שחוסמים תעבורת נתונים יוצאת (egress) מוחלים לפני שהתעבורה נשלחת לשער NAT. אפשר להשתמש בניהול כללי חומת אש כדי לראות אם כללי היציאה המותאמים אישית חוסמים תעבורה יוצאת.
• כדאי לעיין במאמר בנושא סוגים של Cloud NAT. יכול להיות שהיעד של התנועה לא מטופל על ידי NAT.

חלק מהיומנים לא נכללים

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

מנות שהושמטו עם הסיבה: אין משאבים

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

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

במאמר איך מצמצמים את השימוש ביציאות מוסבר איך לצמצם את השימוש ביציאות.

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

מנות נשמטות כשהקצאת יציאות דינמית מוגדרת

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

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

• אם אפשר להגדיל את מספר החיבורים בקצב איטי יותר, ל-Cloud NAT יש יותר זמן להקצאת עוד יציאות.
• אם המכונות הווירטואליות יוצרות חיבורי TCP, אפשר להגדיר במכונות הווירטואליות ערך גדול יותר ל-tcp_syn_retries, וכך המערכת תקבל יותר זמן ליצירת החיבור והסיכויים שהחיבור יצליח יגדלו.
  לדוגמה, במכונות וירטואליות של Linux, אפשר לראות את ההגדרה הנוכחית:
  sysctl net.ipv4.tcp_syn_retries

במקרה הצורך, אפשר להגדיל את ההגדרה:
sudo sysctl -w net.ipv4.tcp_syn_retries=NUM

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

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

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

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

• משביתים את המיפוי ללא תלות בנקודת הקצה. כך החיבור החדש מכתובת IP ומפורט מסוימים יכול להשתמש בכתובת IP ובפורט אחרים של מקור NAT מאלה שבהם השתמש לפני כן. השבתה או הפעלה של מיפוי ללא תלות בנקודת קצה לא משבשות חיבורים קיימים.
• הגדלת מספר יציאות ה-NAT המינימלי שמוגדר כברירת מחדל לכל מופע של מכונה וירטואלית, כדי שתהליך שמירת היציאות יוכל להקצות לכל מכונת VM של לקוח יותר טפלים של כתובת IP של מקור NAT ויציאת מקור. כך קטן הסיכוי ששני טפלים או יותר של כתובת IP של לקוח ויציאת מקור זמנית יקבלו את אותו טפל של כתובת IP של מקור NAT ויציאת מקור.
• בודקים כמה יציאות מקוריות זמניות נמצאות בשימוש:
  • במכונות וירטואליות של Linux:
    netstat -an | egrep 'ESTABLISHED|TIME_WAIT|CLOSE_WAIT' | wc -l
  • למכונות וירטואליות של Windows:
    netstat -tan | findstr "ESTABLISHED TIME_WAIT CLOSE_WAIT" | find /c /v ""
• מגדירים את המכונות הווירטואליות כך שישתמשו בקבוצה גדולה יותר של יציאות מקור זמניות:
  • במכונות וירטואליות של Linux:
    * כדי לראות את טווח היציאות שמוגדר, מריצים את הפקודה הבאה:
    cat /proc/sys/net/ipv4/ip_local_port_range
    * אפשר להגדיר את ip_local_port_range למספר המקסימלי של יציאות מקור זמניות (64,512) באמצעות הפקודה הבאה:
    echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
  • למכונות וירטואליות של Windows:
    * אפשר להשתמש בפקודות הבאות כדי לראות אילו טווחי יציאות מוגדרים:
    netsh int ipv4 show dynamicport tcp
    netsh int ipv4 show dynamicport udp
    * אפשר להגדיר את מספר יציאות ה-TCP וה-UDP הזמניות של המקור למספר המקסימלי האפשרי (64,512) באמצעות הפקודות הבאות:
    netsh int ipv4 set dynamicport tcp start=1024 num=64512
    netsh int ipv4 set dynamicport udp start=1024 num=64512
    * בצמתים של Google Kubernetes Engine, אפשר להשתמש ב-DaemonSet עם הרשאות כדי להפוך את ההגדרה הזו לאוטומטית.
• באשכולות GKE, משביתים את ה-NAT של המקור שמתבצע בכל צומת עבור חבילות שנשלחות ליעדים רלוונטיים. אפשר לעשות זאת באחת משתי דרכים:
  • כדי לעשות את זה, צריך להטמיע את התג ip-masq-agent ולהוסיף את היעדים שמעניינים אתכם לרשימה של nonMasqueradeCIDRs.
  • כשיוצרים אשכול, אפשר להשבית את SNAT עבור יעדים שמוגדרים כברירת מחדל ולא מוסתרים באמצעות הדגל --disable-default-snat.

מנות שהתקבלו ונמחקו

שער Cloud NAT שומר טבלת מעקב אחר חיבורים כדי לאחסן פרטים של חיבורים פעילים ומיפויים של כתובות IP ויציאות – איך כתובות IP ויציאות של מכונות וירטואליות מתורגמות לכתובות IP ויציאות של NAT. שער Cloud NAT משליך מנות נתונים של תעבורת כניסה אם בטבלת מעקב החיבורים אין רשומה לחיבור.

יכולות להיות כמה סיבות לכך שרשומת החיבור לא מופיעה בטבלה:

• הזמן הקצוב לתפוגה של חיבור TCP פעיל הסתיים בגלל חוסר פעילות.
• נקודת קצה חיצונית לא מצליחה ליצור חיבור חדש לפני שפג הזמן הקצוב לתפוגה של חיבור TCP זמני במצב סרק. לדוגמה, Google Cloud resource יוזם חיבור עם TCP SYN, אבל נקודת הקצה החיצונית לא מגיבה עם SYN ACK.
• נקודת קצה חיצונית, כמו כלי לבדיקת קישוריות, מנסה להתחבר לכתובת IP של NAT וליציאה. שירות Cloud NAT לא מקבל חיבורים נכנסים לא רצויים. רשומות של סוגי החיבורים האלה לא יופיעו בטבלת החיבורים. לכן, כל החבילות שיתקבלו יימחקו.
• אם מסירים כתובות IP של NAT מהשער בזמן שחיבורי NAT עדיין פעילים, מיפויי ה-NAT הופכים ללא תקפים, והחיבורים האלה מוסרים באופן מיידי מטבלת מעקב החיבורים – כל תנועה חוזרת נמחקת.

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

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

• כדאי להשתמש ב_מנגנוני keepalive_ באפליקציה, כדי שחיבורים שפועלים לאורך זמן יוכלו להישאר פתוחים למשך תקופה ארוכה יותר.
• להגדיל את הערך של TCP Transitory Connection Idle Timeout (פסק זמן של חיבור זמני ל-TCP), כדי שלנקודות קצה חיצוניות שמקבלות תנועה (שמגיעה ממקורות) דרך שער Cloud NAT יהיה יותר זמן להגיב וליצור את החיבור. Google Cloud
• אם הקטנתם באופן משמעותי את ערך ברירת המחדל, כדאי להגדיל את הערך של הזמן הקצוב לתפוגה של חיבור TCP פעיל ללא פעילות.

צריך להקצות עוד כתובות IP

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

כדי לעקוב אחרי כשלים שנגרמים בגלל מספר לא מספיק של כתובות IP, צריך ליצור התראה למדד nat_allocation_failed. המדד הזה מוגדר כ-true אם Google Cloud לא מצליח להקצות מספיק כתובות IP למכונה וירטואלית בשער NAT. מידע על כללי מדיניות התראות מופיע במאמר הגדרת כללי מדיניות התראות.

צמצום השימוש ביציאות

אתם יכולים לצמצם את מספר היציאות שכל מכונה וירטואלית משתמשת בהן במצבים שבהם אי אפשר או לא רצוי להקצות יותר כתובות IP של NAT.

כדי לצמצם את השימוש ביציאות, מבצעים את השלבים הבאים:

1. משביתים את האפשרות מיפוי ללא תלות בנקודת קצה.
2. מפעילים את האפשרות הקצאה דינמית של יציאות. כדי להשתמש בהקצאת יציאות דינמית, צריך להגדיר מספר מינימלי של יציאות לכל מכונה וירטואלית ומספר מקסימלי של יציאות לכל מכונה וירטואלית. שירות Cloud NAT מקצה באופן אוטומטי מספר של טפלי NAT של כתובות IP של מקורות ויציאות מקורות, בין המספר המינימלי למספר המקסימלי של יציאות, כולל. שימוש במספר נמוך של יציאות כמספר המינימלי של היציאות מצמצם את הבזבוז של כתובות IP של מקור NAT ושל טפלים של יציאות מקור במכונות וירטואליות עם פחות חיבורים פעילים. אם נתקלתם בפסק זמן לחיבור בזמן הקצאת יציאות, כדאי לעיין במאמר הקטנת מספר אובדן המנות באמצעות הקצאה דינמית של יציאות.
3. קובעים את המספר המינימלי האפשרי של יציאות שנדרש כדי לענות על הצרכים שלכם. יש כמה שיטות לעשות את זה, ורוב השיטות מסתמכות על בדיקת מספר היציאות שבשימוש (compute.googleapis.com/nat/port_usage) כקלט לתהליך קבלת ההחלטות. במאמר הצגת השימוש ביציאות מוסבר איך בודקים את השימוש ביציאות. בהמשך מופיעות שתי דוגמאות לשיטות לקביעת מספר יציאות מינימלי:
   • כדאי להשתמש בערך הממוצע של compute.googleapis.com/nat/port_usage לאורך תקופה מייצגת עבור מספר מייצג של מכונות וירטואליות.
   • כדאי לבדוק את הערך השכיח ביותר של compute.googleapis.com/nat/port_usage לאורך תקופה מייצגת עבור מספר מייצג של מכונות וירטואליות.
4. קובעים את המספר הנמוך ביותר האפשרי של יציאות שמתאים לצרכים שלכם. שוב, כדאי לבדוק את compute.googleapis.com/nat/port_usage כקלט לתהליך קבלת ההחלטות. כנקודת התחלה למספר המקסימלי של הפורטים, כדאי להשתמש בערך המקסימלי של compute.googleapis.com/nat/port_usage לאורך תקופת זמן מייצגת עבור מספר מייצג של מכונות וירטואליות. חשוב לזכור: הגדרה של מספר מקסימלי גבוה מדי עלולה למנוע ממכונות וירטואליות אחרות לקבל טפלים של כתובת IP של מקור NAT ויציאת מקור.
5. כדי למצוא את הערכים הנכונים של יציאות מינימליות ומקסימליות, צריך לבצע בדיקות חוזרות. הוראות לשינוי מספרי היציאות המינימליים והמקסימליים מופיעות במאמר שינוי יציאות מינימליות או מקסימליות כשמוגדרת הקצאה דינמית של יציאות.
6. בודקים את הערכים של פסק הזמן של NAT, את המשמעויות שלהם ואת ערכי ברירת המחדל שלהם. אם אתם צריכים ליצור במהירות סדרה של חיבורי TCP לאותו יעד 3-tuple, כדאי לקצר את זמן ההמתנה של TCP כדי ש-Cloud NAT יוכל לעשות שימוש חוזר מהר יותר בכתובת ה-IP של המקור ב-NAT וב-tuples של יציאת המקור. כך Cloud NAT יכול להשתמש באותו 5-tuple מהר יותר, במקום להשתמש ב-5-tuple ייחודי, מה שעשוי לדרוש הקצאה של כתובת IP נוספת של מקור NAT ושל טופלים של יציאת מקור NAT לכל מכונה וירטואלית ששולחת. הוראות לשינוי הגדרות הזמן הקצוב לתפוגה של NAT מפורטות במאמר שינוי הגדרות הזמן הקצוב לתפוגה של NAT.

שאלות נפוצות

הגבלה אזורית ל-Cloud NAT

האם אפשר להשתמש באותו שער Cloud NAT ביותר מאזור אחד?

לא. אי אפשר לשייך שער Cloud NAT ליותר מאזור אחד, רשת VPC או Cloud Router.

אם אתם צריכים לספק קישוריות לאזורים אחרים או לרשתות VPC, אתם יכולים ליצור עבורם שערים נוספים של Cloud NAT.

האם כתובות ה-IP החיצוניות של NAT שמשמשות שערים של Cloud NAT הן גלובליות או אזוריות?

שערי Cloud NAT משתמשים ב_כתובות IP חיצוניות אזוריות_ ככתובות IP של NAT. למרות שהם אזוריים, אפשר לנתב אותם באופן ציבורי. למידע על דרכים שונות להקצאה או להקצאה של כתובות IP של NAT, אפשר לעיין במאמר בנושא כתובות IP של NAT.

מתי אפשר להשתמש ב-Cloud NAT ומתי אי אפשר

האם Cloud NAT חל על מכונות, כולל מכונות וירטואליות של צומתי GKE, שיש להן כתובות IP חיצוניות?

בדרך כלל לא. אם לממשק הרשת של מכונה וירטואלית יש כתובת IP חיצונית, ‏ Google Cloud תמיד מבצעת NAT של אחד לאחד למנות שנשלחות מכתובת ה-IP הפנימית הראשית של ממשק הרשת בלי להשתמש ב-Cloud NAT. עם זאת, יכול להיות ש-Cloud NAT עדיין יספק שירותי NAT למנות שנשלחות מטווחים של כתובות IP של כינויים של אותו ממשק רשת. פרטים נוספים זמינים במאמרים מפרטים של Cloud NAT ואינטראקציה עם Compute Engine.

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

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

כשמכונת ה-VM של המקור שולחת מנה ליעד, מתבצע תרגום כתובות רשת (NAT) של המקור על ידי Public NAT לפני שהמנה מועברת למופע השני. ‫NAT ציבורי מבצע NAT של יעד (DNAT) לתשובות מהמופע השני לראשון. דוגמה מפורטת מופיעה במאמר הגדרת NAT ציבורי בסיסי ותהליך העבודה.

האם אפשר להשתמש ב-Private NAT לתקשורת בין מכונות וירטואליות באותה רשת VPC?

לא, Private NAT לא מבצע NAT על תעבורת נתונים בין מכונות וירטואליות באותה רשת VPC.

אין תמיכה בחיבורים נכנסים לא רצויים

האם Cloud NAT מאפשר חיבורים נכנסים (לדוגמה, SSH) למכונות ללא כתובות IP חיצוניות?

לא, שירות Cloud NAT לא תומך בחיבורים נכנסים לא רצויים. מידע נוסף זמין במאמר מפרטים של Cloud NAT. עם זאת,יכול להיות שקצה הרשת של Google Cloudיגיב לפינגים אם כתובת ה-IP של היעד היא כתובת IP חיצונית של שער Cloud NAT שיש לה מיפויים פעילים של יציאות לפחות למופע אחד של מכונת VM. כדי לראות את כתובות ה-IP שהוקצו לשער Cloud NAT, משתמשים בפקודה gcloud compute routers get-nat-ip-info. יכול להיות שכתובות IP חיצוניות שמסומנות כ-IN_USE יגיבו לפינגים.

אם אתם צריכים להתחבר למכונה וירטואלית שאין לה כתובת IP חיצונית, כדאי לעיין במאמר בחירת אפשרות חיבור למכונות וירטואליות פנימיות בלבד. לדוגמה, כחלק מההגדרה של Cloud NAT ב-Compute Engine, אתם מתחברים למכונה וירטואלית ללא כתובת IP חיצונית באמצעות שרת proxy לאימות זהויות (IAP).

‫Cloud NAT ויציאות

למה למכונה וירטואלית יש מספר קבוע של יציאות (64 כברירת מחדל)?

כששער Cloud NAT מספק NAT למכונה וירטואלית, הוא שומר טפלים של כתובת מקור ויציאת מקור בהתאם לנוהל שמירת היציאות.

מידע נוסף זמין במאמר דוגמאות להזמנת ניוד.

האם אפשר לשנות את המספר המינימלי של יציאות ששמורות למכונה וירטואלית?

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

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

אפשר להקטין את המספר המינימלי של יציאות לכל מכונה וירטואלית אחרי שיוצרים את שער Cloud NAT?

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

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

לא. כל היציאות הנוספות שמשמשות טווחים משניים נשמרות על ידי המכונות הווירטואליות עד שמקטינים את ההגדרה minimum ports per VM. כשמגדירים את Cloud NAT למיפוי של טווחי משנה (כינוי) לרשתות משנה, ‏ Cloud NAT מקצה לפחות 1,024 יציאות לכל מופע, על סמך הליך שמירת היציאות.

אם עוברים לשימוש בטווחי כתובות ראשיים בלבד, שירות Cloud NAT שומר את היציאות הנוספות שהוקצו למקרים שבהם היציאות האלה כבר הוקצו למופעים. אחרי שמשנים את הטווחים שבהם Cloud NAT חל על Primary only, מספר היציאות שמוקצות למופעים האלה לא משתנה עד שמקטינים גם את ההגדרה minimum ports per VM.

כדי לצמצם את מספר היציאות שמוקצות לאינסטנסים האלה, אחרי המעבר לטווחים ראשיים, צריך להקטין את ההגדרה minimum ports per VM (מספר היציאות המינימלי לכל מכונה וירטואלית). אחרי שהערך הזה יורד, Cloud NAT משנה אוטומטית את מספר היציאות שהוקצו לכל מכונה, וכך מצמצם את צריכת היציאות.

‫Cloud NAT ושירותים אחרים של Google

האם Cloud NAT מאפשר גישה לממשקי API ולשירותים של Google?

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

איך חוקרים בעיות ב-Cloud NAT באמצעות Gemini Cloud Assist

אתם יכולים להשתמש בGemini Cloud Assist investigations כדי לפתור בעיות ב-Cloud NAT.

כדי ליצור חקירה:

1. נכנסים לדף Cloud NAT במסוף Google Cloud .
   כניסה ל-Cloud NAT
2. לוחצים על שער Cloud NAT.
3. בדף פרטי שער Cloud NAT, לוחצים על חקירה.
4. בחלונית ליצירת חקירה, מתארים את הבעיה שרוצים לפתור, בוחרים את המשאבים המושפעים ולוחצים על יצירה כדי להתחיל את החקירה.
   מידע נוסף זמין במאמר יצירת חקירה.

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

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

• קבלת תמיכה