UDP via Tors SOCKS-poort: wat er niet doorheen gaat

Een applicatie naar een SOCKS-poort wijzen werkt voor een browser en mislukt voor een game, en de oorzaak is niet de configuratie. SOCKS5 definieert meerdere opdrachten, en een implementatie mag er slechts enkele ondersteunen; Tors interface accepteert streamverbindingen en naamresolutie, geen willekeurige doorsturing van datagrammen. Een client die UDP verstuurt en verwacht dat de proxy het doorstuurt, vraagt om een opdracht die de server niet implementeert. De handleiding hieronder controleert dat in een paar minuten en kiest daarna een transport dat echt kan werken.

Controleer wat de applicatie werkelijk verstuurt

Begin met het identificeren van het transport in plaats van de protocolnaam. Een spraakclient kan inloggen via HTTPS en daarna de media via UDP dragen; een game kan authenticeren via TCP en spelen via UDP; een bestandsoverdracht kan TCP gebruiken voor besturing en UDP voor ontdekking. De eerste twee gedragingen lijken identiek totdat de login slaagt en het gesprek nog steeds mislukt, daarom is “het is verbonden” geen bewijs dat de hele applicatie werkt. Sommige clients vallen ook vanzelf terug van UDP naar TCP, waardoor een gedeeltelijk werkende sessie op een instabiel netwerk lijkt in plaats van op een geblokkeerd transport.

Noteer de doelpoort en het transport voor het deel dat mislukt. Die ene regel bepaalt of een proxy überhaupt kan helpen.

Wat Tors SOCKS-interface accepteert

Tor implementeert de opdracht SOCKS5 CONNECT voor streamverbindingen en uitbreidingsopdrachten voor naamresolutie, daarom werkt een browser er ongewijzigd doorheen. UDP ASSOCIATE, de opdracht waarmee een client datagrammen aan de proxy zou kunnen geven om door te sturen, hoort niet bij wat Tor biedt. De documentatie van de uitbreidingen staat in de specificatie van SOCKS-uitbreidingen van het project, en die is kort. Het ontbreken van een datagramopdracht is bewust: willekeurige UDP doorsturen zou het netwerk een doorstuurrol geven waarvoor het nooit is ontworpen.

Dit is ook het antwoord voor WireGuard, dat naar ontwerp UDP is en geen TCP-terugvalweg heeft. Er is geen ondersteund pad dat WireGuard naar een SOCKS-poort wijst, en alles wat het tegendeel beweert is een omhulsel met zijn eigen verhaal over vertrouwen en onderhoud, niet een functie van een van de twee hulpmiddelen.

OpenVPN is de gedeeltelijke uitzondering, omdat het kan worden geconfigureerd om via TCP te tunnelen en het een SOCKS-proxyoptie begrijpt. Dat vereist nog steeds een voor TCP geconfigureerde server en een bewuste beslissing over de gevolgen voor prestaties en vingerafdruk, dus het is een ontwerpkeuze en geen compatibiliteitsoplossing.

Voer de controle op volgorde uit

Bevestig eerst dat de proxy voor streams werkt, zodat een latere fout niet aan een onbereikbare poort kan worden toegeschreven. Bevestig daarna het eigen verkeer van de applicatie, en kijk welke sockets hij werkelijk opent.

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'

Een geslaagde eerste opdracht en een opgezette stream in de tweede regel laten zien dat het proxypad werkt zoals ontworpen. De derde opdracht zoekt lokale datagram-sockets van de applicatie; als de client er een opent en rechtstreeks naar een extern adres stuurt, heeft hij de proxy nooit geraadpleegd en geen enkele proxyinstelling zal dat veranderen. Als het al bij de eerste stap mislukt, stop dan en repareer het proxypad voordat je de applicatie onderzoekt, want twee fouten tegelijk leveren een rapport op waar niemand iets mee kan.

Draai terug en kies het juiste hulpmiddel

Verwijder alle proxy-omgevingsvariabelen of proxyinstellingen per applicatie die de UDP-client naar de SOCKS-poort wezen; ze laten staan maakt latere tests dubbelzinnig. Herstel de vorige configuratie uit een kopie, herstart de applicatie en bevestig dat het oorspronkelijke gedrag terugkeert zodat de vergelijking schoon is. Een terugdraaiing die niet is geverifieerd is slechts een hoop dat de toestand is veranderd.

Voor een transport dat UDP moet blijven, past een VPN meestal beter: het draagt de pakketten van de applicatie zonder te vragen dat de applicatie een proxyprotocol spreekt, tegen de prijs van volstrekt andere anonimiteitseigenschappen. Gebruik elk hulpmiddel voor wat het documenteert, en behandel elke brug ertussen als een apart systeem dat zijn eigen beoordeling nodig heeft. Noteer in het eindrapport welke laag welk transport draagt, zodat de volgende persoon niet dezelfde grens opnieuw ontdekt met een andere applicatie.