تونل تقسیم‌شده شما راه‌انداز را مستثنا می‌کند، نه بازی را
راه‌انداز یک فایل اجرایی دیگر را برای مسابقه شروع می‌کند و آن فرایند سوکت‌های خودش را دارد. فرایند واقعی را پیدا کنید، شناسه درست را تطبیق دهید و سپس آزمایش کنید.
راه‌انداز را به فهرست استثناها اضافه می‌کنید، دانلود از کند به سریع می‌پرد و مسابقه همچنان روی یک سرور دور فرود می‌آید. هیچ چیز خراب نیست. راه‌انداز و بازی دو فرایند با دو مجموعه سوکت هستند و مستثنا کردن یکی هیچ چیزی درباره دیگری نمی‌گوید. دانلود سریع‌تر شد چون دانلود ترافیک راه‌انداز بود؛ مسابقه اتصال شخص دیگری است که یک فایل اجرایی باز کرده است و قاعده شما هرگز آن را ندیده.
یک نصب‌کننده، فرایندهای بسیار
نرم‌افزار بازی مدرن یک صورت فلکی کوچک است. یک کلاینت هست که شما را وارد می‌کند، یک به‌روزرسان که محتوا را می‌گیرد، یک راه‌انداز که بازی را شروع می‌کند و یک فایل اجرایی بازی که ممکن است خودش فرایند دومی برای ضدتقلب یا لایه تطبیق مسابقه بسازد. هر یک از آن‌ها می‌تواند اتصال‌های خودش را به مقصدهای خودش نگه دارد.
یک قاعده استثنا معمولاً یکی از آن‌ها را نام می‌برد. اینکه کدام را نام می‌برد کاملاً به شناسه‌ای بستگی دارد که کلاینت VPN پشتیبانی می‌کند و این همان بخشی است که کاربران به‌ندرت بررسی می‌کنند. بعضی کلاینت‌ها مسیر یک فایل اجرایی را تطبیق می‌دهند، بعضی شناسه بسته یا باندل را و بعضی نام فرایندی را که دو فایل دودویی بی‌ربط می‌توانند مشترک داشته باشند. قاعده را پیش از فهرست فرایندها بخوانید، چون قاعده حتی آنچه را هم که می‌توانید بیان کنید محدود می‌کند.
پس نشانه «تونل تقسیم‌شده خراب است» نیست. نشانه «قاعده فرایندی را پوشش می‌دهد که فرایند حامل ترافیک مورد نظر من نیست» است و این جمله بسیار باریک‌تر و بسیار قابل‌ترمیم‌تر است. وقتی آن را این‌طور بگویید، گام بعدی دیگر حدس زدن نیست.
فرایندی را پیدا کنید که اتصال مسابقه را دارد
بازی را شروع کنید، وارد مسابقه شوید و ببینید سوکت‌ها مال کیست نه اینکه روی صفحه چه دیده می‌شود. در Windows فهرست فرایندها به‌همراه یک پرس‌وجوی سوکت برای هر فرایند این را با دو فرمان پاسخ می‌دهد:
Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcessفرمان دوم شناسه فرایند را چاپ می‌کند، نه نام را، پس دو خروجی را بر اساس شناسه به هم بپیوندید. سطری که دنبالش هستید آن است که نشانی دورش به سرویس بازی تعلق دارد و فرایند صاحب آن همان فایل اجرایی است که قاعده شما باید نامش را ببرد.
در Linux همان پرسش برای هر نوع سوکت یک فرمان می‌خواهد و ارزش دارد هر دو را بررسی کنید، چون اتصال مسابقه ممکن است UDP باشد در حالی که بقیه چیزها TCP است:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'اگر بازی در یک کانتینر یا لایه سازگاری اجرا شود، فرایندی که پیدا می‌کنید ممکن است یک لایه واسط باشد نه فایل دودویی که نصب کرده‌اید. در این حالت شناسه مهم همانی است که کلاینت می‌بیند و ممکن است مسیر همان لایه واسط باشد، و هیچ مقدار ویرایش فایل اصلی روی آن اثر نمی‌گذارد.
شناسه‌ای را تطبیق دهید که کلاینت شما پشتیبانی می‌کند
پیش از افزودن هر چیزی مستندات کلاینت را درباره قاعده استثنا بخوانید. سه مدل رایج متفاوت رفتار می‌کنند و یکی از آن‌ها تله است.
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
قاعده‌های مسیر دقیق‌ترین و شکننده‌ترین هستند. به‌روزرسانی راه‌انداز که فایل اجرایی را جابه‌جا می‌کند قاعده را به فایلی اشاره‌گر می‌گذارد که دیگر اجرا نمی‌شود و نشانه بدون اینکه چیزی آشکارا تغییر کند برمی‌گردد. قاعده‌های بسته از آن جان سالم به در می‌برند و می‌توانند بی‌صدا فرایندهای کمکی را هم بپوشانند که هرگز به آن‌ها فکر نکرده‌اید، که بسته به آن کمک‌کننده یا راحت است یا هشداردهنده.
هر چه کلاینت پشتیبانی می‌کند، برای هر فایل اجرایی که پیدا می‌کنید ورودی اضافه نکنید. فهرستی که با آزمون و خطا تا کار کردن یک نشست ساخته شده قابل بازبینی نیست و بی‌صدا استثناهایی برای نرم‌افزارهای بی‌ربط انباشته می‌کند. فرایندی را که پیدا کردید نام ببرید و بنویسید برای چه بود.
روی مسابقه آزمایش کنید، نه روی دانلود
سرعت دانلود راه‌انداز بدترین آزمایش ممکن است، چون دقیقاً همان فرایندی را به کار می‌گیرد که از قبل مستثنا شده بود. از همان چیزی که شکست می‌خورد استفاده کنید و مسیر را بررسی کنید نه نمایش کارایی خود بازی را:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015فرمان اول به نشانی نیاز دارد که سرور مسابقه به آن حل شده است، که گزارش اتصال بازی یا کلاینت شما می‌تواند به شما بدهد. اگر مسیر رابط فیزیکی را نام ببرد، قاعده کار می‌کند. دومی نشان می‌دهد اصلاً نشستی وجود دارد یا نه، که «مستثنا شده اما سرور خاموش است» را از «مستثنا نشده» جدا می‌کند.
هنگام آزمایش منطقه و شبکه دسترسی را ثابت نگه دارید. مسابقه‌ای که هر بار در مرکز داده متفاوتی فرود می‌آید نشانی‌های متفاوتی تولید می‌کند و در نهایت به‌جای اعتبارسنجی یک قاعده، هدف متحرکی را تعقیب خواهید کرد. دو اجرا با نشانی یکسان ارزشمندتر از ده اجرا با نشانی‌های متفاوت است.
پس از به‌روزرسانی بعدی دوباره بررسی کنید
هر قاعده مبتنی بر مسیر عمری دارد که با چرخه‌های وصله اندازه‌گیری می‌شود. وقتی بازی یک ماه بعد دیگر استثنا را رعایت نکند، اولین چیزی که بررسی می‌کنید این است که آیا فایل اجرایی جابه‌جا شده و دوم اینکه آیا فرایند کمکی تازه‌ای کنارش ظاهر شده است.
مدل استثنای برنامه‌ها که یک کلاینت مستند کرده است مرجع معقولی برای نحوه توصیف این قاعده‌هاست، هرچند جزئیات میان محصول‌ها متفاوت است. مدل خودتان را بخوانید، شناسه‌ای را که استفاده کرده‌اید ثبت کنید و تاریخ را بنویسید. همان ثبت است که دفعه بعد که راه‌انداز به‌روزرسانی منتشر می‌کند، یک معما را به تعمیر پنج‌دقیقه‌ای تبدیل می‌کند.
اگر کلاینت به‌سادگی نمی‌تواند مرزی را که نیاز دارید بیان کند، یک سیاست گسترده‌تر تأییدشده بهتر از انبوهی از استثناهای مستندنشده است. گسترده و فهمیده بر باریک و اشتباه پیروز می‌شود، به‌ویژه وقتی نسخه باریک همانی است که همه باور دارند برقرار است.