Разделеният тунел изключва стартера, а не играта

Добавяте стартера към списъка с изключения, изтеглянето скача от бавно към бързо, а мачът все още каца на далечен сървър. Нищо не е счупено. Стартерът и играта са два процеса с два набора сокети и изключването на единия не казва нищо за другия. Изтеглянето се ускори, защото изтеглянето беше трафикът на стартера; мачът е нечия друга връзка, отворена от изпълним файл, който правилото ви никога не е виждало.

Един инсталатор, много процеси

Съвременният игрален софтуер е малко съзвездие. Има клиент, който ви вписва, обновяващ компонент, който тегли съдържание, стартер, който пуска играта, и изпълним файл на играта, който сам може да създаде втори процес за анти-чит или за наслагването за намиране на мач. Всеки от тях може да поддържа собствени връзки към собствени дестинации.

Правилото за изключение обикновено назовава един от тях. Кой точно зависи изцяло от идентификатора, който 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/'

Ако играта работи в контейнер или слой за съвместимост, намереният процес може да е междинен слой, а не двоичният файл, който сте инсталирали. В такъв случай важният идентификатор е този, който клиентът вижда, и той може да е пътят на междинния слой; никакво редактиране на оригиналния файл няма да му повлияе.

Съпоставете идентификатора, който вашият клиент поддържа

Прочетете документацията на клиента за правилото за изключение, преди да добавите нещо. Трите обичайни модела се държат различно и един от тях е капан.

Правилата по път са най-точни и най-крехки. Актуализация на стартера, която премества изпълнимия файл, оставя правилото да сочи към файл, който вече не се изпълнява, и симптомът се връща, без нищо очевидно да се е променило. Правилата по пакет оцеляват при това и също могат тихо да покрият помощни процеси, за които никога не сте мислили, което е или удобно, или тревожно в зависимост от помощника.

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

Тествайте на мача, а не на изтегляне

Скоростта на изтегляне на стартера е възможно най-лошият тест, защото упражнява точно процеса, който вече е изключен. Използвайте нещото, което се проваляше, и проверявайте пътя, а не собствения дисплей за производителност на играта:

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

Първата команда се нуждае от адреса, който сървърът на мача е резолвнал, а него може да ви даде журналът за връзки на играта или клиентът ви. Ако маршрутът посочва физическия интерфейс, правилото работи. Втората показва дали изобщо съществува сесия, което разделя «изключено, но сървърът е спрян» от «не е изключено».

Дръжте региона и мрежата за достъп фиксирани, докато тествате. Мач, който при всяко опитване каца в различен център за данни, дава различни адреси и ще се окажете в преследване на движеща се цел вместо в проверка на правило. Две изпълнения с един и същ адрес струват повече от десет с различни.

Проверете отново след следващата актуализация

Всяко правило, базирано на път, има срок на годност, измерван в цикли на кръпки. Когато играта спре да спазва изключението месец по-късно, първото нещо за проверка е дали изпълнимият файл се е преместил, а второто — дали до него не се е появил нов помощен процес.

Моделът на изключване на приложения, документиран от един клиент, е разумна справка за това как се описват тези правила, макар подробностите да се различават между продуктите. Прочетете своя, запишете идентификатора, който сте използвали, и отбележете датата. Този запис превръща мистерията в петминутно поправяне следващия път, когато стартерът пусне актуализация.

Ако клиентът просто не може да изрази границата, която ви е нужна, одобрена по-широка политика е по-добра от купчина недокументирани изключения. Широкото и разбраното бие тясното и грешното, особено когато тясната версия е това, което всички вярват, че е в сила.