UDP genom Tors SOCKS-port: vad som inte bärs

Att peka ett program mot en SOCKS-port fungerar för en webbläsare och misslyckas för ett spel, och orsaken är inte konfiguration. SOCKS5 definierar flera kommandon, och en implementation får stödja bara några av dem; Tors gränssnitt tar emot strömanslutningar och namnmatchning, inte godtycklig vidarebefordran av datagram. En klient som skickar UDP och förväntar sig att proxyn vidarebefordrar det ber om ett kommando som servern inte implementerar. Vägledningen nedan kontrollerar detta på några minuter och väljer sedan en transport som faktiskt kan fungera.

Kontrollera vad appen faktiskt skickar

Börja med att identifiera transporten i stället för protokollnamnet. En röstklient kan logga in via HTTPS och sedan bära mediet via UDP; ett spel kan autentisera via TCP och spela via UDP; en filöverföring kan använda TCP för styrning och UDP för upptäckt. De två första beteendena ser identiska ut tills inloggningen lyckas och samtalet fortfarande misslyckas, därför är ”det anslöt” inte bevis för att hela appen fungerar. Vissa klienter faller också av sig själva tillbaka från UDP till TCP, vilket får en delvis fungerande session att se ut som ett ostabilt nätverk i stället för en blockerad transport.

Skriv ned målporten och transporten för den del som misslyckas. Den enda raden avgör om en proxy alls kan hjälpa.

Vad Tors SOCKS-gränssnitt accepterar

Tor implementerar kommandot SOCKS5 CONNECT för strömanslutningar och tilläggskommandon för namnmatchning, därför fungerar en webbläsare genom det utan ändringar. UDP ASSOCIATE, kommandot som skulle låta en klient lämna datagram till proxyn för vidarebefordran, är inte en del av det Tor erbjuder. Dokumentationen för tilläggen finns i projektets specifikation för SOCKS-tillägg, och den är kort. Avsaknaden av ett datagramkommando är avsiktlig: att vidarebefordra godtycklig UDP skulle ge nätverket en vidarebefordrarroll som det aldrig konstruerades för.

Detta är också svaret för WireGuard, som till sin konstruktion är UDP och inte har någon TCP-reservväg. Det finns ingen stödd väg som pekar WireGuard mot en SOCKS-port, och allt som påstår motsatsen är ett hölje med sin egen historia om förtroende och underhåll, inte en funktion i något av de två verktygen.

OpenVPN är det delvisa undantaget, eftersom det kan konfigureras att tunnla över TCP och det förstår ett SOCKS-proxyval. Det kräver fortfarande en server konfigurerad för TCP och ett medvetet beslut om konsekvenserna för prestanda och fingeravtryck, så det är ett designval och inte en kompatibilitetsrättning.

Kör kontrollen i ordning

Bekräfta först att proxyn fungerar för strömmar, så att ett senare fel inte kan skyllas på en onåbar port. Bekräfta sedan appens egen trafik och observera vilka sockets den faktiskt öppnar.

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'

Ett lyckat första kommando och en etablerad ström på andra raden visar att proxyvägen fungerar som konstruerad. Det tredje kommandot letar efter lokala datagram-sockets som tillhör appen; om klienten öppnar en och skickar direkt till en fjärradress har den aldrig frågat proxyn, och ingen proxyinställning ändrar det. Om det misslyckas redan i första steget, stanna och reparera proxyvägen innan du undersöker appen, eftersom två fel samtidigt ger en rapport som ingen kan agera på.

Rulla tillbaka och välj rätt verktyg

Ta bort alla proxy-miljövariabler eller proxyinställningar per app som pekade UDP-klienten mot SOCKS-porten; att låta dem stå gör senare tester tvetydiga. Återställ den tidigare konfigurationen från en kopia, starta om appen och bekräfta att det ursprungliga beteendet kommer tillbaka så att jämförelsen blir ren. En återställning som inte verifieras är bara en förhoppning om att tillståndet ändrades.

För en transport som måste förbli UDP passar en VPN oftast bättre: den bär appens paket utan att kräva att appen talar ett proxyprotokoll, till priset av helt andra anonymitetsegenskaper. Använd varje verktyg för det det dokumenterar, och behandla varje bro mellan dem som ett eget system som behöver sin egen granskning. Skriv i slutrapporten vilket lager som bär vilken transport, så att nästa person inte återupptäcker samma gräns med en annan app.