Java DatagramSocket und SOCKS5-UDP-Relaying
Verstehen Sie, warum ein Java-UDP-Socket eine SOCKS5-UDP-Implementierung braucht, obwohl TCP-Verbindungen bereits SOCKS nutzen.
Ihre Java-HTTP-Anfrage funktioniert über SOCKS, doch eine UDP-Funktion sendet weiterhin direkt Daten oder schlägt fehl. Das Setzen der SOCKS-Eigenschaften der JVM gibt DatagramSocket keine SOCKS5-UDP-Implementierung.
Die DatagramSocket-API sendet und empfängt Datagramme, die an Netzwerkendpunkte adressiert sind. Ihre Methode connect() wählt einen Peer für diesen Socket. Sie führt keine SOCKS-Aushandlung mit dem Peer durch.
Ein SOCKS5-UDP-Weg erfordert zusätzliche Arbeit
SOCKS5 definiert eine UDP-Assoziation, die über eine TCP-Steuerverbindung aufgebaut wird. Anschließend tauscht der Client gekapselte Datagramme mit der Relay-Adresse aus, die der Proxy bereitstellt. Jede gekapselte Nachricht benennt ihr Ziel. Eine Client-Implementierung muss diese Kapselung und die Lebensdauer der Steuerverbindung beherrschen.
Einen gewöhnlichen UDP-Socket auf den TCP-Lauschport des Proxys zu richten, überspringt diese Schritte. Die Rohdatagramme Ihrer Anwendung an diese Adresse zu senden, ersetzt die Assoziation nicht.
Wählen Sie eine Bibliothek oder Anwendungsfunktion, die SOCKS5-UDP-Relay ausdrücklich unterstützt, und bestätigen Sie, dass auch der Server dies tut. Eine Bibliothek, die SOCKS-Unterstützung bewirbt, implementiert möglicherweise nur TCP CONNECT. Die Protokollspezifikation unterscheidet die Befehle.
Das UDP-Relay braucht außerdem einen nutzbaren Pfad
Eine erfolgreiche TCP-Verbindung zum Proxy legt nur den Steuerpfad an. Firewalls oder NAT-Verhalten können Datagramme zum Relay weiterhin stören. Sammeln Sie den zurückgegebenen Relay-Endpunkt und jeden Relay-Fehler, bevor Sie folgern, dass das Ziel der Anwendung offline ist.
Schließlich fügt SOCKS-Transportunterstützung dem UDP keine Zustellgarantien hinzu. Die eigenen Timeouts Ihrer Anwendung, die Verlustbehandlung und die Beschränkungen der Nachrichtengröße gelten auch nach dem Wechsel des Wegs.