UDP gennem Tors SOCKS-port: hvad der ikke bæres

At pege et program mod en SOCKS-port virker for en browser og fejler for et spil, og årsagen er ikke konfiguration. SOCKS5 definerer flere kommandoer, og en implementering kan frit understøtte kun nogle af dem; Tors grænseflade accepterer streamforbindelser og navneopløsning, ikke vilkårlig videresendelse af datagrammer. En klient, der sender UDP og forventer, at proxyen videresender det, beder om en kommando, som serveren ikke implementerer. Vejledningen nedenfor kontrollerer det på få minutter og vælger derefter en transport, der faktisk kan fungere.

Kontrollér, hvad programmet faktisk sender

Begynd med at identificere transporten frem for protokolnavnet. En tale-klient kan logge ind over HTTPS og derefter bære mediet over UDP; et spil kan godkende over TCP og spille over UDP; en filoverførsel kan bruge TCP til kontrol og UDP til opdagelse. De to første adfærdsmønstre ser identiske ud, indtil login lykkes, og opkaldet stadig fejler, og derfor er “det blev forbundet” ikke bevis for, at hele programmet virker. Nogle klienter falder også af sig selv tilbage fra UDP til TCP, hvilket får en delvist fungerende session til at ligne et ustabilt netværk frem for en blokeret transport.

Skriv destinationsporten og transporten ned for den del, der fejler. Den ene linje afgør, om en proxy overhovedet kan hjælpe.

Hvad Tors SOCKS-grænseflade accepterer

Tor implementerer kommandoen SOCKS5 CONNECT til streamforbindelser og udvidelseskommandoer til navneopløsning, og derfor virker en browser gennem den uden ændringer. UDP ASSOCIATE, den kommando der ville lade en klient overlade datagrammer til proxyen til videresendelse, er ikke en del af det, Tor tilbyder. Dokumentationen for udvidelserne findes i projektets specifikation for SOCKS-udvidelser, og den er kort. Fraværet af en datagramkommando er bevidst: videresendelse af vilkårlig UDP ville give netværket en rolle som videresender, som det aldrig var designet til.

Det er også svaret for WireGuard, som er UDP af design og ikke har nogen TCP-fallback. Der findes ingen understøttet vej, der peger WireGuard mod en SOCKS-port, og alt, der hævder andet, er en indpakning med sin egen historie om tillid og vedligeholdelse snarere end en funktion i noget af de to værktøjer.

OpenVPN er den delvise undtagelse, fordi det kan konfigureres til at tunnelere over TCP, og det forstår en SOCKS-proxyindstilling. Det kræver stadig en server konfigureret til TCP og en bevidst beslutning om konsekvenserne for ydeevne og fingeraftryk, så det er et designvalg frem for en kompatibilitetsrettelse.

Kør kontrollen i rækkefølge

Bekræft først, at proxyen virker for streams, så en senere fejl ikke kan skydes på en uopnåelig port. Bekræft derefter programmets egen trafik, og læg mærke til, hvilke sockets det faktisk åbner.

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 etableret stream i anden linje viser, at proxyvejen virker som designet. Den tredje kommando leder efter lokale datagram-sockets, der tilhører programmet; hvis klienten åbner en og sender direkte til en fjernadresse, har den aldrig spurgt proxyen, og ingen proxyindstilling ændrer det. Hvis det fejler ved første trin, så stop og reparer proxyvejen, før du undersøger programmet, fordi to fejl på én gang giver en rapport, som ingen kan handle på.

Rul tilbage og vælg det rigtige værktøj

Fjern alle proxy-miljøvariabler eller proxyindstillinger for hvert program, der pegede UDP-klienten mod SOCKS-porten; at lade dem blive gør senere tests tvetydige. Gendan den tidligere konfiguration fra en kopi, genstart programmet, og bekræft, at den oprindelige adfærd vender tilbage, så sammenligningen er ren. En tilbagerulning, der ikke er verificeret, er kun et håb om, at tilstanden ændrede sig.

For en transport, der skal forblive UDP, er en VPN normalt det bedre valg: den bærer programmets pakker uden at kræve, at programmet taler en proxyprotokol, på bekostning af helt andre anonymitetsegenskaber. Brug hvert værktøj til det, det dokumenterer, og behandl enhver bro mellem dem som et separat system, der kræver sin egen gennemgang. Skriv ned i den endelige rapport, hvilket lag der bærer hvilken transport, så den næste person ikke genopdager den samme grænse med et andet program.