Din delte tunnel udelukker starteren, ikke spillet

Du føjer starteren til udelukkelseslisten, downloadet springer fra langsomt til hurtigt, og kampen lander stadig på en fjern server. Intet er i stykker. Starteren og spillet er to processer med to sæt sockets, og at udelukke den ene siger intet om den anden. Downloadet blev hurtigere, fordi downloadet var starterens trafik; kampen er en andens forbindelse, åbnet af en eksekverbar fil, som din regel aldrig har set.

Én installatør, mange processer

Moderne spilsoftware er et lille stjernebillede. Der er en klient, der logger dig ind, en opdatering, der henter indhold, en starter, der starter spillet, og en spilfil, som selv kan starte en anden proces til anti-cheat eller til matchmaking-overlejret. Hver af dem kan have sine egne forbindelser til sine egne destinationer.

En udelukkelsesregel navngiver normalt en af dem. Hvilken en, afhænger fuldstændigt af den identifikator, VPN-klienten understøtter, og det er den del, brugerne sjældent kontrollerer. Nogle klienter matcher en sti til en eksekverbar fil, nogle matcher en pakke- eller bundle-identifikator, og nogle matcher et procesnavn, som to uafhængige binære filer kan dele. Læs reglen, før du læser proceslisten, fordi reglen begrænser, hvad du overhovedet kan udtrykke.

Symptomet er derfor ikke “den delte tunnel er i stykker”. Det er “reglen dækker en proces, som ikke er den, der bærer den trafik, jeg bekymrer mig om”, hvilket er en meget smallere og meget mere reparabel udtalelse. Når du først siger det sådan, holder næste skridt op med at være gætværk.

Find den proces, der ejer kampforbindelsen

Start spillet, kom ind i en kamp, og se på, hvem der ejer sockets, i stedet for hvad der er på skærmen. På Windows besvarer proceslisten plus en socketforespørgsel for hver proces det med to kommandoer:

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

Den anden kommando udskriver et proces-id, ikke et navn, så sammenkæd de to output efter id. Den række, du leder efter, er den, hvis fjernadresse tilhører spiltjenesten, og dens ejende proces er den eksekverbare fil, som din regel skal navngive.

På Linux kræver det samme spørgsmål én kommando for hver sockettype, og det er værd at kontrollere begge, fordi en kampforbindelse kan være UDP, mens alt andet er TCP:

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

Hvis spillet kører i en container eller et kompatibilitetslag, kan den proces, du finder, være en shim i stedet for den binære fil, du installerede. I så fald er den identifikator, der betyder noget, den klienten ser, hvilket kan være shimmenes sti, og ingen mængde redigering af den oprindelige fil vil påvirke det.

Match den identifikator, din klient understøtter

Læs klientens dokumentation for udelukkelsesreglen, før du tilføjer noget. De tre almindelige modeller opfører sig forskelligt, og en af dem er en fælde.

Stiregler er de mest præcise og de mest skrøbelige. En starteropdatering, der flytter den eksekverbare fil, efterlader reglen pegende på en fil, der ikke længere kører, og symptomet vender tilbage, uden at noget åbenlyst ændrer sig. Pakkeregler overlever det, og de kan også stille dække hjælpeprocesser, du aldrig har tænkt på, hvilket enten er praktisk eller alarmerende afhængigt af hjælperen.

Uanset hvad klienten understøtter, må du ikke tilføje poster for hver eksekverbar fil, du kan finde. En liste sammensat ved prøve og fejle, indtil en session virkede, kan ikke gennemgås, og den vil stille akkumulere undtagelser for ubeslægtet software. Navngiv den proces, du fandt, og skriv ned, hvad den var til.

Test på kampen, ikke på et download

Starterens downloadhastighed er den værst tænkelige test, fordi den netop udnytter den proces, der allerede var udelukket. Brug det, der fejlede, og kontrollér ruten i stedet for spillets egen ydelsesvisning:

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

Den første kommando har brug for den adresse, som kampserveren opløste til, hvilket spillets forbindelseslog eller din klient kan give dig. Hvis ruten navngiver den fysiske grænseflade, virker reglen. Den anden viser, om der overhovedet findes en session, hvilket adskiller “udelukket, men serveren er nede” fra “ikke udelukket”.

Hold regionen og adgangsnetværket fast, mens du tester. En kamp, der lander i et andet datacenter hver gang, giver forskellige adresser, og du vil ende med at jage et bevægeligt mål i stedet for at validere en regel. To kørsler med samme adresse er mere værd end ti med forskellige.

Kontrollér igen efter den næste opdatering

Enhver stibaseret regel har en holdbarhed målt i patchcyklusser. Når spillet en måned senere holder op med at respektere udelukkelsen, er det første, du skal kontrollere, om den eksekverbare fil er flyttet, og det andet, om der er dukket en ny hjælpeproces op ved siden af.

Den applikationsudelukkelsesmodel, som én klient dokumenterer, er en rimelig reference for, hvordan disse regler beskrives, selvom detaljerne varierer mellem produkter. Læs din, registrér den identifikator, du brugte, og notér datoen. Den registrering er det, der gør et mysterium til en femminutters rettelse næste gang, starteren sender en opdatering.

Hvis klienten simpelthen ikke kan udtrykke den grænse, du har brug for, er en godkendt bredere politik bedre end en bunke udokumenterede undtagelser. Bredt og forstået slår smalt og forkert, især når den smalle version er det, alle tror er på plads.