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

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

בעיות נפוצות

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

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

  • בודקים אם לממשק הרשת של המכונה הווירטואלית יש כתובת IP חיצונית. אם לממשק הרשת מוקצית כתובת IP חיצונית,‏ Cloud de Confiance by S3NSמבצע באופן אוטומטי 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 שלכם עשויים להיות סדרי עדיפויות גבוהים יותר מאשר למסלולים שהנקודות הבאות שלהם הן שערים של אינטרנט שמוגדרים כברירת מחדל. מידע על האופן שבוCloud de Confiance מעריך מסלולים זמין במאמר על התאמה וסדר של ניתוב.

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

  • מוודאים שהרישום ביומן של NAT מופעל.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • אם אפשר להגדיל את מספר החיבורים בקצב איטי יותר, ל-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 reason הוא 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 של המקור שמבוצע בכל צומת עבור חבילות שנשלחות ליעדים שמעניינים אתכם. אפשר לעשות את זה באחת משתי דרכים:

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

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

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

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

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

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

התמודדות עם ההשפעה על האפליקציה

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

  • כדאי להשתמש במנגנוני keepalive באפליקציה כדי שחיבורים שפועלים לאורך זמן יוכלו להישאר פתוחים למשך זמן ארוך יותר.
  • להגדיל את הזמן הקצוב לתפוגה של חיבור TCP זמני במצב סרק כדי לתת לנקודות קצה חיצוניות זמן נוסף להגיב למשאבים, וכך לאפשר את יצירת החיבור. Cloud de Confiance
  • אם הקטנתם באופן משמעותי את ערך ברירת המחדל, כדאי להגדיל את הזמן הקצוב לתפוגה של חיבור TCP פעיל.

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

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

שורש הבעיה תיאור הבעיה פתרון
הקצית כתובות באופן ידני, אבל לא הקצית מספיק כתובות בהתחשב בשימוש הנוכחי שלך בניוד.
  • Cloud de Confiance במסוף מוצגת השגיאה You need to allocate at least 'X' more IP addresses to allow all instances to access the internet.
  • הערך של המדד nat_allocation_failed הוא true.

מבצעים אחת מהפעולות הבאות:
חרגתם ממגבלה קשיחה של כתובות IP של NAT.

כדי לעקוב אחרי כשלים שנגרמים בגלל מספר לא מספיק של כתובות IP, צריך ליצור התראה למדד nat_allocation_failed. המדד הזה מוגדר לערך true אם Cloud de Confiance לא מצליח להקצות מספיק כתובות 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 כתובות יעד, כדאי לקצר את זמן ההמתנה של TCP כדי ש-Cloud NAT יוכל לעשות שימוש חוזר מהר יותר בכתובת ה-IP של מקור NAT ובטווח היציאות של המקור. כך, שירות 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 חיצונית,‏ Cloud de Confiance תמיד מבצעת NAT של אחד לאחד למנות שנשלחות מכתובת ה-IP הפנימית הראשית של ממשק הרשת בלי להשתמש ב-Cloud NAT. עם זאת, יכול להיות ש-Cloud NAT עדיין יספק שירותי NAT למנות שנשלחות מטווחים של כתובות IP של כינויים של אותו ממשק רשת. פרטים נוספים זמינים במאמרים מפרטים של Cloud NAT ואינטראקציה עם Compute Engine.

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

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

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

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

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

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

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

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

אם אתם צריכים להתחבר למכונה וירטואלית שאין לה כתובת IP חיצונית, כדאי לעיין במאמר בחירת אפשרות חיבור למכונות וירטואליות פנימיות בלבד. לדוגמה, כחלק מההגדרה של Cloud NAT ב-Compute Engine, אתם מתחברים למכונה וירטואלית ללא כתובת IP חיצונית באמצעות Identity-Aware Proxy.

‫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 הראשי של רשת משנה, Cloud de Confiance מופעלת אוטומטית גישה פרטית ל-Google. מידע נוסף זמין במאמר אינטראקציה של גישה פרטית ל-Google.

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

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

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

  1. נכנסים לדף Cloud NAT במסוף Cloud de Confiance .

    כניסה ל-Cloud NAT

  2. לוחצים על שער Cloud NAT.

  3. בדף פרטי שער Cloud NAT, לוחצים על חקירה.

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

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

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

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