ورود به Steam کار میکند، بازی نه: هر مسیر را بررسی کنید
ورود به Steam، یک دانلود و یک جلسهٔ تطبیق میتوانند مسیرهای متفاوتی داشته باشند. فهرست بررسی را به ترتیب دنبال کنید و بنویسید کدام مرحله واقعاً شکست خورد.
Steam را اجرا کنید، وارد شوید و همهچیز سالم به نظر میرسد تا وقتی بازی جلسهای پیدا نمیکند. این را سه پرسش جداگانهٔ شبکه در نظر بگیرید نه یک پرسش. فروشگاه و صفحههای حساب، دانلود محتوا و جلسهٔ بازی میتوانند هرکدام از طریق انتقالهای متفاوت به نقاط پایانی متفاوتی برسند. این بررسیها را به ترتیب انجام دهید و در اولین موردی که شکست میخورد متوقف شوید، چون هر چیز بعد از آن حدس است.
مرحله 1: تأیید کنید که ورود تنها چیزی بود که کار کرد
ورود ثابت میکند که حساب با اعتبارنامهها و هر عامل دومی که حساب لازم دارد به سرویس هویت رسیده است. دربارهٔ تحویل محتوا چیزی نمیگوید و دربارهٔ ترتیب میزبانی خود بازی هم چیزی نمیگوید. بنویسید کدامیک از سه عملیات را واقعاً آزمایش کردید، چون مردم معمولاً بعد از آزمایش فقط لانچر از بازی خراب گزارش میدهند.
پیش از شبکه، متن خطا را بخوانید. بازیای که میگوید هیچ سروری در دسترس نیست چیزی متفاوت از لانچری به شما میگوید که به فروشگاه نمیرسد. این دو خطا از لایههای متفاوت میآیند و بهندرت یک معنا دارند. این تفاوت تعیین میکند که بررسی بعدی دربارهٔ حل نام، دربارهٔ UDP یا دربارهٔ تنظیم منطقه باشد.
حساب، منطقه، بازی و زمان را ثبت کنید. بدون این چهار مقدار، مقایسهٔ بعدی میان دو آزمون متفاوت است که تصادفاً نام یکسان دارند.
مرحله 2: انتقال هر عملیات را نامگذاری کنید
تحویل محتوا مانند یک انتقال بزرگ HTTP رفتار میکند و تأخیر را بسیار بهتر از افت تحمل میکند. تطبیق و جلسههای درون بازی اغلب از UDP استفاده میکنند، جایی که مسیری که بستهها را میاندازد شبیه بازی خراب است نه دانلود کند. این دو نمایه در همان تونل به شکلهای متفاوت شکست میخورند، به همین دلیل دانلود سریع جلسهٔ سالم را پیشبینی نمیکند.
بهجای فهرست پورتهای فروشنده، ابتدا مقصدها و سوکتهای فعال را بررسی کنید. فهرست میگوید پلتفرم چه چیزی میتواند استفاده کند، در حالی که سوکتها میگویند این کلاینت هماکنون چه میکند.
nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/اگر فرایند بازی سوکت UDP با ترافیک را نگه دارد در حالی که مسیر انتقال سالم است، شکست در بخش UDP است. این مشکل را به نحوهٔ برخورد تونل با UDP محدود میکند نه به حساب یا فروشگاه.
مرحله 3: سیاست شاملسازی را پیش از فهرست پورت بررسی کنید
بسیاری از کلاینتهای VPN سیاست را برای هر برنامه، هر محدودهٔ نشانی یا هر خانوادهٔ نشانی اعمال میکنند نه برای کل ماشین. لانچر میتواند داخل تونل باشد در حالی که فایل اجرایی بازی که جداگانه اجرا شده بیرون آن است، و آنگاه آن دو دربارهٔ جهان توافق ندارند. شاملسازی در سطح برنامه مقصر معمول در لپتاپهای بازی با کلاینت فروشندهٔ نصبشده است. سیاستی را بخوانید که واقعاً در اجراست، نه پروفایلی که ماه گذشته ذخیره کردید.
به جدول مسیریابی و رابطی که مسیر پیشفرض را دارد نگاه کنید. قاعدهٔ تونل تقسیمشده بر پایهٔ پیشوندهای مقصد آنجا دیده میشود، اما استثنای سطح برنامه دیده نمیشود. دانستن این تفاوت پیش از تغییر هر یک از این دو ارزشمند است.
ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescriptionاگر ترافیک بازی از آداپتور فیزیکی خارج شود در حالی که فروشگاه از تونل میگذرد، سیاست شاملسازی یافته است. هیچ استثنای پورتی تصمیم مسیریابی را درست نمیکند و افزودن یکی فقط سطح را گستردهتر میکند.
مرحله 4: مسیر SOCKS را که نمیتواند UDP را حمل کند کنار بگذارید
Tor یک پروکسی SOCKS ارائه میدهد و پشتیبانی SOCKS در سراسر اکوسیستم دربارهٔ UDP یکدست نیست. رفتار مستند Tor پیادهسازی UDP ASSOCIATE نیست، بنابراین بازیای که ترافیک جلسهاش UDP است نمیتواند از آن مسیر استفاده کند هر طور که کلاینت به آن نشانه رفته باشد. مرورگری که از طریق پروکسی کار میکند فقط ثابت میکند که جریانهای TCP مرورگر کار میکنند.
ادعا را بیازمایید نه نیت را. اگر بازی هنوز جلسهٔ در دسترس نبودن را گزارش کند در حالی که آزمون فقط TCP از طریق همان پروکسی موفق میشود، مسیر پروکسی ترافیکی را که بازی نیاز دارد حمل نمیکند.
VPN مسیریابیشده و پروکسی SOCKS را ابزارهای متفاوتی با تواناییهای متفاوت بدانید. جایگزینکردن یکی با دیگری تغییری در طراحی است، نه ترجیح پیکربندی.
ثبت را با توافقنامه بسنجید
دسترسیپذیری شبکه و مجوز حساب دو پرسش جداگانهاند و تنها به اولی یک تونل سالم پاسخ میدهد. محدودیت دربارهٔ نیت پشت پروکسیکردن است نه دربارهٔ پروتکلی که انتخاب کردید. توافقنامهٔ در اجرا پروکسیکردن IP را محدود میکند که هدفش پنهانکردن محل زندگی صاحب حساب است، بنابراین مسیری که کار میکند ممکن است هنوز بیرون از شرایطی باشد که پذیرفتید. توافقنامه را بخوانید نه اینکه اتصال را تأیید بدانید.
برای مقایسهای صادقانه، هر بار یک متغیر را تغییر دهید و همان بازی، منطقهٔ سرور، حساب و عملیات را نگه دارید. سپس نتیجه را روی همان چهار عملیاتی که در آغاز ثبت کردید بررسی کنید.
tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/وقتی ثبت نشان میدهد ورود کار میکند، دانلود کار میکند و جلسه شکست میخورد، پرسش باقیمانده دربارهٔ UDP روی مسیر است. وقتی هر سه کار میکنند، شکایت اصلی دربارهٔ چیز دیگری بود و گام مفید بعدی گزارش خود بازی است نه تونل. در هر حال، فهرست بررسی بحث را با مشاهدهای مشخص جایگزین کرده است.