Ваш розділений тунель виключає лаунчер, а не гру

Ви додаєте лаунчер до списку винятків, завантаження прискорюється, а матч усе одно потрапляє на віддалений сервер. Нічого не зламано. Лаунчер і гра — два процеси з двома наборами сокетів, і виключення одного нічого не говорить про інший. Завантаження прискорилося, бо це був трафік лаунчера; матч — чуже з'єднання, відкрите виконуваним файлом, якого ваше правило ніколи не бачило.

Один інсталятор, багато процесів

Сучасне ігрове програмне забезпечення — невелике сузір'я. Є клієнт, який виконує вхід, оновлення, яке завантажує вміст, лаунчер, який запускає гру, та виконуваний файл гри, який сам може створити другий процес для античіту або шару підбору матчів. Кожен із них може тримати власні з'єднання зі своїми адресатами.

Правило винятку зазвичай називає один із них. Який саме — повністю залежить від ідентифікатора, який підтримує клієнт VPN, і це та частина, яку користувачі рідко перевіряють. Одні клієнти зіставляють шлях до виконуваного файлу, інші — ідентифікатор пакета або bundle, треті — ім'я процесу, яке можуть спільно використовувати два незв'язані бінарники. Прочитайте правило до списку процесів, бо правило обмежує навіть те, що ви можете висловити.

Тож симптом не «розділений тунель зламано». Він — «правило охоплює процес, який не є тим, що несе важливий для мене трафік», а це значно вужче й значно легше виправне твердження. Щойно ви скажете це так, наступний крок перестане бути здогадом.

Знайдіть процес, якому належить з'єднання матчу

Запустіть гру, увійдіть у матч і подивіться, кому належать сокети, а не що на екрані. У 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/'

Якщо гра працює в контейнері або шарі сумісності, знайдений процес може бути shim, а не встановлений вами бінарник. У такому разі важливий ідентифікатор — той, який бачить клієнт, і це може бути шлях shim, і жодне редагування оригінального файлу на це не вплине.

Зіставте ідентифікатор, який підтримує ваш клієнт

Прочитайте документацію клієнта про правило винятку, перш ніж щось додавати. Три звичайні моделі поводяться по-різному, і одна з них — пастка.

Правила шляху найточніші й найкрихкіші. Оновлення лаунчера, яке переміщує виконуваний файл, залишає правило вказівником на файл, що більше не запускається, і симптом повертається без очевидних змін. Правила пакета це переживають, і вони також можуть тихо охоплювати допоміжні процеси, про які ви ніколи не думали, що зручно або тривожно залежно від помічника.

Хоч би що підтримував клієнт, не додавайте записи для кожного знайденого виконуваного файлу. Список, складений методом проб і помилок, доки одна сесія не запрацювала, неможливо переглянути, і він тихо накопичуватиме винятки для незв'язаного програмного забезпечення. Назвіть знайдений процес і запишіть, для чого він був.

Перевіряйте на матчі, а не на завантаженні

Швидкість завантаження лаунчера — найгірша можлива перевірка, бо вона задіює саме той процес, який уже був виключений. Використайте те, що не працювало, і перевірте маршрут, а не власний дисплей продуктивності гри:

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

Першій команді потрібна адреса, у яку розв'язався сервер матчу, і її може дати журнал з'єднань гри або ваш клієнт. Якщо маршрут називає фізичний інтерфейс, правило працює. Друга показує, чи існує сесія взагалі, що відокремлює «виключено, але сервер недоступний» від «не виключено».

Тримайте регіон і мережу доступу незмінними під час перевірки. Матч, який щоразу потрапляє до іншого дата-центру, дає різні адреси, і ви зрештою ганятиметеся за рухомою ціллю замість перевірки правила. Два запуски з однією адресою цінніші за десять із різними.

Перевірте знову після наступного оновлення

Будь-яке правило на основі шляху має термін придатності, вимірюваний циклами виправлень. Коли через місяць гра перестане поважати виняток, перше, що треба перевірити, — чи перемістився виконуваний файл, а друге — чи не з'явився поруч новий допоміжний процес.

Модель виключення застосунків, задокументована одним клієнтом, — розумний орієнтир для опису цих правил, хоча деталі різняться між продуктами. Прочитайте свою, запишіть використаний ідентифікатор і зазначте дату. Саме цей запис перетворює загадку на п'ятихвилинне виправлення наступного разу, коли лаунчер випустить оновлення.

Якщо клієнт просто не може висловити потрібну межу, схвалена ширша політика краща за купу недокументованих винятків. Широке й зрозуміле перемагає вузьке й хибне, особливо коли вузька версія — це те, що всі вважають чинним.