A Steam bejelentkezés működik, a játék nem: ellenőrizd az összes útvonalat

Indítsd el a Steamet, jelentkezz be, és minden egészségesnek tűnik, amíg a játék nem talál munkamenetet. Kezeld ezt három külön hálózati kérdésként, nem egyként. Az áruház és a fiók képernyői, a tartalomletöltés és a játékmunkamenet különböző végpontokat érhet el különböző átviteli módokon. Végezd el ezeket az ellenőrzéseket sorrendben, és állj meg az elsőnél, amelyik hibázik, mert minden utána találgatás.

1. lépés: erősítsd meg, hogy a bejelentkezés volt az egyetlen, ami működött

A bejelentkezés azt bizonyítja, hogy a fiók elérte az identitásszolgáltatást a hitelesítő adatokkal és minden második tényezővel, amelyet a fiók megkövetel. Semmit sem mond a tartalom kézbesítéséről, és semmit sem mond a játék saját tárhelyelrendezéséről. Jegyezd fel, hogy a három művelet közül melyiket tesztelted valóban, mert az emberek általában csak az indítót tesztelve jelentenek hibás játékot.

Olvasd el a hiba szövegét a hálózat előtt. Egy játék, amely azt jelenti, hogy nincsenek elérhető szerverek, mást mond, mint egy indító, amely nem éri el az áruházat. A két hiba különböző rétegekből származik, és ritkán jelent ugyanazt. A megkülönböztetés dönti el, hogy a következő ellenőrzés a névfeloldásról, az UDP-ről vagy egy régióbeállításról szól.

Jegyezd fel a fiókot, a régiót, a játékot és az időt. E négy érték nélkül egy későbbi összehasonlítás két különböző teszt között történik, amelyek véletlenül ugyanazt a nevet viselik.

2. lépés: nevezd meg az átvitelt minden művelethez

A tartalom kézbesítése nagy HTTP-átvitelként viselkedik, és a késleltetést sokkal jobban tűri, mint a veszteséget. A párosítás és a játékon belüli munkamenetek gyakran UDP-t használnak, ahol a csomagokat eldobó útvonal inkább törött játéknak tűnik, mint lassú letöltésnek. Ez a két profil másként hibázik ugyanazon az alagúton, ezért a gyors letöltés nem jósol működő munkamenetet.

Először a célokat és az aktív socketeket ellenőrizd, ne a szállító portlistáját. A lista azt mondja, mit használhat a platform, míg a socketek azt mondják, mit tesz ez a kliens most.

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

Ha a játékfolyamat forgalommal rendelkező UDP-socketet tart, miközben az átviteli útvonal rendben van, a hiba az UDP-lábban van. Ez a problémát az alagút UDP-kezelésére szűkíti, nem a fiókra vagy az áruházra.

3. lépés: a portlista előtt ellenőrizd a befogadási házirendet

Sok VPN-kliens alkalmazza a házirendet alkalmazásonként, címtartományonként vagy címcsaládonként, nem az egész gépre. Az indító lehet az alagúton belül, miközben egy külön indított játék-bináris azon kívül van, és akkor a kettő nem ért egyet a világról. Az alkalmazásszintű befogadás a szokásos bűnös a szállító kliensét futtató játékos laptopokon. Azt a házirendet olvasd, amely valóban érvényben van, ne a múlt hónapban mentett profilt.

Nézd meg az útvonaltáblát és az alapértelmezett útvonalat birtokló interfészt. A cél-előtagokon alapuló osztott alagút szabálya ott megjelenik, az alkalmazásszintű kizárás viszont nem. Ezt a különbséget érdemes ismerni, mielőtt bármelyiket megváltoztatod.

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

Ha a játék forgalma a fizikai adapteren keresztül távozik, miközben az áruház az alagúton megy át, a befogadási házirend a lelet. Egyetlen portkivétel sem javít egy útvonalválasztási döntést, és egy hozzáadása csak szélesíti a felületet.

4. lépés: zárd ki az UDP-t hordozni képtelen SOCKS-útvonalat

A Tor SOCKS-proxyt biztosít, és a SOCKS támogatása az ökoszisztémában ellentmondásos az UDP tekintetében. A Tor dokumentált viselkedése nem valósítja meg az UDP ASSOCIATE-et, ezért egy játék, amelynek munkamenet-forgalma UDP, nem használhatja azt az útvonalat, akárhogyan irányítják is a klienst rá. Az a böngésző, amely a proxyn keresztül működik, csak azt bizonyítja, hogy a böngésző TCP-folyamai működnek.

Az állítást teszteld, ne a szándékot. Ha a játék továbbra is elérhetetlen munkamenetet jelent, miközben a csak TCP-s teszt ugyanazon a proxyn sikerül, a proxy útvonala nem hordozza a játék által igényelt forgalmat.

Kezeld az útvonalválasztott VPN-t és a SOCKS-proxyt különböző képességekkel rendelkező különböző eszközökként. Az egyik lecserélése a másikra tervezési változás, nem konfigurációs preferencia.

Vesd össze a feljegyzést a megállapodással

A hálózati elérhetőség és a fiókengedély külön kérdés, és csak az elsőre ad választ egy működő alagút. A korlátozás a proxizás mögötti szándékról szól, nem a választott protokollról. A hatályos megállapodás korlátozza az IP-proxizást, amelynek célja elrejteni, hol lakik a fióktulajdonos, ezért egy működő útvonal még mindig kívül eshet az elfogadott feltételeken. Olvasd a megállapodást, ahelyett hogy a kapcsolódást jóváhagyásnak tekintenéd.

Őszinte összehasonlításhoz egyszerre egy változót módosíts, és tartsd ugyanazt a játékot, szerverrégiót, fiókot és műveletet. Utána ellenőrizd az eredményt ugyanazon a négy műveleten, amelyeket az elején feljegyeztél.

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

Amikor a feljegyzés azt mutatja, hogy a bejelentkezés működik, a letöltés működik, a munkamenet pedig hibázik, a fennmaradó kérdés az útvonalon lévő UDP-ről szól. Amikor mindhárom működik, az eredeti panasz valami másról szólt, és a következő hasznos lépés a játék saját naplója, nem az alagút. Akárhogy is, az ellenőrzőlista vitát cserélt konkrét megfigyelésre.