Twój tunel dzielony wyklucza launcher, a nie grę

Dodajesz launcher do listy wykluczeń, pobieranie przeskakuje z wolnego na szybkie, a mecz nadal trafia na odległy serwer. Nic nie jest zepsute. Launcher i gra to dwa procesy z dwoma zestawami gniazd, a wykluczenie jednego nic nie mówi o drugim. Pobieranie przyspieszyło, bo pobieranie było ruchem launchera; mecz jest połączeniem kogoś innego, otwartym przez plik wykonywalny, którego twoja reguła nigdy nie widziała.

Jeden instalator, wiele procesów

Współczesne oprogramowanie do gier to mały gwiazdozbiór. Jest klient, który cię loguje, aktualizator, który pobiera treści, launcher, który uruchamia grę, oraz plik wykonywalny gry, który sam może utworzyć drugi proces na potrzeby anti-cheatu lub nakładki do matchmakingu. Każdy z nich może utrzymywać własne połączenia do własnych celów.

Reguła wykluczenia zwykle nazywa jeden z nich. Który nazywa, zależy całkowicie od identyfikatora obsługiwanego przez klienta VPN, i to jest część, którą użytkownicy rzadko sprawdzają. Niektóre klienty dopasowują ścieżkę pliku wykonywalnego, inne identyfikator pakietu lub bundle'a, a jeszcze inne nazwę procesu, którą mogą dzielić dwa niepowiązane pliki binarne. Przeczytaj regułę przed listą procesów, bo reguła ogranicza nawet to, co możesz wyrazić.

Objawem nie jest więc „tunel dzielony jest zepsuty”. To „reguła obejmuje proces, który nie jest tym, który przenosi ruch, na którym mi zależy”, czyli znacznie węższe i znacznie łatwiejsze do naprawy stwierdzenie. Gdy powiesz to w ten sposób, następny krok przestaje być zgadywaniem.

Znajdź proces, który posiada połączenie meczu

Uruchom grę, wejdź do meczu i sprawdź, kto posiada gniazda, a nie co jest na ekranie. W systemie Windows lista procesów plus zapytanie o gniazda dla każdego procesu odpowiadają na to dwiema komendami:

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

Druga komenda wypisuje identyfikator procesu, a nie nazwę, więc połącz oba wyniki po identyfikatorze. Wiersz, którego szukasz, to ten, którego zdalny adres należy do usługi gry, a proces, który go posiada, to plik wykonywalny, który twoja reguła musi nazwać.

W systemie Linux to samo pytanie wymaga jednej komendy na typ gniazda, i warto sprawdzić oba, bo połączenie meczu może być UDP, podczas gdy wszystko inne jest TCP:

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

Jeśli gra działa w kontenerze lub warstwie zgodności, znaleziony proces może być shimem, a nie plikiem binarnym, który zainstalowałeś. W takim przypadku ważnym identyfikatorem jest ten, który widzi klient, czyli może to być ścieżka shima, i żadna edycja oryginalnego pliku tego nie zmieni.

Dopasuj identyfikator obsługiwany przez twojego klienta

Przeczytaj dokumentację klienta dotyczącą reguły wykluczenia, zanim cokolwiek dodasz. Trzy typowe modele zachowują się różnie, a jeden z nich to pułapka.

Reguły ścieżki są najprecyzyjniejsze i najbardziej kruche. Aktualizacja launchera, która przenosi plik wykonywalny, zostawia regułę wskazującą plik, który już nie działa, a objaw wraca, choć nic oczywiście się nie zmienia. Reguły pakietów to przetrwają, a mogą też po cichu obejmować procesy pomocnicze, o których nigdy nie myślałeś, co jest wygodne albo alarmujące w zależności od pomocnika.

Cokolwiek obsługuje klient, nie dodawaj wpisów dla każdego znalezionego pliku wykonywalnego. Lista złożona metodą prób i błędów, aż jedna sesja zadziałała, nie nadaje się do przeglądu i będzie po cichu gromadzić wyjątki dla niepowiązanego oprogramowania. Nazwij znaleziony proces i zapisz, czemu służył.

Testuj na meczu, nie na pobieraniu

Prędkość pobierania launchera to najgorszy możliwy test, bo ćwiczy dokładnie ten proces, który już był wykluczony. Użyj tego, co zawodziło, i sprawdź trasę, a nie własny wyświetlacz wydajności gry:

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

Pierwsza komenda potrzebuje adresu, na który rozwiązał się serwer meczu, a może go podać dziennik połączeń gry albo twój klient. Jeśli trasa wskazuje interfejs fizyczny, reguła działa. Druga pokazuje, czy w ogóle istnieje sesja, co oddziela „wykluczone, ale serwer nie działa” od „niewykluczone”.

Podczas testu utrzymuj stały region i sieć dostępową. Mecz, który za każdym razem trafia do innego centrum danych, daje różne adresy, a ty skończysz na ściganiu ruchomego celu zamiast weryfikowaniu reguły. Dwa uruchomienia z tym samym adresem są warte więcej niż dziesięć z różnymi.

Sprawdź ponownie po następnej aktualizacji

Każda reguła oparta na ścieżce ma termin przydatności mierzony cyklami poprawek. Gdy gra miesiąc później przestanie respektować wykluczenie, pierwszą rzeczą do sprawdzenia jest to, czy plik wykonywalny się przeniósł, a drugą, czy obok pojawił się nowy proces pomocniczy.

Model wykluczania aplikacji dokumentowany przez jednego klienta to rozsądne odniesienie do sposobu opisywania tych reguł, choć szczegóły różnią się między produktami. Przeczytaj swój, zapisz użyty identyfikator i zanotuj datę. To ten zapis zamienia zagadkę w pięciominutową naprawę przy następnej aktualizacji launchera.

Jeśli klient po prostu nie potrafi wyrazić potrzebnej granicy, zatwierdzona szersza polityka jest lepsza niż stos nieudokumentowanych wyjątków. Szerokie i zrozumiałe bije wąskie i błędne, zwłaszcza gdy wąska wersja jest tym, co wszyscy uważają za obowiązujące.