Steam-ensaluto funkcias, la ludo ne: kontrolu ĉiun vojon

Lanĉu Steam, ensalutu, kaj ĉio aspektas sana ĝis la ludo ne trovas sesion. Traktu tion kiel tri apartajn retajn demandojn anstataŭ unu. La butiko kaj la kontaj ekranoj, la enhava elŝuto kaj la luda sesio povas ĉiu atingi malsamajn finpunktojn per malsamaj transportoj. Plenumu ĉi tiujn kontrolojn laŭ ordo kaj haltu ĉe la unua, kiu malsukcesas, ĉar ĉio post ĝi estas konjekto.

Paŝo 1: konfirmu, ke la ensaluto estas la sola afero, kiu funkciis

La ensaluto pruvas, ke la konto atingis la identigan servon kun la akreditiloj kaj ajna dua faktoro, kiun la konto postulas. Ĝi diras nenion pri enhava liverado, kaj ĝi diras nenion pri la propra gastiga aranĝo de la ludo. Notu, kiun el la tri operacioj vi fakte testis, ĉar homoj kutime raportas malsukcesan ludon post testado nur de la lanĉilo.

Legu la malsukcesan tekston antaŭ la reto. Ludo, kiu raportas, ke neniuj serviloj disponeblas, diras al vi ion alian ol lanĉilo, kiu ne atingas la butikon. La du eraroj venas el malsamaj tavoloj kaj malofte signifas la saman. La distingo decidas, ĉu la sekva kontrolo temas pri nomrezolucio, pri UDP aŭ pri regiona agordo.

Notu la konton, la regionon, la ludon kaj la tempon. Sen tiuj kvar valoroj, pli posta komparo estas inter du malsamaj testoj, kiuj hazarde havas la saman nomon.

Paŝo 2: nomu la transporton por ĉiu operacio

Enhava liverado kondutas kiel granda HTTP-transigo kaj toleras latentecon multe pli bone ol perdon. Matĉado kaj sesioj en la ludo ofte uzas UDP, kie vojo, kiu perdas pakaĵojn, aspektas kiel difektita ludo anstataŭ malrapida elŝuto. Tiuj du profiloj malsukcesas malsame sur la sama tunelo, tial rapida elŝuto ne antaŭsignas funkciantan sesion.

Kontrolu la celojn kaj la aktivajn ingojn anstataŭ unue la havenliston de la vendanto. La listo diras, kion la platformo rajtas uzi, dum la ingoj diras, kion ĉi tiu kliento faras nun.

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

Se la luda procezo tenas UDP-ingon kun trafiko, dum la transiga vojo estas en ordo, la malsukceso estas en la UDP-parto. Tio mallarĝigas la problemon al la traktado de UDP fare de la tunelo, ne al la konto aŭ la butiko.

Paŝo 3: kontrolu la inkludan politikon antaŭ la havenlisto

Multaj VPN-klientoj aplikas politikon po aplikaĵo, po adresaro aŭ po adresa familio anstataŭ al la tuta maŝino. Lanĉilo povas esti ene de la tunelo, dum aparte lanĉita luda binaraĵo estas ekster ĝi, kaj tiam la du malkonsentas pri la mondo. Inkludo ĉe aplikaĵa nivelo estas la kutima kulpulo en ludaj tekkomputiloj kun instalita kliento de vendanto. Legu la politikon, kiu fakte validas, ne la profilon, kiun vi konservis pasintmonate.

Rigardu la vojigan tabelon kaj la interfacon, kiu posedas la defaŭltan vojon. Regulo de dividita tunelo bazita sur celaj prefiksoj aperos tie, sed escepto ĉe aplikaĵa nivelo ne. Tiu diferenco indas esti konata antaŭ ol vi ŝanĝas iun ajn el ili.

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

Se la trafiko de la ludo eliras tra la fizika adaptilo, dum la butiko iras tra la tunelo, la inkluda politiko estas la trovo. Neniu havena escepto riparos vojigan decidon, kaj aldoni unu nur larĝigas la surfacon.

Paŝo 4: ekskludu vojon SOCKS, kiu ne povas porti UDP

Tor provizas SOCKS-prokurilon, kaj SOCKS-subteno tra la ekosistemo estas malkonsekvenca pri UDP. La dokumentita konduto de Tor ne efektivigas UDP ASSOCIATE, do ludo, kies sesia trafiko estas UDP, ne povas uzi tiun vojon, kiel ajn la kliento estas direktita al ĝi. Retumilo, kiu funkcias tra la prokurilo, pruvas nur, ke la TCP-fluoj de la retumilo funkcias.

Testu la aserton, ne la intencon. Se la ludo ankoraŭ raportas neatingeblan sesion, dum testo nur per TCP tra la sama prokurilo sukcesas, la prokurila vojo ne portas la trafikon, kiun la ludo bezonas.

Traktu vojigitan VPN kaj SOCKS-prokurilon kiel malsamajn ilojn kun malsamaj kapabloj. Anstataŭigi unu per la alia estas ŝanĝo de dezajno, ne prefero de agordo.

Komparu la rikordon kun la interkonsento

Retatingeblo kaj konta permeso estas apartaj demandoj, kaj nur la unuan respondas funkcianta tunelo. La limigo temas pri la intenco malantaŭ la prokuriĝo, ne pri la protokolo, kiun vi elektis. La valida interkonsento limigas IP-prokuriĝon, kies celo estas kaŝi, kie loĝas la kontposedanto, do vojo, kiu funkcias, povas ankoraŭ esti ekster la kondiĉoj, kiujn vi akceptis. Legu la interkonsenton anstataŭ trakti konekteblon kiel aprobon.

Por honesta komparo, ŝanĝu unu variablon samtempe kaj konservu la saman ludon, servilan regionon, konton kaj operacion. Poste kontrolu la rezulton sur la samaj kvar operacioj, kiujn vi notis komence.

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/

Kiam la rikordo montras, ke la ensaluto funkcias, la elŝuto funkcias kaj la sesio malsukcesas, la restanta demando temas pri UDP sur la vojo. Kiam ĉiuj tri funkcias, la origina plendo temis pri io alia, kaj la sekva utila paŝo estas la propra protokolo de la ludo, ne la tunelo. Ĉiel ajn, la kontrolo anstataŭigis disputon per konkreta observado.