עודכן לפני חודש
רוב המכשירים יושבים מאחורי חומות אש מסוג NAT שמאפשרות תעבורה יוצאת אך חוסמות תעבורה נכנסת בלתי מבוקשת. שני מכשירים המוגנים על ידי NAT מתמודדים עם מבוי סתום בלתי אפשרי: אף אחד מהם לא יכול לפנות אל האחר ראשון.
ניקוב חורים ב-UDP פותר זאת בטריק אלגנטי: שני המכשירים פונים בו-זמנית, ובכך כל אחד מהם יוצר את הפתח שהאחר זקוק לו.
המבוי הסתום
כשהמכשיר שלך שולח נתונים דרך NAT, הראוטר יוצר מיפוי זמני — הכתובת הפנימית והפורט שלך מקושרים לכתובת חיצונית ופורט חיצוני. תעבורה חוזרת מגיעה אליך דרך מיפוי זה. אך תעבורה נכנסת בלתי מבוקשת נדחית.
שני מכשירים מאחורי NAT לא יכולים להתחבר. מכשיר A לא יכול לשלוח ל-B כי הראוטר של B דוחה את החבילה הבלתי צפויה. מכשיר B לא יכול לשלוח ל-A מאותה הסיבה. A לא יכול להגיע ל-B עד ש-NAT של B ייצור מיפוי, אך NAT של B לא ייצור את המיפוי הזה עד ש-B ישלח משהו ראשון.
הפתרון המסורתי: שרתי ממסר שמעבירים הכל בין עמיתים. זה עובד, אך מוסיף השהיה. לשיחות וידאו או משחקים מרובי משתתפים, ההשהיה הזאת פוגעת בחוויה.
הדפיקה הבו-זמנית
ניקוב חורים ב-UDP מנצל התנהגות NAT צפויה: ברגע שחבילת UDP יוצאת יוצרת מיפוי, הראוטר מקבל חבילות נכנסות המגיעות לאותו פורט חיצוני — אפילו ממקורות שהמכשיר לא יצר עמם קשר ישיר.
הטכניקה דורשת שלושה משתתפים: שני עמיתים ושרת מפגש נגיש לציבור.
שני העמיתים מתחברים לשרת המפגש. כש-A שולח חבילת UDP לשרת, ה-NAT של A יוצר מיפוי — נניח, כתובת IP חיצונית 203.0.113.10 בפורט 5000. השרת מתעד זאת. B עושה את אותו הדבר, ומופיע אולי ב-198.51.100.20 בפורט 6000.
כעת השרת יודע את שתי נקודות הקצה הציבוריות. הוא מודיע ל-A היכן B נמצא, ומודיע ל-B היכן A נמצא.
הנה הטריק: שני העמיתים שולחים חבילות UDP לנקודות הקצה הציבוריות של האחר בו-זמנית.
כש-A שולח לנקודת הקצה של B (198.51.100.20:6000), החבילה כנראה נדחית — NAT של B עדיין לא יצר מיפוי עבור A. אך חבילה יוצאת זו מ-A נוקבת חור ב-NAT של A. פורט 5000 עכשיו מאזין.
בו-זמנית, B שולח לנקודת הקצה של A (203.0.113.10:5000). חבילה זו נוקבת חור ב-NAT של B — ומגיעה בדיוק לפורט שבו NAT של A מקבל כעת תעבורה.
שני העמיתים שולחים חבילות שתידחנה — אך בהידחותן, הן יוצרות את התנאים לקבלה.
תוך מילישניות, שני החורים קיימים וחבילות זורמות בשני הכיוונים. תפקיד שרת המפגש הסתיים. העמיתים מתקשרים ישירות.
STUN ו-TURN
ארגון IETF תיקנן תהליך זה:
שרתי STUN (Session Traversal Utilities for NAT) עוזרים למכשירים לגלות את נקודות הקצה הציבוריות שלהם. אתה שולח בקשה; השרת מודיע לך איזו כתובת ופורט הוא ראה. שרתי STUN הם קלי משקל — הם משקפים מידע בלבד, ולעולם אינם ממסרים תעבורה.
שרתי TURN (Traversal Using Relays around NAT) הם הגיבוי כשניקוב חורים נכשל. שרת TURN מממסר בפועל תעבורה בין עמיתים. פעולה זו פוגעת ביתרונות של רוחב הפס וההשהיה שמציע חיבור ישיר, אך מבטיחה קישוריות כשאף דבר אחר לא עובד.
יישומים מודרניים משתמשים ב-ICE (Interactive Connectivity Establishment), שמנסה מספר אסטרטגיות במקביל: חיבור ישיר, ניקוב חורים דרך STUN, ממסר דרך TURN. האפשרות הטובה ביותר שעובדת מנצחת.
מתי זה נכשל
ניקוב חורים עובד עם רוב ראוטרי הצרכנים, אך מספר גורמים עשויים לשבש אותו:
NAT סימטרי מקצה פורטים חיצוניים שונים בהתאם ליעד. כש-A פונה לשרת STUN, הוא מקבל פורט חיצוני אחד. כש-A שולח ל-B, הוא מקבל פורט שונה לחלוטין. מידע נקודת הקצה מ-STUN הופך לחסר תועלת. כ-11% ממשתמשי האינטרנט יושבים מאחורי סוג זה של NAT.1
NAT מוגבל-פורטים מקבל רק חבילות נכנסות מכתובות שהמכשיר כבר פנה אליהן. חבילות של B ל-A נדחות אלא אם הן מגיעות מהכתובת המדויקת ש-A שלח אליה — אך A שלח ל-NAT של B, לא ל-B ישירות.
חומות אש ארגוניות עשויות לחסום UDP לחלוטין או לבחון תעבורה בשכבת היישום.
TCP אינו עובד באותה הדרך. לחיצת היד התלת-שלבית של TCP יוצרת תרחיש "פתיחה בו-זמנית" שרוב יישומי NAT אינם מטפלים בו כראוי. ניקוב חורים הוא בבסיסו טכניקת UDP — אם כי מחקר עדכני מראה שעם סנכרון תזמון מדויק, TCP ו-QUIC יכולים להגיע לאחוזי הצלחה דומים.2
ניקוב חורים מצליח בכ-70–82% מהתרחישים בעולם האמיתי.3 ליתרת המקרים, ממסרי TURN מספקים קישוריות במחיר של השהיה.
היכן השתמשת בזה
שיחות VoIP סללו את הדרך לטכניקה זו. Skype השתמש בניקוב חורים כדי לכונן זרמי שמע ישיר, מפני שקול בזמן אמת אינו יכול לסבול השהיה של ממסר.
משחקים מרובי משתתפים נוקבים חורים ללא הרף. כש-10 מילישניות קובעות מי מנצח בקרב יריות, לא ניתן לנתב תעבורה דרך שרתים מרכזיים. לקוחות המשחק משתמשים בשרתי מפגש להתאמת משחקים, ואז מכוננים חיבורי UDP ישירים לניהול המשחק עצמו.
WebRTC הביא ניקוב חורים לדפדפנים. כשאתה מצטרף לוועידת וידאו, ICE בוחן באופן אוטומטי את תצורת הרשת שלך, מנסה ניקוב חורים, וחוזר לממסרים במידת הצורך. אתה לוחץ "הצטרף" ומקבל וידאו עמית-לעמית.
הטכניקה מניעה גם שיתוף קבצים, כלי שולחן עבודה מרחוק ותקשורת מכשירי IoT. בכל מקום שדרוש חיבור ישיר תוך ישיבה מאחורי NAT, גרסה כלשהי של ניקוב חורים הופכת זאת לאפשרי.
שאלות נפוצות על ניקוב חורים ב-UDP
למה זה נקרא "ניקוב חורים"?
השם מתאר מה שקורה: אתה יוצר פתח זמני בחומת אש שחוסמת בדרך כלל תעבורה נכנסת בלתי מבוקשת. החבילה היוצאת "נוקבת" את הגנות ה-NAT, ומשאירה פתח לתעבורה החוזרת.
האם ניקוב חורים פוגע באבטחה?
במידה מינימלית. החור קיים רק כל עוד תעבורה זורמת — מיפויי NAT פגים לאחר תקופות של חוסר פעילות, בדרך כלל כ-5 דקות עבור UDP.4 החור מקבל רק חבילות UDP, לא חיבורים שרירותיים. ה-NAT שלך עדיין חוסם תעבורה בלתי מבוקשת לכל שאר הפורטים.
למה ניקוב חורים ב-TCP אינו עובד כל כך טוב?
TCP דורש לחיצת יד תלת-שלבית (SYN, SYN-ACK, ACK) ליצירת חיבורים. שני הצדדים ששולחים חבילות SYN בו-זמנית יוצרים תרחיש "פתיחה בו-זמנית" שרוב יישומי NAT אינם מטפלים בו כראוי. מכיוון ש-UDP אינו מבוסס חיבור, טריק השליחה הבו-זמנית פועל בו בצורה אמינה.
מה קורה אם שרת המפגש נופל?
חיבורי עמית-לעמית קיימים ממשיכים לעבוד — לאחר התיאום הראשוני הם אינם זקוקים לשרת. אך לא ניתן לכונן חיבורים חדשים עד שהשרת חוזר לפעולה. יישומים קריטיים מתחזקים מספר שרתי מפגש לצורכי יתירות.
האם ספק האינטרנט שלי יכול לחסום ניקוב חורים?
כן. ספקי אינטרנט המשתמשים ב-NAT ברמת הספק (CGN) או המיישמים NAT סימטרי בקנה מידה רחב עשויים לשבור ניקוב חורים. חלק מרשתות הסלולר סובלות מבעיה זו. יישומים חוזרים לממסרי TURN, שעובדים אך מוסיפים השהיה.
מקורות
האם דף זה היה מועיל?