UDP gjennom SOCKS-porten til Tor: det som ikke blir båret

Det å rette et program mot en SOCKS-port virker for en nettleser og mislykkes for et spill, og grunnen er ikke konfigurasjon. SOCKS5 definerer flere kommandoer, og en implementasjon er fri til å støtte bare noen av dem; grensesnittet til Tor tar imot 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 som serveren ikke implementerer. Veiledningen nedenfor sjekker dette i løpet av noen minutter og velger så en transport som faktisk kan virke.

Sjekk hva programmet faktisk sender

Begynn med å identifisere transporten framfor protokollnavnet. En taleklient kan logge på 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 styring og UDP til oppdagelse. De to første atferdene ser like ut helt til påloggingen lykkes og samtalen fortsatt mislykkes, og derfor er «det koblet seg til» ikke bevis for at hele programmet virker. Noen klienter faller også av egen kraft tilbake fra UDP til TCP, noe som får en delvis virkende økt til å likne et ustabilt nettverk istedenfor en blokkert transport.

Skriv opp målporten og transporten for den delen som mislykkes. Den ene linjen avgjør om en proxy i det hele tatt kan hjelpe.

Hva grensesnittet til Tor godtar

Tor implementerer kommandoen SOCKS5 CONNECT for strømtilkoblinger og utvidelseskommandoer for navneoppslag, og derfor virker en nettleser gjennom det uendret. 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 ligger i prosjektets spesifikasjon for SOCKS-utvidelser, og den er kort. At det ikke finnes noen datagramkommando er tilsiktet: videresending av vilkårlig UDP ville gi nettverket en videresenderrolle som det aldri var utformet for.

Dette er også svaret for WireGuard, som etter design er UDP og ikke har noen TCP-reservevei. Det finnes ingen støttet vei som retter WireGuard mot en SOCKS-port, og alt som påstår det motsatte 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 likevel en server konfigurert for TCP og en bevisst beslutning om følgene for ytelse og fingeravtrykk, så det er et designvalg og ikke en kompatibilitetsretting.

Utfør kontrollen i rekkefølge

Bekreft først at proxyen virker for strømmer, slik at en senere feil ikke kan legges på en uoppnåelig port. Bekreft deretter programmets egen trafikk, og se 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 på andre linje viser at proxyveien virker som utformet. Den tredje kommandoen leter 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 på det. Hvis det mislykkes allerede på første trinn, stopp og reparer proxyveien før du undersøker programmet, fordi to feil samtidig gir en rapport som ingen kan handle etter.

Rull tilbake og velg riktig verktøy

Fjern alle proxy-miljøvariabler eller proxyinnstillinger per program som rettet 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 har endret seg.

For en transport som må være UDP, passer en VPN vanligvis bedre: den bærer pakkene til programmet 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.