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 service

In 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.

Ähnliche Artikel