פורטי UDP קבועים יכולים לדלג על העברת פורטים, אבל לא כל NAT

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

ההשוואה שחומת אש מבצעת

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

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

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

קיבוע פורט אחד בכל קצה

פורט ה־UDP המוגדר כברירת מחדל של OpenVPN הוא 1194, ו־lport קובע את פורט המקור שממנו הוא שולח. קבעו את שני העמיתים וכל רביעייה יוצאת תצביע על פורט שהאחר מאזין לו:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

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

היכן הרביעייה מפסיקה להתאים

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

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

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

בדרך כלל צד אחד נכשל ראשון

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

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

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

מתי להפסיק לנסות

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

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

נסו תחילה את הסידור הישיר, ואחר כך רשמו מה ראיתם. התנהגות ה־NAT והלכידה שהראתה אותה שוות יותר משורת הפורטים שבסופו של דבר השתמשתם בה, מפני שהרשת הבאה תהיה שונה. מדריך OpenVPN 2.6 מתעד lport ואת אפשרויות ה־remote שזה תלוי בהן.