Den delte tunnelen din utelukkar oppstartaren, ikkje spelet

Du legg oppstartaren til utelukkelista, nedlastinga hoppar frå treg til rask, og kampen landar framleis på ein fjern server. Ingenting er øydelagt. Oppstartaren og spelet er to prosessar med to sett socketar, og å utelukke den eine seier ingenting om den andre. Nedlastinga vart raskare fordi nedlastinga var trafikken til oppstartaren; kampen er tilkoplinga til nokon andre, opna av ei kjørbar fil som regelen din aldri har sett.

Éin installatør, mange prosessar

Moderne speleprogramvare er eit lite stjernebilete. Det finst ein klient som loggar deg inn, ein oppdatering som hentar innhald, ein oppstartar som startar spelet, og ei kjørbar spelefil som sjølv kan starte ein andre prosess for anti-cheat eller for matchmaking-overlegget. Kvar av dei kan halde eigne tilkoplingar til eigne destinasjonar.

Ein utelukka-regel nemner vanlegvis ein av dei. Kva ein nemner avheng heilt av identifikatoren VPN-klienten støttar, og det er delen brukarar sjeldan sjekkar. Nokre klientar matchar ein sti til ei kjørbar fil, nokre matchar ein pakke- eller bundle-identifikator, og nokre matchar eit prosessnamn som to urelaterte binærfiler kan dele. Les regelen før du les prosesslista, fordi regelen avgrensar kva du i det heile kan uttrykke.

Symptomet er derfor ikkje «den delte tunnelen er øydelagd». Det er «regelen dekkjer ein prosess som ikkje er den som ber trafikken eg bryr meg om», som er ei mykje smalare og mykje meir reparerbar utsegn. Når du først seier det slik, sluttar neste steg å vere gissing.

Finn prosessen som eig kampkoplinga

Start spelet, kom inn i ein kamp og sjå på kven som eig socketane i staden for kva som står på skjermen. På Windows svarar prosesslista pluss ein socket-førespurnad per prosess på dette med to kommandoar:

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 andre kommandoen skriv ut ein prosess-ID, ikkje eit namn, så kople dei to utdataane etter ID. Raden du leitar etter, er den der fjernadressa høyrer til speleteksten, og prosessen som eig han, er den kjørbare fila regelen din må namngje.

På Linux krev det same spørsmålet éin kommando per socket-type, og det er verdt å sjekke begge, fordi ei kampkopling kan vere UDP medan alt anna er TCP:

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

Viss spelet køyrer i ein container eller eit kompatibilitetslag, kan prosessen du finn vere ein shim i staden for binærfila du installerte. I så fall er identifikatoren som betyr noko den klienten ser, som kan vere stien til shimen, og inga mengd redigering av originalfila vil påverke det.

Match identifikatoren klienten din støttar

Les dokumentasjonen til klienten for utelukka-regelen før du legg til noko. Dei tre vanlege modellane oppfører seg ulikt, og ein av dei er ei felle.

Stireglar er dei mest presise og dei mest skjøre. Ei oppstartsopdatering som flyttar den kjørbare fila, lèt regelen peike på ei fil som ikkje lenger køyrer, og symptomet kjem tilbake utan at noko openbert endrar seg. Pakkereglar overlever det, og dei kan også stille dekkje hjelpeprosessar du aldri har tenkt på, noko som anten er praktisk eller alarmerande avhengig av hjelparen.

Uansett kva klienten støttar, ikkje legg til oppføringar for kvar kjørbar fil du finn. Ei liste sett saman ved prøving og feiling til éin økt fungerte, kan ikkje gjennomgåast, og ho vil stille samle unntak for urelatert programvare. Namngje prosessen du fann, og skriv ned kva han var for.

Test på kampen, ikkje på ei nedlasting

Nedlastingsfarten til oppstartaren er den dårlegaste moglege testen, fordi han trenar nøyaktig prosessen som allereie var utelukka. Bruk det som feila, og sjekk ruta i staden for ytingsvisinga til spelet sjølv:

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

Den første kommandoen treng adressa kampserveren løyste til, som tilkoplingsloggen til spelet eller klienten din kan gje deg. Viss ruta nemner det fysiske grensesnittet, verkar regelen. Den andre viser om det i det heile finst ei økt, noko som skil «utelukka, men serveren er nede» frå «ikkje utelukka».

Hald regionen og tilgangsnettet fast medan du testar. Ein kamp som landar i eit anna datasenter kvar gong, gjev ulike adresser, og du vil ende med å jage eit rørleg mål i staden for å validere ein regel. To køyringar med same adresse er verdt meir enn ti med ulike.

Sjekk på nytt etter neste oppdatering

Kvar stibasert regel har ein haldbarheit målt i patch-syklusar. Når spelet ein månad seinare sluttar å respektere utelukkinga, er det første du sjekkar om den kjørbare fila har flytta seg, og det andre om det har dukka opp ein ny hjelpeprosess ved sida av.

Den applikasjonsutelukkingsmodellen som éin klient dokumenterer, er ei rimeleg referanse for korleis desse reglane blir skildra, sjølv om detaljane varierer mellom produkt. Les din, registrer identifikatoren du brukte, og noter datoen. Den registreringa er det som gjer eit mysterium til ein fem minutts reparasjon neste gong oppstartaren sender ein oppdatering.

Viss klienten rett og slett ikkje kan uttrykke grensa du treng, er ein godkjend breiare policy betre enn ein haug med udokumenterte unntak. Breitt og forstått slår smalt og feil, særleg når den smale versjonen er det alle trur er på plass.