بررسی‌کننده پورت می‌گوید باز است؟ چرا بازیکنان Minecraft هنوز نمی‌توانند بپیوندند

کسی یک بررسی پورت اجرا می‌کند، کلمه باز را می‌بیند و سرور را حل‌شده می‌پندارد. معنای واقعی آن نتیجه باریک است: از مکان بررسی‌کننده، در همان لحظه، یک اتصال TCP به آن نشانی و پورت پذیرفته شد. این هیچ چیزی درباره دست‌دادن پروتکل Minecraft، تأیید حساب یا اینکه آیا سرور بازیکن را به جهانی راه داده است نمی‌گوید.

این‌ها چهار لایه متفاوت‌اند و شکست در هر یک از آن‌ها همان جمله را از بازیکن بیرون می‌آورد: کار نکرد.

یک کاوشگر فقط چیزی را می‌آزماید که می‌تواند ببیند

اتصال TCP زمانی کامل می‌شود که هر دو طرف دست‌دادن سه‌طرفه را تمام کنند، که پایین‌تر از هر چیزی است که بازی می‌داند. کاوشگر گزارش می‌دهد که شنونده‌ای وجود داشته و از مکان شبکه‌ای خود پاسخ داده است. نمی‌تواند به شما بگوید که شنونده خود بازی است، چون هر فرآیندی می‌تواند یک پورت را اشغال کند و اتصال بپذیرد.

مکان به اندازه نتیجه اهمیت دارد. یک بررسی‌کننده در اینترنت عمومی یک مسیر از یک شبکه را می‌آزماید. بررسی‌کننده‌ای که گرداننده از داخل همان شبکه اجرا می‌کند مسیر کاملاً دیگری را می‌آزماید، و نتیجه مثبت در آنجا تقریباً هیچ چیزی درباره آنچه بازیکن دور می‌گذراند نمی‌گوید. حتی دو بررسی‌کننده متفاوت نزد دو ارائه‌دهنده متفاوت می‌توانند به دلایلی که هیچ ربطی به سرور شما ندارند با هم اختلاف داشته باشند.

زمان هم مهم است. نتیجه کاوشگر لحظه‌ای را توصیف می‌کند که اجرا شده، و یک اتصال خانگی با نشانی پویا یا قاعده هدایت تغییریافته می‌تواند پاسخ واقعی را چند دقیقه بعد جابه‌جا کند. نشانی عمومی، پورت، خانواده نشانی و زمان را همراه با حکم ثبت کنید، وگرنه مشاهده قابل تکرار نیست. بررسی را از شبکه‌ای واقعاً متفاوت تکرار کنید، نه از تلفنی روی همان اتصال.

چهار لایه میان یک سوکت و یک بازیکن

توالی‌ای را تصور کنید که یک کلاینت متصل‌شونده واقعاً انجام می‌دهد. نخست نشانی را تفکیک می‌کند، سپس اتصال TCP به پورت منتشرشده باز می‌کند، سپس با پروتکل خود بازی برای مذاکره و احراز هویت صحبت می‌کند، و در پایان سرور تصمیم می‌گیرد که آیا آن هویت اجازه ورود به جهان را دارد. هر لایه امضای شکست خودش را دارد و فقط لایه اول برای بررسی‌کننده پورت قابل مشاهده است.

پورت پیش‌فرض Java Edition برابر 25565 است، اما گرداننده می‌تواند پورت بیرونی دیگری منتشر کند و آن را به داخل هدایت کند، پس شماره‌ای که بازیکن تایپ می‌کند لزوماً شماره‌ای نیست که سرور می‌بیند. بررسی‌کننده‌ای که به پورت بیرونی اشتباه نشانه رفته باشد در حالی که سرور کاملاً سالم است «بسته» گزارش می‌دهد، و این رایج‌ترین هشدار نادرست در کل این حوزه است.

نام‌ها یک گام دیگر بالای پورت اضافه می‌کنند. اگر بازیکن یک نام میزبان تایپ کند، تفکیک باید نشانی منتشرشده را برگرداند، و روی ماشینی در داخل شبکه ممکن است به‌جای آن یک نشانی خصوصی برگرداند. این شکست دیوار آتش نیست و هیچ میزان هدایت پورت آن را تغییر نمی‌دهد.

چرا بازیکن داخل مسیر دیگری می‌رود

بازیکنی در همان LAN، یا در یک VPN که به آن LAN می‌رسد، تلاش می‌کند از داخل به نشانی عمومی برسد. درخواست به نشانی بیرونی روتر می‌رود و روتر باید آن را به داخل بازگرداند، که همان ترتیبی است که معمولاً hairpinning یا انعکاس NAT نامیده می‌شود. برای اینکه این کار کند، هم ترجمه رفت و هم مسیر بازگشت باید هم‌تراز باشند، و بسیاری از روترهای خانگی آن را اصلاً پیاده‌سازی نمی‌کنند.

به همین دلیل مهمان بیرونی می‌پیوندد و کسی که کنار سرور نشسته نمی‌تواند. مسیر بیرونی واقعاً درست است؛ انحراف داخلی همان چیزی است که شکست می‌خورد، و به گونه‌ای شکست می‌خورد که از صفحه بازیکن مثل مشکل سرور به نظر می‌رسد. گزارش خود سرور تعیین می‌کند کدام یک رخ داده، چون اتصالی که هرگز ترجمه نشده هرگز به آن نمی‌رسد.

دو اصلاح صادقانه و یک عادت بد وجود دارد. گزینه‌های خوب این است که بگذارید بازیکنان داخلی از نشانی خصوصی یا نام split-DNS استفاده کنند که در داخل به نشانی خصوصی تفکیک می‌شود، یا اگر این قابلیت وجود دارد و درست کار می‌کند، انعکاس را روی روتر فعال کنید. عادت بد باز کردن پورت‌های بیشتر یا خاموش کردن دیوار آتش میزبان است، که نمی‌تواند بر ترجمه‌ای که روتر هرگز انجام نداده اثر بگذارد.

مستندات Netgate درباره انعکاس NAT تفاوت بیرون و داخل و گزینه split-DNS را با جزئیات بیشتری توصیف می‌کند. آن را توصیفی از سازوکار بخوانید، نه وعده‌ای که هر ارائه‌دهنده VPN یا روتر خاصی همه گونه‌های loopback را پشتیبانی می‌کند.

از هر دیدگاه شواهد جمع کنید

برای هر آزمون بنویسید چه کسی آن را اجرا کرد، از کجا، در چه زمانی، علیه کدام نشانی و پورت، و سرور چه چیزی ثبت کرد. رد شدن از بازی با دلیل روشن در کنسول سرور یافته‌ای متفاوت از اتصالی است که هرگز نرسید، و این دو به جهت‌های مخالف می‌روند.

اگر بازیکنان دور مجاز می‌پیوندند و یک بازیکن محلی نمی‌تواند، مسیر محلی پرسش باقی‌مانده است و شایسته بررسی جداگانه است: کلاینت از کدام نشانی استفاده کرد، روتر با ترجمه چه کرد، و آیا سرور اصلاً هیچ تلاش اتصالی ثبت کرد. این سه واقعیت را به صاحب شبکه بدهید، به‌جای باز کردن تصادفی پورت‌ها.