Jaettu tunnelisi sulkee pois käynnistimen, ei peliä
Käynnistin käynnistää ottelua varten toisen suoritettavan tiedoston, ja sillä prosessilla on omat sokettinsa. Etsi todellinen prosessi, sovita oikea tunniste ja testaa sitten.
Lisäät käynnistimen poissulkuluetteloon, lataus hyppää hitaasta nopeaksi ja ottelu laskeutuu silti kaukaiselle palvelimelle. Mikään ei ole rikki. Käynnistin ja peli ovat kaksi prosessia, joilla on kaksi sokettijoukkoa, eikä toisen poissulkeminen kerro toisesta mitään. Lataus nopeutui, koska lataus oli käynnistimen liikennettä; ottelu on jonkun muun yhteys, jonka avasi suoritettava tiedosto, jota sääntösi ei ole koskaan nähnyt.
Yksi asentaja, monta prosessia
Nykyaikainen peliohjelmisto on pieni tähtikuvio. On asiakas, joka kirjaa sinut sisään, päivittäjä, joka hakee sisältöä, käynnistin, joka käynnistää pelin, ja pelin suoritettava tiedosto, joka voi itse luoda toisen prosessin huijauksen torjuntaa tai otteluiden yhdistämiskerrosta varten. Jokainen niistä voi pitää omat yhteytensä omiin kohteisiinsa.
Poissulkusääntö nimeää yleensä yhden niistä. Se, minkä se nimeää, riippuu täysin tunnisteesta, jota VPN-asiakas tukee, ja juuri sitä käyttäjät harvoin tarkistavat. Jotkin asiakkaat sovittavat suoritettavan tiedoston polun, jotkin paketin tai bundlen tunnisteen ja jotkin prosessin nimen, jonka kaksi toisistaan riippumatonta binaaritiedostoa voi jakaa. Lue sääntö ennen prosessiluetteloa, koska sääntö rajoittaa jopa sitä, mitä voit ilmaista.
Oire ei siis ole “jaettu tunneli on rikki”. Se on “sääntö kattaa prosessin, joka ei ole se, joka kuljettaa minua kiinnostavaa liikennettä”, mikä on paljon kapeampi ja paljon korjattavampi väite. Kun sanot sen näin, seuraava askel lakkaa olemasta arvailua.
Etsi prosessi, jolla on ottelun yhteys
Käynnistä peli, mene otteluun ja katso, kuka omistaa sokeetit sen sijaan, mitä näytöllä on. Windowsissa prosessiluettelo plus sokettikysely prosessia kohden vastaa siihen kahdella komennolla:
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 OwningProcessToinen komento tulostaa prosessin ID:n, ei nimeä, joten yhdistä kaksi tulostetta ID:n perusteella. Etsimäsi rivi on se, jonka etäosoite kuuluu pelipalvelulle, ja sen omistava prosessi on suoritettava tiedosto, jonka sääntösi on nimettävä.
Linuxissa sama kysymys vaatii yhden komennon sokettityyppiä kohden, ja molemmat kannattaa tarkistaa, koska ottelun yhteys voi olla UDP:nä, kun kaikki muu on TCP:tä:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'Jos peli toimii kontissa tai yhteensopivuuskerroksessa, löytämäsi prosessi voi olla shim eikä asentamasi binaaritiedosto. Siinä tapauksessa tärkeä tunniste on se, jonka asiakas näkee, ja se voi olla shimin polku, eikä alkuperäisen tiedoston muokkaaminen vaikuta siihen.
Sovita tunniste, jota asiakkaasi tukee
Lue asiakkaan dokumentaatio poissulkusäännöstä ennen kuin lisäät mitään. Kolme tavallista mallia käyttäytyvät eri tavoin, ja yksi niistä on ansa.
| 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 |
Polkusäännöt ovat tarkimmat ja hauraimmat. Käynnistimen päivitys, joka siirtää suoritettavan tiedoston, jättää säännön osoittamaan tiedostoon, joka ei enää käynnisty, ja oire palaa, ilman että mikään näkyvästi muuttuu. Pakettisäännöt kestävät sen, ja ne voivat myös hiljaa kattaa apuprosesseja, joita et koskaan ajatellut, mikä on joko kätevää tai hälyttävää apurista riippuen.
Mitä asiakas tukee, älä lisää merkintöjä jokaiseen löytämääsi suoritettavaan tiedostoon. Kokeilun ja erehdyksen kautta koottu luettelo, kunnes yksi istunto toimi, ei ole tarkistettavissa, ja se kerää hiljaa poikkeuksia asiaankuulumattomalle ohjelmistolle. Nimeä löytämäsi prosessi ja kirjoita, mihin se oli tarkoitettu.
Testaa ottelussa, älä latauksessa
Käynnistimen latausnopeus on huonoin mahdollinen testi, koska se rasittaa juuri sitä prosessia, joka oli jo suljettu pois. Käytä sitä, mikä epäonnistui, ja tarkista polku pelin oman suorituskykynäytön sijaan:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015Ensimmäinen komento tarvitsee osoitteen, johon ottelupalvelin ratkesi, ja sen voi antaa pelin yhteysloki tai asiakkaasi. Jos reitti nimeää fyysisen liitännän, sääntö toimii. Toinen näyttää, onko istuntoa ylipäätään olemassa, mikä erottaa tilan “poissuljettu mutta palvelin on alhaalla” tilasta “ei poissuljettu”.
Pidä alue ja käyttöverkko kiinteinä testauksen ajan. Ottelu, joka laskeutuu joka kerta eri datakeskukseen, tuottaa eri osoitteita, ja päädyt jahtaamaan liikkuvaa maalia säännön validoimisen sijaan. Kaksi ajoa samalla osoitteella on arvokkaampi kuin kymmenen eri osoitteilla.
Tarkista uudelleen seuraavan päivityksen jälkeen
Jokaisella polkupohjaisella säännöllä on korjausjaksoissa mitattu käyttöikä. Kun peli lopettaa poissulkemisen noudattamisen kuukautta myöhemmin, ensimmäinen tarkistettava asia on, siirtyikö suoritettava tiedosto, ja toinen, ilmestyikö sen viereen uusi apuprosessi.
Yhden asiakkaan dokumentoima sovellusten poissulkumalli on järkevä viite siihen, miten nämä säännöt kuvataan, vaikka yksityiskohdat vaihtelevat tuotteiden välillä. Lue omasi, kirjaa käyttämäsi tunniste ja merkitse päivämäärä. Juuri se merkintä muuttaa mysteerin viiden minuutin korjaukseksi seuraavan kerran, kun käynnistin julkaisee päivityksen.
Jos asiakas ei yksinkertaisesti pysty ilmaisemaan tarvitsemaasi rajaa, hyväksytty laajempi käytäntö on parempi kuin kasa dokumentoimattomia poikkeuksia. Laaja ja ymmärretty voittaa kapean ja väärän, varsinkin kun kapea versio on se, jonka kaikki uskovat olevan voimassa.