Usually we can set up a proxy server by some kind of tools such as CCProxy which provides proxy services for HTTP, SOCKS, FTP packets etc.
Also, Proxifier or Proxycap is used to forward the packets of specific application on the client PC.
However, when UDP packets are forwarded to the proxy server, these packets cannot be correctly forwarded to the destination originally the application wanted them to go.
When I use a network analyzer to observe the UDP traffic flow, the UDP packets are just passed to the proxy server from my PC without going to the correct destination finally.
Besides, someone suggested that the UDP relay is not enabled in the proxy server so the UDP packets cannot be routed successfully. How can I enable the UDP relay function on the proxy server?(Assume that I can control the proxy server completely)
Any kind of proxy, whether it is for TCP or UDP, needs to be told where to forward outgoing packets to. That also allows the proxy to know who is requesting the forwarding so it can route matching inbound packets back to that same requester.
Lets assume SOCKS, for example. SOCKS v4 does not support UDP (or IPv6), but SOCKS v5 does. However, it requires the requesting app to establish a TCP connection to the SOCKS proxy and ask it to forward UDP packets on the app's behalf until that TCP connection is closed.
Tools like CCProxy, Proxycap, Proxifier, etc work (for TCP, anyway) by intercepting outgoing TCP conections and redirecting them to the proxy server, transparently handling any proxy handshaking to set up forwarding, before then allowing any application data to flow through the TCP connection. Once the TCP connection has been established, the proxifier does not need to do anything more with the connection since the app is now talking directly to the proxy.
I do not know if such tools support UDP. It would be much harder to implement, since there is no outgoing connection to redirect. Every outbound UDP packet would have to be intercepted, then the proxifier would have to check if it already has its own SOCKS v5 TCP connection associated with the packet's local/remote tuple and if not then create a new one and send the necessary UDP forwarding handshake, then encapsulate every outbound UDP packet for that tuple and send it to the proxy's outbound IP/Port, and receive every matching inbound UDP packet for that tuple from the proxy so it can be de-encapsulated and forwarded to the app's local IP/Port that sent out the original outbound UDP packet. And because UDP is connection-less, the proxifier would have to also implement a timeout mechanism on its SOCKS v5 TCP connection to the proxy so it can eventually be closed after a period of UDP traffic being idle.
That is a LOT more work for a UDP proxifier to do compared to TCP.
And that is just for SOCKS. HTTP/FTP proxies do not support UDP at all (since HTTP/FTP are TCP-based protocols). And there are other tunnel/proxy protocols as well, which may or may not have their on UDP capabilities.
So you have to check the capabilities of your proxifier tool to see if it supports UDP or not.
Related
I have an application that sends simple data over TCP (simple, no auth) and another application that must receive it. The only allowed connection between the two is UDP.
On the receiving side, I have SOCAT listening for incoming UDP packets and forwarding them via a TCP connection to the computer that hosts the software.
socat UDP4-LISTEN:5000, fork TCP-CONNECT:192.168.1.5:5001
On the sending side, I can send test data via
socat UDP4-connect 192.168.1.1:5000
There is a firewall in the way and I have no control over it which is why UDP is my only option. The firewall allows UDP out from the sender and UDP in to the receiver.
What I don't know is how to take a TCP connection on the sender and forward its output via UDP. And I don't know if this is the best way or if it will work at all.
Thank you
Here is my understanding of how a client-server HTTP server works.
The client creates a TCP socket connection to connect to the server and sends data.
The server creates a TCP socket connection to listen for incoming requests.
So it looks like both the client and the server need to agree on the use of the Transport protocol to use (in this case TCP). But if we want a website to work over UDP/QUIC protocol then we need both the client and the server to create a UDP socket connection. But some websites use TCP and others use UDP...
So does it mean it would need to look like this? To know beforehand which protocol a website uses?
if (URI == 'https://www.google.com') {
// Website that works over UDP
client.create.UDP.socket
client.sendData
server.create.UDP.socket
server.receive.data
} else {
// Website that works over TCP
client.create.TCP.socket
client.sendData
server.create.TCP.socket
server.receive.data
}
So the client needs to keep a record of which website uses TCP and which websites use UDP/QUIC and create that kind of socket to communicate with it?
If a protocol supports both TCP and UDP, the server listens both on the TCP port and the UDP port. The port number is generally the same, e.g. DNS uses TCP port 53 and UDP port 53.
Usually the client has a preference. Let's say it prefers TCP. The client will first try to connect with TCP. If the server does not respond, the client will retry with UDP. Alternatively, the server can respond over TCP but ask the client to switch to UDP. The client can then decide to continue with TCP or switch to UDP.
For QUIC 1 2, the browser will first connect using HTTP over TCP. The server will respond with a message stating that it also supports QUIC. If the browser also supports this protocol, the browser will reconnect to the server using QUIC.
The UDP ASSOCIATE request is used to establish an association within
the UDP relay process to handle UDP datagrams. The DST.ADDR and
DST.PORT fields contain the address and port that the client expects
to use to send UDP datagrams on for the association. The server MAY
use this information to limit access to the association. If the
client is not in possesion of the information at the time of the UDP
ASSOCIATE, the client MUST use a port number and address of all
zeros.
From RFC 1928, I interpret the text as that the DST.ADDR and DST.PORT is only useful for limiting access to the association(I take limiting access as preventing sending UDP through the association)，this makes sense to me.
By following the RFC, I already implemented client -> proxy -> remote for UDP relay.
Now the confusion I am having is how to implement remote -> proxy -> client, WHAT port to listen for remote packets and WHAT port of the client to forward the packets to? The RFC does not states this clearly.
Is it possible this Scenario without using webrtc?
Client A connects to Server
Client B connects to Server
Server send information to B and to A with each others information
A and B start talking directly using the same connection (by transforming their sockets info with the new port/ip address for example)
note: Client A and B doesn't have any socket server. They are only clients
Thank you very much.
It's definitely possible to set up a direct TCP connection, if at least one of the clients can accept an incoming TCP connection. In that case the server can just tell the other client what IP address and port to connect to, and then the two clients can communicate directly over the new TCP connection.
If both clients are behind firewalls or NAT, on the other hand, things get a lot more iffy -- in some cases you can use TCP hole punching techniques to get a direct TCP connection started; in other cases you're just out of luck.
In no case (AFAIK) can you modify an existing TCP connection to have new endpoints; a TCP connection's endpoints are fixed, and to get new endpoints you have to set up a new TCP connection.
I have an application (essentially a game) that is broadcasting game state data via UDP to many connected clients on a private LAN.
UDP works fine for broadcasting game state. Not having to configure the clients is important for this app. The client just read the UDP datagram stream and build up state as it goes.
But now I need the clients to reliably download a few pieces large data payload from the server. TCP is way better then UDP for that.
But we still rather not have to configure each and every clients with the host info.
It would be better to just embed an service advertisement in the broadcast UDP stream and then have each client see the advertisement and connect to the TCP host with no extra configuration on the endpoints.
Is there an standard way, or better, example code of advertising a TCP service via UDP. Preferably in C++.
The client needs to know the IP and port of the TCP server, that is all. If you can embed that info into your protocol it will work.
Actually, the UDP clients probably know the IP already because the UDP packets have a sender IP. Maybe this fact can help you.
One of the options here (maybe not for just a game but for some "enterprise" service) is setting up SRV records in local DNS.