Den samme spilserver virker kun gennem en VPN: hvad det beviser

Én server, to forsøg: med VPN slået fra falder sessionen under indlæsningen, med den slået til tilslutter den samme session. Det er reel evidens, og det er let at overfortolke. At slå en VPN til ændrer kildeadressen, transitvejen, resolverpolitikken og nogle gange adressefamilien på én gang, så en succes fortæller dig, at forskellen betød noget, uden at fortælle hvilken forskel det var. At gå sammenligningen igennem ét lag ad gangen er måden at få et svar, du kan handle på. Det forhindrer dig også i at ændre fire ting og ikke lære noget.

Bekræft først, hvad operatøren har tænkt sig

En privat server, der kræver en godkendt VPN, skal være utilgængelig gennem en almindelig offentlig forbindelse, og det er en fungerende konfiguration og ikke en fejl. En offentliggjort offentlig server, der fejler på præcis én adgangsvej, er en anden sag med en anden ejer. Før du tester noget, skal du fastslå, hvilken af de to du ser på, fordi svaret afgør, om du fejlfinder et netværk eller læser en politik. Spørg operatøren, eller læs deres offentliggjorte adgangsnoter, i stedet for at udlede det af et mislykket join.

Hvis operatøren offentliggør en adgangsmetode, så brug den. At omgå en bevidst begrænsning er ikke samme opgave som at reparere en brudt rute.

Hold sammenligningsregistret lille og fast

Hold spillet, kontoen, den valgte server og handlingen konstant mellem forsøgene, og ændr kun VPN-tilstanden. Registrér serverens id og region samt den faktiske adresse, hvor klienten viser den, fordi det synlige servernavn ikke er det, netværket bruger. »Launcheren åbnede« og »denne multiplayer-session blev tilsluttet« er forskellige resultater, og at blande dem gør sammenligningen værdiløs.

Skriv de fire linjer ned før den første test. En sammenligning, du bagefter rekonstruerer fra hukommelsen, er en historie, ikke en måling.

Navngiv den første fejl, ikke den sidste besked

Beskeden på skærmen er normalt den sidste hændelse i en kæde. Notér i stedet den første meningsfulde: navneopløsning, transport-timeout, afvisning af forbindelse, en kontobegrænsning eller en sessionsfejl efter, at forbindelsen lykkedes. De kategorier har forskellige ejere og forskellige rettelser, og et generisk »afbrudt«-banner kollapser dem til ét ubrugeligt ord.

Hvis klienten fører en log, så læs den for fasen i stedet for fejlkoden. Fasen fortæller dig, hvilket lag du skal teste næste gang.

Samme navn betyder ikke samme tuple

Et værtsnavn kan opløses til forskellige adresser på forskellige veje, og IPv4 og IPv6 kan følge helt forskellige ruter og forskellige politikker. Tjek, om det direkte forsøg og VPN-forsøget brugte samme destination og samme adressefamilie, før du sammenligner deres udfald. Ellers sammenligner du to eksperimenter og kalder dem ét.

For en ruteforskel skal du huske, at internettets routing følger operatørens politik og ikke den geografisk korteste linje, hvilket er præcis den idé, der er beskrevet i BGP-specifikationen. En VPN, der undgår en dårlig transitvej, demonstrerer, at en vej var dårlig, ikke at nogen bevidst throttler dig.

Test den transport, spillet faktisk bruger

En vellykket TCP-forbindelse til én port etablerer ikke en UDP-session, og ingen af dem beviser, at spillets login blev gennemført. Følg de tjenester, titlen faktisk har brug for, i stedet for en portliste kopieret fra et andet spil, og foretræk at holde øje med klientens egen adfærd frem for at sondere udefra. Hvis en server besvarer en anmodning fra din udgangsadresse med en afvisning, er det et politisk spørgsmål for operatøren, ikke evidens om dit lokale kabel eller din router.

Brug udgiverens support- eller klagekanal ved en udtrykkelig begrænsning. At sløre en kontos berettigelse er en anden aktivitet med et andet sæt konsekvenser.

Når du skriver det op, så medtag begge veje, den uændrede handling, den valgte server og adressefamilie samt den første fejl. Det er en rapport, en operatør kan undersøge, og den kræver ikke, at du ændrer fire indstillinger på én gang for at lave den.