Den delte tunnelen din utelukker oppstarteren, ikke spillet
En oppstarter starter en annen kjørbar fil for kampen, og den prosessen har sine egne sockets. Finn den virkelige prosessen, match riktig identifikator, og test deretter.
Du legger oppstarteren til utelukkelseslisten, nedlastingen hopper fra treg til rask, og kampen lander fortsatt på en fjern server. Ingenting er ødelagt. Oppstarteren og spillet er to prosesser med to sett sockets, og å utelukke den ene sier ingenting om den andre. Nedlastingen ble raskere fordi nedlastingen var oppstarterens trafikk; kampen er noen andres tilkobling, åpnet av en kjørbar fil som regelen din aldri har sett.
Én installatør, mange prosesser
Moderne spillprogramvare er et lite stjernebilde. Det finnes en klient som logger deg inn, en oppdatering som henter innhold, en oppstarter som starter spillet, og en kjørbar spillfil som selv kan starte en andre prosess for anti-cheat eller for matchmaking-overlegget. Hver av dem kan holde sine egne tilkoblinger til sine egne destinasjoner.
En utelukkelsesregel navngir vanligvis en av dem. Hvilken den navngir avhenger helt av identifikatoren VPN-klienten støtter, og det er delen brukere sjelden sjekker. Noen klienter matcher en sti til en kjørbar fil, noen matcher en pakke- eller bundle-identifikator, og noen matcher et prosessnavn som to urelaterte binærfiler kan dele. Les regelen før du leser prosesslisten, fordi regelen begrenser hva du i det hele tatt kan uttrykke.
Symptomet er derfor ikke «den delte tunnelen er ødelagt». Det er «regelen dekker en prosess som ikke er den som bærer trafikken jeg bryr meg om», som er en mye smalere og mye mer reparerbar uttalelse. Når du først sier det slik, slutter neste steg å være gjetting.
Finn prosessen som eier kampforbindelsen
Start spillet, kom inn i en kamp og se på hvem som eier socketene i stedet for hva som står på skjermen. På Windows svarer prosesslisten pluss en socket-forespørsel per prosess på dette 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 OwningProcessDen andre kommandoen skriver ut en prosess-ID, ikke et navn, så koble de to utdataene etter ID. Raden du leter etter, er den der fjernadressen tilhører spilltjenesten, og prosessen som eier den, er den kjørbare filen regelen din må navngi.
På Linux krever det samme spørsmålet én kommando per socket-type, og det er verdt å sjekke begge, fordi en kampforbindelse kan være UDP mens alt annet er TCP:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'Hvis spillet kjører i en container eller et kompatibilitetslag, kan prosessen du finner være en shim i stedet for binærfila du installerte. I så fall er identifikatoren som betyr noe den klienten ser, som kan være shimmenes sti, og ingen mengde redigering av originalfila vil påvirke det.
Match identifikatoren klienten din støtter
Les klientens dokumentasjon for utelukkelsesregelen før du legger til noe. De tre vanlige modellene oppfører seg forskjellig, og en av dem er en felle.
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
Stiregler er de mest presise og de mest skjøre. En oppstartsopdatering som flytter den kjørbare fila, lar regelen peke på en fil som ikke lenger kjører, og symptomet kommer tilbake uten at noe åpenbart endres. Pakkeregler overlever det, og de kan også stille dekke hjelpeprosesser du aldri har tenkt på, noe som enten er praktisk eller alarmerende avhengig av hjelperen.
Uansett hva klienten støtter, ikke legg til oppføringer for hver kjørbar fil du finner. En liste satt sammen ved prøving og feiling til én økt fungerte, kan ikke gjennomgås, og den vil stille samle unntak for urelatert programvare. Navngi prosessen du fant, og skriv ned hva den var for.
Test på kampen, ikke på en nedlasting
Oppstarterens nedlastingshastighet er den dårligste mulige testen, fordi den trener nøyaktig prosessen som allerede var utelukket. Bruk det som feilet, og sjekk ruten i stedet for spillets egen ytelsesvisning:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015Den første kommandoen trenger adressen kampserveren løste til, som spillets tilkoblingslogg eller klienten din kan gi deg. Hvis ruten navngir det fysiske grensesnittet, virker regelen. Den andre viser om det i det hele tatt finnes en økt, noe som skiller «utelukket, men serveren er nede» fra «ikke utelukket».
Hold regionen og tilgangsnettet fast mens du tester. En kamp som lander i et annet datasenter hver gang, gir forskjellige adresser, og du vil ende med å jage et bevegelig mål i stedet for å validere en regel. To kjøringer med samme adresse er verdt mer enn ti med forskjellige.
Sjekk på nytt etter neste oppdatering
Enhver stibasert regel har en holdbarhet målt i patch-sykluser. Når spillet en måned senere slutter å respektere utelukkelsen, er det første du sjekker om den kjørbare fila har flyttet seg, og det andre om det har dukket opp en ny hjelpeprosess ved siden av.
Den applikasjonsutelukkelsesmodellen som én klient dokumenterer, er en rimelig referanse for hvordan disse reglene beskrives, selv om detaljene varierer mellom produkter. Les din, registrer identifikatoren du brukte, og noter datoen. Den registreringen er det som gjør et mysterium til en fem minutters reparasjon neste gang oppstarteren sender en oppdatering.
Hvis klienten rett og slett ikke kan uttrykke grensen du trenger, er en godkjent bredere policy bedre enn en haug med udokumenterte unntak. Bredt og forstått slår smalt og feil, spesielt når den smale versjonen er det alle tror er på plass.