Az osztott tunnel az indítót zárja ki, nem a játékot

Felveszed az indítót a kizárási listára, a letöltés lassúból gyorsba vált, és a meccs mégis egy távoli szerveren landol. Semmi nem tört el. Az indító és a játék két folyamat, két socketkészlettel, és az egyik kizárása semmit nem mond a másikról. A letöltés azért gyorsult fel, mert a letöltés az indító forgalma volt; a meccs valaki más kapcsolata, amelyet egy olyan végrehajtható fájl nyitott meg, amelyet a szabályod soha nem látott.

Egy telepítő, sok folyamat

A modern játékszoftver egy kis csillagkép. Van egy kliens, amely bejelentkeztet, egy frissítő, amely tartalmat tölt le, egy indító, amely elindítja a játékot, és egy játék végrehajtható fájl, amely maga is létrehozhat egy második folyamatot a csalásellenőrzéshez vagy a meccs-összeállítási réteghez. Mindegyik saját kapcsolatokat tarthat a saját céljaihoz.

A kizárási szabály általában egyet nevez meg közülük. Az, hogy melyiket nevezi meg, teljesen attól az azonosítótól függ, amelyet a VPN-kliens támogat, és ez az a rész, amelyet a felhasználók ritkán ellenőriznek. Egyes kliensek egy végrehajtható fájl útvonalát párosítják, mások egy csomag- vagy bundle-azonosítót, megint mások egy folyamatnevet, amelyet két független bináris fájl oszthat meg. Olvasd el a szabályt a folyamatlista előtt, mert a szabály még azt is korlátozza, amit kifejezhetsz.

A tünet tehát nem „az osztott tunnel elromlott”. Hanem „a szabály olyan folyamatot fed le, amely nem az engem érdeklő forgalmat szállítja”, ami sokkal szűkebb és sokkal javíthatóbb állítás. Ha így mondod, a következő lépés már nem találgatás.

Keresd meg a meccs kapcsolatát birtokló folyamatot

Indítsd el a játékot, lépj be egy meccsbe, és nézd meg, ki birtokolja a socketeket, ne azt, ami a képernyőn van. Windowson a folyamatlista plusz a folyamatonkénti socket-lekérdezés két paranccsal válaszol erre:

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

A második parancs folyamatazonosítót ír ki, nem nevet, ezért kapcsold össze a két kimenetet azonosító alapján. A keresett sor az, amelynek távoli címe a játékszolgáltatáshoz tartozik, és a birtokló folyamat az a végrehajtható fájl, amelyet a szabályodnak meg kell neveznie.

Linuxon ugyanez a kérdés sockettypenként egy parancsot igényel, és érdemes mindkettőt ellenőrizni, mert a meccs kapcsolata UDP lehet, miközben minden más TCP:

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

Ha a játék konténerben vagy kompatibilitási rétegben fut, a talált folyamat lehet egy shim, nem az általad telepített bináris. Ebben az esetben a fontos azonosító az, amelyet a kliens lát, ami a shim útvonala lehet, és az eredeti fájl bármilyen szerkesztése nem befolyásolja.

Párosítsd a kliensed által támogatott azonosítót

Olvasd el a kliens dokumentációját a kizárási szabályról, mielőtt bármit hozzáadnál. A három szokásos modell eltérően viselkedik, és az egyik csapda.

Az útvonalszabályok a legpontosabbak és a legtörékenyebbek. Az indító frissítése, amely áthelyezi a végrehajtható fájlt, a szabályt egy már nem futó fájlra mutatva hagyja, és a tünet visszatér anélkül, hogy bármi nyilvánvalóan megváltozna. A csomagszabályok túlélik ezt, és csendesen lefedhetnek olyan segédfolyamatokat, amelyekre soha nem gondoltál, ami a segítőtől függően kényelmes vagy riasztó.

Bármit is támogat a kliens, ne adj hozzá bejegyzéseket minden végrehajtható fájlhoz, amelyet találsz. A próbálgatással összeállított lista, amíg egy munkamenet működött, nem ellenőrizhető, és csendesen gyűjteni fogja a kivételeket a nem kapcsolódó szoftverekhez. Nevezd meg a talált folyamatot, és írd le, mire való volt.

A meccsen tesztelj, ne egy letöltésen

Az indító letöltési sebessége a lehető legrosszabb teszt, mert pontosan azt a folyamatot gyakorolja, amelyet már kizártak. Azt használd, ami meghibásodott, és az útvonalat ellenőrizd, ne a játék saját teljesítménykijelzőjét:

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

Az első parancsnak arra a címre van szüksége, amelyre a meccsszerver feloldódott, amelyet a játék kapcsolati naplója vagy a kliensed adhat meg. Ha az útvonal a fizikai interfészt nevezi meg, a szabály működik. A második megmutatja, létezik-e egyáltalán munkamenet, ami elválasztja a „kizárva, de a szerver leállt” állapotot a „nincs kizárva” állapottól.

Tartsd rögzítve a régiót és a hozzáférési hálózatot a tesztelés alatt. Az a meccs, amely minden kísérletnél más adatközpontba érkezik, más címeket eredményez, és végül egy mozgó célpontot üldözöl a szabály érvényesítése helyett. Két futás ugyanazzal a címmel többet ér, mint tíz különbözővel.

Ellenőrizd újra a következő frissítés után

Minden útvonalalapú szabálynak van patches ciklusokban mért élettartama. Amikor a játék egy hónappal később már nem tartja be a kizárást, először azt ellenőrizd, hogy elmozdult-e a végrehajtható fájl, másodszor pedig azt, hogy megjelent-e mellette egy új segédfolyamat.

Az egyik kliens által dokumentált alkalmazáskizárási modell ésszerű hivatkozás arra, hogyan írják le ezeket a szabályokat, bár a részletek termékenként eltérnek. Olvasd el a sajátodat, jegyezd fel a használt azonosítót, és jegyezd meg a dátumot. Ez a feljegyzés változtatja a rejtélyt ötperces javítássá, amikor az indító legközelebb frissítést ad ki.

Ha a kliens egyszerűen nem tudja kifejezni a szükséges határt, egy jóváhagyott szélesebb szabályzat jobb, mint a dokumentálatlan kivételek halmaza. A széles és érthető legyőzi a szűk és hibás megoldást, különösen akkor, amikor a szűk változat az, amelyet mindenki hatályban lévőnek hisz.