מדוע חצות NAT חשובה כאשר רשתות מקשות על חיבורים ישירים

חלק מבעיות החיבור אינן נגרמות מהאפליקציה שבה אתה משתמש. הם מגיעים מנתיב הרשת בין התקנים.

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

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

מה NAT עושה ברשתות יומיומיות

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

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

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

זו ההגדרה הבסיסית למעבר NAT.

מהי חצה NAT?

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

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

אין תשובה אוניברסלית אחת מכיוון שהתנהגות NAT משתנה. תקנים כגון IETF RFC 4787 מתארים התנהגות NAT עבור UDP ומסבירים מדוע העקביות חשובה עבור אפליקציות בזמן אמת כגון תקשורת מולטימדיה ומשחקים מקוונים. אותה בעיה רחבה מופיעה בקטגוריות רבות של אפליקציות מודרניות: שיחות, כלי שיתוף פעולה, משחקים, כלי גישה מרחוק, מערכות בסגנון עמית לעמית ואפליקציות דמויות VPN, כולם יכולים להיות מושפעים מהאופן שבו רשתות מטפלות בתעבורה.

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

מהו UDP ניקוב חורים?

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

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

הביטוי נשמע אגרסיבי, אבל הקונספט רגיל יותר ממה שהשם מרמז. מדובר בעבודה עם הכללים הקיימים של הנתב לתנועה יוצאת וחוזרת. מחקר יסודי מ-Bryan Ford, Pyda Srisuresh ו-Dan Kegel מתאר ניקוב חורים כגישה מעשית המשמשת יישומים מבוססי UDP, תוך שימת דגש על מגבלה מרכזית: שום טכניקת מעבר פועלת בכל הגדרות של NAT.

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

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

מדוע לפעמים חיבורים ישירים נכשלים

קישוריות ישירה עלולה להיכשל מכמה סיבות רגילות:

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

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

היכן מתאימים נפילות ממסר

כאשר הקישוריות הישירה אינה אמינה, חלק מהמערכות משתמשות בממסר: שתי נקודות הקצה מתחברות החוצה לשרת ביניים, והשרת מעביר ביניהן תעבורה. IETF RFC 5766 מתאר את TURN, קיצור של מעבר באמצעות ממסרים סביב NAT, כפרוטוקול לתקשורת בעזרת ממסר כאשר תקשורת עמיתים ישירה אינה אפשרית במצבים מסוימים של NAT.

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

זו הסיבה שעיצובי קישוריות רבים מעדיפים לנסות תחילה נתיב ישיר, ואז לרדת אחורה בעת הצורך. IETF RFC 8445 מתאר את ICE כגישה של מסלולי סטנדרטים למעבר NAT עבור תקשורת מבוססת UDP המשתמשת במושגים STUN ו-TURN כדי לגלות ולבדוק נתיבים אפשריים. זה לא אומר שכל כלי הקשור ל-VPN משתמש ב-ICE, STUN או TURN. זה פשוט מראה דפוס הנדסי נפוץ: בדוק איזה נתיב עובד, ואז השתמש ב-fallback אם קישוריות ישירה אינה זמינה.

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

מה זה אומר עבור קוראי VPN Satelites

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

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

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

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

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

כיצד לקרוא תביעות מעבר NAT בזהירות

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

שאלות שימושיות כוללות:

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

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

שאלות נפוצות

האם מעבר NAT זהה ל-VPN?

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

האם ניקוב חורים UDP תמיד עובד?

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

האם הפסקות ממסר טובות יותר מחיבורים ישירים?

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

האם מאמר זה אומר ש-VPN Satelites משתמש ב-STUN, TURN, ICE, בממסרים או בהעברת יציאות?

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

האם מעבר של NAT יכול לעקוף כללי רשת?

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

השורה התחתונה

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

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