Indys Null-Adresse bei UDP ASSOCIATE ist nicht das Datagrammziel
Trennen Sie die Client-Assoziationsadresse, den zurückgegebenen SOCKS-Relay und das in jedem UDP-Paket kodierte Ziel.
0.0.0.0:0 in einer Indy-UDP-ASSOCIATE-Anfrage kann beabsichtigt sein. Diese Anfrage beschreibt den erwarteten UDP-Endpunkt auf Clientseite, und RFC 1928 erlaubt Nullen, wenn er unbekannt ist. Sie wählt nicht den endgültigen Dienst.
Die BND.ADDR/BND.PORT der Antwort bezeichnen den Relay, an den der Client gekapselte Datagramme sendet.
TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target serviceIn Indy ruft TIdUDPClient.Connect das OpenUDP des transparenten Proxys auf. TIdSocksInfo liefert die Null-Assoziationsfelder. Später übergibt SendBuffer den gewünschten Dienst an SendToUDP, der den SOCKS-UDP-Zielheader vor den Anwendungsdaten aufbaut.
Wenn die Assoziation gelingt, aber der Datenverkehr fehlschlägt, prüfen Sie den zurückgegebenen Relay, das kodierte Ziel und den UDP-Antwortpfad. NAT/Firewalls können den TCP-Austausch zulassen und UDP dennoch blockieren.
Halten Sie die TCP-Steuerverbindung offen; ihr Schließen beendet die Assoziation. SOCKS4/4a kennen diesen Vorgang nicht, und die Bezeichnung SOCKS5 allein garantiert nicht, dass ein Server UDP unterstützt.