NAT סימטרי ו-VPN: יש לבדוק את המיפוי, לא את התווית
מיפוי תלוי-קצה משפיע על גילוי עמיתים, ולא על מנהרה רגילה מלקוח לשרת. מדדו את הפורט, ואם המסלול הישיר נכשל עברו לממסר.
שרשור תמיכה מסתיים בפסק הדין „NAT סימטרי, ה-VPN לא יעבוד כאן”, ואז מתקינים מחדש את הלקוח שלוש פעמים בלי סיבה. התווית מזיקה מפני שהיא עונה על שאלה שאיש לא שאל. לקוח שמתחבר החוצה לשרת קבוע יוצר מיפוי ברגע שהוא שולח את החבילה הראשונה, והתשובה מורשית לחזור לפי כללים שכמעט כל רשת מיישמת. מה שמיפוי תלוי-קצה באמת מסבך הוא שני עמיתים שמנסים להגיע זה לזה בו בזמן, וזה מבחן אחר.
שתי שאלות מסתתרות מאחורי תווית אחת
השאלה הראשונה היא אם מארח מאחורי הרשת הזאת יכול לפתוח שיחה לכתובת ציבורית ופורט ידועים. עבור לקוח מנהרה זה המקרה הרגיל, והתשובה היא כמעט תמיד כן. הנתב רושם את המקור הפנימי, מקצה פורט חיצוני, ומעביר את התשובה מפני שהיא שייכת לשיחה שהחלה מבפנים.
השאלה השנייה היא אם שני מארחים מאחורי רשתות שונות יכולים לגלות מסלול משותף ולשלוח זה לזה בלי שרת באמצע. זה תלוי באופן שבו כל רשת מקצה את הפורטים החיצוניים האלה, וזה המקום היחיד שבו להתנהגות המיפוי יש חשיבות.
ערבוב של השניים מייצר את האבחון השגוי הקלאסי: תכונת עמית-לעמית נכשלת, מישהו מריץ בדיקת סוג NAT, רואה את הקטגוריה הגרועה ביותר, ומסיק שגם המנהרה הרגילה לא יכולה לעבוד. המנהרה מעולם לא הייתה הדבר שנכשל.
מיפוי וסינון הם שני מאפיינים נפרדים
המינוח של RFC מדויק יותר מהשמות שהספקים משתמשים בהם, וכדאי להעביר אותו לכרטיס כי הוא מכריע בוויכוחים. מיפוי הוא הדרך שבה מוקצה הפורט החיצוני. סינון הוא אילו חבילות נכנסות מורשות לעבור. רשת יכולה להיות מחמירה באחד ונדיבה בשני, והשילוב הוא מה שפרוטוקול עמית-לעמית צריך לשרוד.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
השורה השלישית היא מה שרוב נתבי הצרכנים והמפעילים הסלולריים מתכוונים אליו ב״סימטרי”. שימו לב שהתווית מתארת רק את ההקצאה. רשת עם מיפוי כזה וסינון נדיב עדיין יכולה לקבל חבילות נכנסות לפורט שהוקצה זה עתה, ולכן חירור חורים מצליח בחלק מהן ונכשל באחרות.
לסינון יש שלושה מקרים משלו ושם משלו לכל אחד. כתיבת „NAT סימטרי” בכרטיס כשמתכוונים ל„סינון תלוי כתובת ופורט” שולחת את האדם הבא לפרק הלא נכון במדריך. השניים מתנהגים אחרת בבדיקה, ולכן הטעות אינה אקדמית.
מדדו את המיפוי במקום לתת לו שם
אפשר לצפות בפורט המוקצה ישירות מצד השרת של כל שירות UDP שאתם שולטים בו. התחילו לכידה במארח הציבורי, שלחו מהלקוח, וקראו את פורט המקור שאיתו הגיעה החבילה:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820שורת נקודת הקצה היא השימושית משלושתן, מפני ש-WireGuard רושם את הכתובת והפורט האחרונים שקיבל מכל עמית. השוו את הפורט הזה לזה שהלקוח חושב שהוא משתמש בו. הם ייבדלו בכל פעם שמתרחשת תרגום כלשהו, והשאלה החשובה היא אם הערך נשאר יציב.
חזרו על התצפית מול פורט יעד שני או שרת שני והשוו שוב. אם הפורט החיצוני משתנה לפי יעד, המיפוי תלוי בכתובת ובפורט. אם הוא נשאר זהה, הרשת נותנת לכם מיפוי אחד ולגילוי יש סיכוי.
כלים מבוססי STUN מדווחים על אותה סיווג בשלב אחד, וכדאי להשתמש בהם כשהרשת מתירה UDP יוצא לשרת STUN ציבורי. כשהיא אינה מתירה, שיטת הלכידה שלמעלה עדיין עובדת ואינה דורשת דבר מלבד מארח שכבר בשליטתכם.
בחרו תיקון שמתאים לכשל
אם התכונה שנכשלה היא עמית-לעמית, התשובות הנתמכות הן ממסר, שירות מפגש ששני העמיתים יכולים להגיע אליו, או טופולוגיה אחרת. TURN קיים בדיוק בשביל זה, ומוצר שמספק ממסר משלו אומר לכם שהוא מצפה שכמה רשתות יהיו עוינות.
אם התכונה שנכשלה היא מנהרה רגילה, התנהגות המיפוי אינה הבעיה שלכם ושום דבר מהאמור לעיל אינו חל. בדקו שהלקוח באמת שולח, שהשרת רואה את החבילה, ושהתשובה חוזרת. הרצף הזה הוא שלוש תצפיות והוא אינו דורש לדעת דבר על קטגוריית ה-NAT של הנתב.
מה שלא עובד הוא פיזור שינויי פורט מקומיים עד שמשהו מתחבר. שינוי פורט המקור של הלקוח אינו משנה את אופן הקצאת המיפויים ברשת. הצלחה מקרית בניסיון החמישי היא חיובי שגוי, והיא תצוטט כתיקון במשך חודשים.
תעדו את הארכיטקטורה, לא את פסק הדין
הערה שימושית אומרת איזה פרוטוקול, לאיזה כיוון נפתחת השיחה, אם יש ממסר במסלול, ומה נצפה על החוט. „NAT סימטרי, לא עובד” אינו שמיש, מפני שהוא שגוי לגבי המנהרה וחסר מידע לגבי מסלול העמית בו בזמן.
כללו את יציבות הפורט שנמדדה ואת התנהגות הסינון אם בדקתם אותם. שתי העובדות האלה מאפשרות למישהו אחר לחזות אם תכונה חדשה תעבוד ברשת ההיא בלי לחזור על כל החקירה. הן גם מזדקנות טוב יותר מקטגוריית ספק שמשמעותה שונה במעט בכל עמוד עזרה.
לבסוף, החזיקו בהישג יד את המינוח של RFC 4787 כשאתם כותבים את זה. שימוש במונחים מדויקים עולה משפט אחד ומונע מהקורא הבא לחזור על אותו אבחון שגוי, וזו כל המטרה של כתיבת ההערה מלכתחילה.