Je split-tunnel sluit de launcher uit, niet het spel

Je voegt de launcher toe aan de uitsluitingslijst, de download springt van langzaam naar snel, en de wedstrijd belandt nog steeds op een verre server. Niets is kapot. De launcher en het spel zijn twee processen met twee sets sockets, en het ene uitsluiten zegt niets over het andere. De download werd sneller omdat de download het verkeer van de launcher was; de wedstrijd is de verbinding van iemand anders, geopend door een uitvoerbaar bestand dat je regel nooit heeft gezien.

Eén installer, veel processen

Moderne spellesoftware is een klein sterrenbeeld. Er is een client die je aanmeldt, een updater die inhoud ophaalt, een launcher die het spel start, en een uitvoerbaar spelbestand dat zelf een tweede proces kan starten voor anti-cheat of voor de matchmaking-overlay. Elk daarvan kan zijn eigen verbindingen naar zijn eigen bestemmingen houden.

Een uitsluitingsregel noemt meestal een van hen. Welke hij noemt hangt volledig af van de identificatie die de VPN-client ondersteunt, en dat is het deel dat gebruikers zelden controleren. Sommige clients matchen een pad naar een uitvoerbaar bestand, sommige een pakket- of bundle-identificatie, en sommige een procesnaam die twee ongerelateerde binaries kunnen delen. Lees de regel voordat je de proceslijst leest, want de regel beperkt zelfs wat je kunt uitdrukken.

Het symptoom is dus niet „de split-tunnel is kapot”. Het is „de regel dekt een proces dat niet degene is die het verkeer draagt waar ik om geef”, wat een veel smallere en veel beter te repareren bewering is. Zodra je het zo zegt, is de volgende stap geen giswerk meer.

Vind het proces dat de wedstrijdverbinding bezit

Start het spel, ga een wedstrijd in en kijk wie de sockets bezit in plaats van wat er op het scherm staat. Op Windows beantwoorden de proceslijst plus een socketquery per proces dat met twee opdrachten:

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

De tweede opdracht drukt een proces-ID af, geen naam, dus voeg de twee uitvoer samen op ID. De rij die je zoekt is degene waarvan het externe adres bij de speldienst hoort, en het bezittende proces is het uitvoerbare bestand dat je regel moet noemen.

Op Linux vereist dezelfde vraag één opdracht per sockettype, en het is de moeite waard beide te controleren, omdat een wedstrijdverbinding UDP kan zijn terwijl al het andere TCP is:

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

Als het spel in een container of een compatibiliteitslaag draait, kan het proces dat je vindt een shim zijn in plaats van de binary die je hebt geïnstalleerd. In dat geval is de identificatie die ertoe doet degene die de client ziet, wat het pad van de shim kan zijn, en geen enkele bewerking van het originele bestand zal daar invloed op hebben.

Koppel de identificatie die je client ondersteunt

Lees de documentatie van de client over de uitsluitingsregel voordat je iets toevoegt. De drie gangbare modellen gedragen zich verschillend, en een ervan is een valstrik.

Padregels zijn het nauwkeurigst en het breekbaarst. Een launcher-update die het uitvoerbare bestand verplaatst laat de regel wijzen naar een bestand dat niet meer draait, en het symptoom komt terug zonder dat er iets zichtbaar verandert. Pakketregels overleven dat, en ze kunnen ook stil hulpprocessen dekken waar je nooit aan hebt gedacht, wat handig of alarmerend is, afhankelijk van de helper.

Wat de client ook ondersteunt, voeg geen items toe voor elk uitvoerbaar bestand dat je vindt. Een lijst die door vallen en opstaan is samengesteld tot één sessie werkte, is niet te beoordelen, en hij zal stil uitzonderingen verzamelen voor ongerelateerde software. Noem het proces dat je vond, en schrijf op waarvoor het diende.

Test op de wedstrijd, niet op een download

De downloadsnelheid van de launcher is de slechtst mogelijke test, omdat die precies het proces oefent dat al was uitgesloten. Gebruik het ding dat faalde, en controleer het pad in plaats van de prestatieweergave van het spel zelf:

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

De eerste opdracht heeft het adres nodig waar de wedstrijdserver naar resolvet, wat het verbindingslog van het spel of je client je kan geven. Als de route de fysieke interface noemt, werkt de regel. De tweede laat zien of er überhaupt een sessie bestaat, wat „uitgesloten maar de server ligt eruit” scheidt van „niet uitgesloten”.

Houd de regio en het toegangsnetwerk vast terwijl je test. Een wedstrijd die bij elke poging in een ander datacenter landt, levert verschillende adressen op, en je jaagt uiteindelijk een bewegend doel na in plaats van een regel te valideren. Twee runs met hetzelfde adres zijn meer waard dan tien met verschillende.

Controleer opnieuw na de volgende update

Elke padgebaseerde regel heeft een houdbaarheid gemeten in patchcycli. Als het spel een maand later de uitsluiting niet meer respecteert, is het eerste dat je controleert of het uitvoerbare bestand is verplaatst, en het tweede of er een nieuw hulpproces naast is verschenen.

Het toepassingsuitsluitingsmodel dat één client documenteert is een redelijke referentie voor hoe deze regels worden beschreven, hoewel de details per product verschillen. Lees het jouwe, noteer de gebruikte identificatie en schrijf de datum op. Die registratie is wat een mysterie verandert in een reparatie van vijf minuten de volgende keer dat de launcher een update uitbrengt.

Als de client de grens die je nodig hebt simpelweg niet kan uitdrukken, is een goedgekeurd breder beleid beter dan een hoop ongedocumenteerde uitzonderingen. Breed en begrepen verslaat smal en fout, vooral wanneer de smalle versie is wat iedereen denkt dat van kracht is.