پورت‌های ثابت 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 که این به آن‌ها وابسته است.