Å peke et program mot en SOCKS-port fungerer for en nettleser og feiler for et spill, og årsaken er ikke konfigurasjon. SOCKS5 definerer flere kommandoer, og en implementasjon står fritt til å støtte bare noen av dem; Tors grensesnitt godtar strømtilkoblinger og navneoppslag, ikke vilkårlig videresending av datagrammer. En klient som sender UDP og forventer at proxyen videresender det, ber om en kommando serveren ikke implementerer. Veiledningen nedenfor kontrollerer dette på noen minutter og velger deretter en transport som faktisk kan fungere.

Kontroller hva programmet faktisk sender

Begynn med å identifisere transporten i stedet for protokollnavnet. En taleklient kan logge inn over HTTPS og deretter bære mediet over UDP; et spill kan autentisere over TCP og spille over UDP; en filoverføring kan bruke TCP til kontroll og UDP til oppdagelse. De to første atferdene ser identiske ut helt til innloggingen lykkes og samtalen fortsatt feiler, og derfor er «det koblet til» ikke bevis for at hele programmet virker. Noen klienter faller også av seg selv tilbake fra UDP til TCP, noe som får en delvis fungerende økt til å se ut som et ustabilt nettverk i stedet for en blokkert transport.

Skriv ned destinasjonsporten og transporten for den delen som feiler. Den ene linjen avgjør om en proxy i det hele tatt kan hjelpe.

Hva Tors SOCKS-grensesnitt godtar

Tor implementerer kommandoen SOCKS5 CONNECT for strømtilkoblinger og utvidelseskommandoer for navneoppslag, og derfor virker en nettleser gjennom det uten endringer. UDP ASSOCIATE, kommandoen som ville la en klient overlate datagrammer til proxyen for videresending, er ikke en del av det Tor tilbyr. Dokumentasjonen for utvidelsene finnes i prosjektets spesifikasjon for SOCKS-utvidelser, og den er kort. Fraværet av en datagramkommando er bevisst: videresending av vilkårlig UDP ville gi nettverket en videresenderrolle det aldri var designet for.

Dette er også svaret for WireGuard, som er UDP av design og ikke har noen TCP-fallback. Det finnes ingen støttet vei som peker WireGuard mot en SOCKS-port, og alt som hevder noe annet er en innpakning med sin egen historie om tillit og vedlikehold, ikke en funksjon i noen av de to verktøyene.

OpenVPN er det delvise unntaket, fordi det kan konfigureres til å tunnelere over TCP og det forstår et SOCKS-proxyvalg. Det krever fortsatt en server konfigurert for TCP og en bevisst beslutning om konsekvensene for ytelse og fingeravtrykk, så det er et designvalg og ikke en kompatibilitetsretting.

Kjør kontrollen i rekkefølge

Bekreft først at proxyen virker for strømmer, slik at en senere feil ikke kan skyldes på en uoppnåelig port. Bekreft deretter programmets egen trafikk, og legg merke til hvilke sockets det faktisk åpner.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

En vellykket første kommando og en etablert strøm i andre linje viser at proxyveien virker som designet. Den tredje kommandoen ser etter lokale datagram-sockets som tilhører programmet; hvis klienten åpner en og sender direkte til en ekstern adresse, har den aldri spurt proxyen, og ingen proxyinnstilling vil endre det. Hvis det feiler allerede på første trinn, stopp og reparer proxyveien før du undersøker programmet, fordi to feil samtidig gir en rapport ingen kan handle på.

Rull tilbake og velg riktig verktøy

Fjern alle proxy-miljøvariabler eller proxyinnstillinger per program som pekte UDP-klienten mot SOCKS-porten; å la dem stå gjør senere tester tvetydige. Gjenopprett den forrige konfigurasjonen fra en kopi, start programmet på nytt og bekreft at den opprinnelige atferden kommer tilbake, slik at sammenligningen blir ren. En tilbakerulling som ikke er verifisert, er bare et håp om at tilstanden endret seg.

For en transport som må forbli UDP, passer en VPN vanligvis bedre: den bærer programmets pakker uten å kreve at programmet snakker en proxyprotokoll, mot at helt andre anonymitetsegenskaper følger med. Bruk hvert verktøy til det det dokumenterer, og behandle enhver bro mellom dem som et eget system som trenger sin egen gjennomgang. Skriv i sluttrapporten hvilket lag som bærer hvilken transport, slik at neste person ikke gjenoppdager den samme grensen med et annet program.

Relaterte artikler