ماینکرفت از طریق VPN: کدام نشانی در فهرست سرورها می‌آید؟
نقطه پایانی VPN تونل را می‌سازد؛ بازی به نشانی خصوصی میزبان و درگاه نیاز دارد. نقش‌ها را به نشانی‌ها نسبت دهید، سپس شنونده، مسیر و قواعد میزبان را بررسی کنید.
نوشتن نقطه پایانی VPN در فهرست سرورهای ماینکرفت منطقی به نظر می‌رسد و هر بار شکست می‌خورد، چون آن نشانی تونل را پایان می‌دهد نه اینکه بازی را میزبانی کند. بازیکنی که به همان VPN پیوسته است از قبل مسیری به میزبان بازی دارد، پس ورودی باید میزبان و درگاهی را که بازی روی آن گوش می‌دهد نام ببرد. این دو را درست کنید و بقیه مشکل دسترس‌پذیری معمول سرویس است، که فهرست بازبینی بسیار کوتاه‌تری از آنچه در نگاه اول به نظر می‌رسد است.
دو نشانی، دو وظیفه
یکی از نشانی‌ها زیرساخت عمومی است: نقطه پایانی انتقال که بسته‌های رمزگذاری‌شده را بین همتاها حمل می‌کند. دیگری نشانی خصوصی ماشینی است که سرور اختصاصی را اجرا می‌کند. این دو قابل تعویض نیستند، و جایگزین کردن یکی با دیگری اتصال ردشده یا زمانی تمام‌شده تولید می‌کند که شبیه مشکل دیوار آتش است.
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
با درگاه پیش‌فرض، بازیکن 10.60.0.20:25565 را می‌نویسد و هیچ چیز دیگر. صفحه دانلود سرور Java شرکت موجانگ 25565 را به‌عنوان پیش‌فرض ذکر می‌کند، و باید به گرداننده سروری که درگاه را تغییر داده باور داشت نه اینکه بر اساس یک آموزش قدیمی تردید کرد.
آن نشانی را به سرویس واقعی تبدیل کنید
نشانی قابل‌دسترس لازم است و کافی نیست. سرور اختصاصی باید در حال اجرا باشد، با نسخه‌ای که کلاینت بازیکن اجرا می‌کند سازگار باشد، و روی نشانی گوش دهد که تونل بتواند به آن تحویل دهد. فرآیندی که فقط به loopback بسته شده به این دلیل که کسی نشانی دیگری به ماشین افزوده قابل‌دسترس نمی‌شود.
پیش از دست زدن به دیوار آتش، شنونده را تأیید کنید:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565خط اول نشان می‌دهد فرآیند واقعاً به چه چیزی بسته شده، و خط دوم نشان می‌دهد آیا همتا می‌تواند دست‌دادن TCP را کامل کند. وقتی اتصال روی 127.0.0.1 است، هیچ مقدار پیکربندی VPN نتیجه را تغییر نمی‌دهد، و همین یک جزئیات شمار شگفت‌آوری از گزارش‌های «VPN خراب است» را توضیح می‌دهد.
سیاست همتاها، دیوار آتش و مسیر بازگشت
دو پرسش مجوز روی شنونده قرار دارد. پیکربندی همتاهای VPN باید ترافیک بین دو همتا را مجاز کند، و دیوار آتش میزبان بازی باید درگاه بازی را از آن همتا بپذیرد. هر دو را محدود به سرویس بازی و همتاهای مجاز نگه دارید، به‌جای خاموش کردن دیوار آتش میزبان که قاعده دو خطی را با مشکلی بسیار بزرگ‌تر عوض می‌کند. قواعد باریک همچنین تنها نسخه‌ای از این هستند که بدون یک بند توجیه از بازبینی امنیتی عبور می‌کنند.
سپس یادتان باشد یک ping موفق چه چیزی را اثبات می‌کند. رسیدن به دروازه VPN، یا گرفتن پاسخ از میزبان بازی، فقط نشان می‌دهد ICMP مسیر را طی کرده است. اتصال بازی نیاز دارد درگاه مشخص در هر دو جهت باز باشد، و مسیر بازگشت به اندازه مسیر خروج اهمیت دارد.
وقتی سرور پشت دروازه است
در مثال بالا سرور بازی یک همتاست، که طرح نشانی را ساده نگه می‌دارد. اگر سرور به‌جای آن در یک شبکه محلی پشت دروازه VPN باشد، بازیکن به نشانی خصوصی مسیریابی‌شدنی سرور نیاز دارد، دروازه باید برای آن شبکه محلی ارسال به جلو پیکربندی شود، و میزبان در شبکه محلی به مسیری بازگشتی به سوی کلاینت تونل‌شده نیاز دارد. اگر مسیر بازگشت از دست برود، دست‌دادن در نیمه راه می‌میرد، که گیج‌کننده‌ترین شکست از این سه است.
نشانی همتای مثال را برای تقلید این توپولوژی روی ماشین دیگری کپی نکنید. نشانی‌ها در یک مثال نقش‌ها را توصیف می‌کنند، و استفاده دوباره از یک نشانی در دو نقش هم‌پوشانی ایجاد می‌کند که مسیریابی نمی‌تواند آن را حل کند.
کشف، حساب‌ها و آنچه نباید تغییر داد
کشف خودکار شبکه محلی راحتی‌ای است که بر پایه اعلان‌ها ساخته شده. VPN مسیریابی‌شده لازم نیست آن پخش‌ها را حمل کند، بنابراین نبود یک ورودی در فهرست شبکه محلی چیزی درباره کار کردن نشانی خصوصی صریح نمی‌گوید. نشانی را بنویسید و سپس قضاوت کنید. اگر متصل شد، شکاف کشف یک آزار کاربردپذیری است نه عیب، و می‌توان آن را به همین شکل مستند کرد به‌جای بررسی.
احراز هویت عادی حساب بازی و سیاست پذیرش را هم دست‌نخورده نگه دارید. مسیر خصوصی کارکننده یک مسیر می‌دهد نه عضویت، و هیچ بازآرایی اولویت آداپتور جای شناسایی مقصدی را که کلاینت باید استفاده کند نمی‌گیرد.