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

המדריך הזה יכול לעזור לכם לפתור בעיות נפוצות ב-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 ציבורי, והמיפוי העצמאי של נקודות הקצה (EIM) מופעל, יכול להיות שאובדן המנות נגרם בגלל התנגשות עצמאית של נקודות קצה. אם כן, dropped_sent_packets_count הסיבה היא ENDPOINT_INDEPENDENCE_CONFLICT. מידע נוסף על מדדים זמין במאמר שימוש במדדים של מופעי מכונות וירטואליות.

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

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

  • הגדלת מספר היציאות המינימלי שמוגדר כברירת מחדל ל-NAT לכל מופע של מכונה וירטואלית, כדי שתהליך שמירת היציאות יוכל להקצות לכל מכונת לקוח יותר טפלים של כתובת 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 פעיל בלי פעילות.
  • נקודת קצה חיצונית לא הגיבה לבקשת החיבור לפני שפג הזמן הקצוב לתפוגה של חיבור 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 (צריך להקצות לפחות X כתובות IP נוספות כדי לאפשר לכל המכונות הווירטואליות לגשת לאינטרנט).
  • הערך של המדד nat_allocation_failed הוא true.

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

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

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

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

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

  1. משביתים את האפשרות מיפוי ללא תלות בנקודת קצה.

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

שאלות נפוצות

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

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

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