فهرست خالی بازی‌های LAN روی OpenVPN؟ مسیر کشف را بررسی کنید
یافتن یک بازی میزبانی‌شده و پیوستن به آن دو مسیر جداگانه است. نشانی نشست را آزمون کنید، آنچه لابی اعلام می‌کند را بخوانید، سپس رله را با پل بسنجید.
پینگ کردن نشانی تونل یک بازیکن دیگر و دیدن بازی میزبانی‌شدهٔ او دو دستاورد متفاوت است. فهرست لابی معمولاً به تبادل کشفی وابسته است که برای یک شبکهٔ محلی واحد نوشته شده، در حالی که نشست بازی یک اتصال معمولی به نشانی و درگاه است. اگر فهرست خالی را خطای مسیریابی بدانید، به سمت پلی می‌روید که شاید به آن نیاز نداشته باشید، پس پیش از تغییر هر چیزی دو پرسش را از هم جدا کنید.
پیوستن به نشست را از یافتن آن جدا کنید
پیوستن ناموفق به مسیرها، قواعد دیوار آتش و سرویسی که گوش می‌دهد اشاره دارد. پیوستن موفق با فهرست خالی به کشف یا به نشانی‌ای اشاره دارد که اعلامیه حمل می‌کند. این دو نتیجه به کار کاملاً متفاوتی می‌رسند و تنها با آزمودن آگاهانهٔ اولی می‌توانید آن‌ها را از هم تشخیص دهید.
پیش از دست زدن به پیکربندی VPN نتیجه را بنویسید. این ارزان‌ترین آزمون در کل بررسی است و نیمی از فضای طراحی را حذف می‌کند. نشانی‌ای را که به کار بردید هم یادداشت کنید، زیرا نقطهٔ مرجع هر آزمون بعدی می‌شود. بدون این خط در یادداشت‌هایتان، مقایسهٔ بعدی فقط گمان است.
پیش از دست زدن به تونل، پیوستن مستقیم را بیازمایید
اگر بازی گزینهٔ اتصال مستقیم را عرضه می‌کند، از نشانی تونل میزبان و درگاه مستندشدهٔ بازی استفاده کنید و احراز هویت خود بازی و قواعد دیوار آتش میزبان را دست‌نخورده بگذارید. پیوستن موفق مشکل را به کشف محدود می‌کند. پیوستن ناموفق هنوز بررسی خودش را می‌طلبد و هیچ رله‌ای آن را درست نمی‌کند.
فرض نکنید که درگاه کشف و درگاه نشست یک عدد هستند. بازی‌ها معمولاً روی یک درگاه UDP اعلام می‌کنند و بازیکنان را روی درگاه دیگری می‌پذیرند، و رله‌ای که برای درگاه اشتباه ساخته شده فهرستی می‌دهد که همچنان خالی می‌ماند.
بررسی کنید که فرایند میزبانی کدام آداپتور را انتخاب کرده است. فرایندی که به نشانی LAN خانه گره خورده همان نشانی را اعلام می‌کند و بازیکن دور نمی‌تواند به آن مسیریابی کند، حتی وقتی اعلامیه می‌رسد. فهرست ممکن است پر شود و پیوستن تنها به همین دلیل شکست بخورد.
بفهمید پخش همگانی کجا متوقف می‌شود
تونل TUN مسیریابی‌شده بسته‌های IP را میان همتاها جابه‌جا می‌کند و پخش همگانی محلی را در شبکهٔ هر همتا بازتولید نمی‌کند. نشانی پخش همگانی محدود 255.255.255.255 درون همان رابطی می‌ماند که آن را منتشر می‌کند، و پخش همگانی به سمت زیرشبکه موردی جداست، نه مجوزی کلی برای اینکه مسیریاب‌ها اعلامیه‌ها را سیل‌آسا بفرستند.
این ویژگی طراحی است، نه نقصی که با یک گزینه وصله شود. OpenVPN، و تنظیم client-to-client ترافیک همتاها درون تونل را اداره می‌کند و رلهٔ کشف نیست، هرچند در بسیاری از رشته‌ها برای همین منظور پیشنهاد می‌شود. رله مؤلفه‌ای جداست با پیکربندی خودش و شیوه‌های شکست خودش. این گمان که گزینه‌ای موجود از قبل آن را پوشش می‌دهد، رایج‌ترین دلیل گیر کردن این بررسی است.
کشف چندپخشی همین مشکل را با ردهٔ نشانی دیگری دارد و به مسیریابی چندپخشی یا رله نیاز دارد، نه به استثنای پخش همگانی.
وقتی رله توجیه دارد، آن را باریک نگه دارید
اگر کشف خودکار الزام است، نخست تبادل واقعی را مشخص کنید: پخش همگانی یا چندپخشی، نشانی مقصد، درگاه UDP، رابطی که آن را می‌فرستد و نشانی درون پاسخ. رله‌ای متناسب با پروتکل و محدود به این پنج واقعیت بسیار باریک‌تر از گستردن یک قطعهٔ کامل Ethernet است.
فرستادن بسته بدون تغییر ممکن است همچنان کافی نباشد. اگر محتوا به گیرنده بگوید به نشانی‌ای وصل شود که به آن نمی‌رسد، رله پاسخ بی‌فایده‌ای می‌دهد، از این رو باید رابط خود بازی یا تنظیم نشانی اعلام‌شده پیش از وجود هر رله‌ای آزموده شود.
رله را به رابط‌ها و همتاهایی که به آن نیاز دارند محدود کنید و تعریف کنید پاسخ‌ها چگونه درخواست‌کننده را می‌یابند. تکرار پخش‌های همگانی نامرتبط سرویس‌های محلی دیگر را آشکار می‌کند و حلقه‌هایی می‌سازد که اشکال‌زدایی بعدی‌شان دردناک است.
پل تنها وقتی طراحی به Ethernet نیاز دارد
قاب‌های Ethernet درون TAP سفر می‌کنند، پس تونل TAP می‌تواند به دامنهٔ پخش همگانیِ آگاهانه پل‌شده تعلق داشته باشد. صرفاً dev tun به dev tap تغییر دادن آن پل را نمی‌سازد، پیکربندی سرور را سازگار نمی‌کند و برنامه را وادار به انتخاب رابط تازه نمی‌کند. راهنمای پل‌سازی OpenVPN چیدمان گسترده‌تر را توصیف می‌کند، نه درمان یک لابی خالی را.
پل‌سازی طرح نشانی را هم تخت می‌کند، از این رو تصمیم شایستهٔ دلیلی فراتر از بی‌حوصلگی است. دو شبکه‌ای که جدا بودند یکی می‌شوند و هر سرویس در هر طرف پخش‌های همگانی طرف دیگر را می‌بیند. این پیامد باید پیش از فعال کردنش در دفتر تغییرات باشد. هیچ قاعده‌ای نیست که مشتری‌های بازی باید در بازهٔ 192.168 باشند؛ طرحی بدون همپوشانی برگزینید و محدودیت‌های همان بازی را بررسی کنید، به جای اینکه تونل را دوباره شماره‌گذاری کنید چون یک نوشتهٔ انجمن چنین کرد.
در پایان دو نتیجه را جدا نگه دارید: اینکه آیا می‌توان به میزبان پیوست و اینکه آیا پاسخ کشف مقصدی را اعلام می‌کند که بازیکن دیگر واقعاً بتواند به کار ببرد. درست کردن دومی بدون تأیید اولی همان راهی است که مردم در نهایت پلی را برای مشکلی نگه می‌دارند که هرگز دربارهٔ پخش همگانی نبود.