I want to develop sock5 proxy server in c# which could make connections to client.
i.e in normal scenarios client or browser make connection to proxy server but i want the proxy server to connect to the client.
i googled a lot but could not find any code sample in c# or other language.
This sounds like a rather broad question, but generally I think what you are trying to do isn't "by definition possible". Socks5 is defined in RFC1928 (https://www.rfc-editor.org/rfc/rfc1928). It specifically relates to the 'client' connecting to the 'server'. In order for the proxy server to connect to the client, the client machine would have to have some form of service running and listening on a previously established port (assuming TCP/IP here). I suppose you could write some form of browser plugin or a service daemon to listen for server initiated connections; however, this wouldn't technically be 'socks5'. Having an open port (service) on your client open other security concerns, such as a connection from a machine claiming to be your server, or an outside machine requesting the proxy server to contact your client machine. Part of the trust model of these setups is the idea of client initiated actions. You may be trying to solve the wrong problem (i.e. you may need to reframe your problem in a different way).
Related
I want to make a website that connects to a clients internal server through a TCP connection in order to get a stream of data from an internal server in the clients computer (at a specific port).
There is a 3rd party program that when running simulations creates a 'telemetry server' at a specific port in the clients computer. I want my website to connect to that port on the clients computer and do stuff (plots) with that output.
I read about Blazor server-side app and though I give it a try since I know C# and I already wrote a program to graph said telemetry output data in C#. Now I want to make my program available to others though a website.
My program connects through System.Net.Sockets.TcpClient without problem. I even tested the connection on Blazor server-side app and it connects when the server is running on my computer.
System.Net.Sockets.TcpClient tcpclnt = new System.Net.Sockets.TcpClient();
state = "Connecting.....";
tcpclnt.Connect(myIp, 15151); // Telemetry server in port 15151
stm = tcpclnt.GetStream();
The problem is when I host my Blazor website in Azure, it is not longer able to connect. I tried writing my public IP in myIp and it doesn't work.
Unfortunately I don't get info error output from Blazor since the website just freezes with "An error has occurred..." message.
I don't know much about this (TCP connections, web connection rules, ports..) and would appreciate any leads on what could be wrong or if it is even possible.
EDIT:
I'm using server-side as suggested here since a client-side app wont be allowed to connect How can I use Socket in Blazor Client-side?
Are you using a Azure web app?
You might want to consider adding Azure Network Gateways to handle Routing rules. I think all apps and VM's in Azure need a application gateway to communicate outside of the Azure subnet.
I'm having difficulty finding help resources on this. I know how to use the TCPClient class to create a connection between one IP/Port/machine and another.
My doubt is how does that work when one machine wants to initiate a TCP connection to another machine where the destination machine is inside a different network. So the destination network may have hundreds of computers each with its own private ip and the network would have one public IP address. This would be using the TCPClient class or any other that is more appropriate.
I know we could use ports and then inside the network the port could be forwarded to the correct machine but I was looking for a solution like the one services like LogMeIn use. Basically I wanted to use port 80 always and then initiate the connection from the server to that particular machine or others on the same network when I needed.
I suppose, theoretically, I could create the connection first from inside that network, then on the server, save the details and close the connection and then in the near future, when I needed, I would re-open the connection.
So in my scenario, I would have many clients across multiple networks, each network might have multiple internal machines with a client installed. Then on the server I would initiate connection to these machines when needed. Within each network I would want to use port 80 for obvious reasons. The reason I want to initiate the connection from the server and not the client machines is simply to save resources, I couldn't cope with having opened connections until eventually I might need to communicate wit them.
Also, I have no control on the client networks besides them having my client installed.
Ideally, I wish to have c# info, possibly code and not network configuration.
I had this requirement at a previous company. We installed our client/server software (C# based) on numerous different networks with a mix of public/private IPs. I found two relatively simple ways to solve it. First, I want to say that without a public IP, its impossible to connect reliably (in my experience).
When I proposed the solution, I explained the problem to other developers/managers this way.
Your server, the machine with the public IP address [public to clients, but may still be an "internal address"], is like a house without any long distance calling. It can receive calls, but it can't make any calls. The clients are like houses with long distance service. Clients must call the server, because they have long distance. Once connected, any party can talk on the line.
From here you have two choices.
Client connects and never disconnects (this is what I implemented). On the server, I had an object that mapped the client object to the client connection so I could communicate any time with a client that was connected.
Server holds a queue of messages for the client. The client automatically connects on a fixed interval to see if there are any messages (maybe 5 minutes). There would be an option from the server to stay connected for a specific interval. Another vendor called this "fast talk".
There's a couple of approaches.
You could setup NAT - probably no good for your scenario.
You could make an outbound connection from your client.
You could "combine the above" by using STUN (see http://en.wikipedia.org/wiki/STUN) this is quite popular in VOIP for peer to peer scenarios.
The Windows Azure servicebus may have a solution for your problem; NetTcpRelayBinding in hybrid mode allows two comuters behind NAT to create a direct connection with each other. This might not solve your problem if you are money constrained as each connection has an associated cost.The simplest solution is probably to have the clients polling your server.
You may use SignalR, which has been developed for this kind of scenarios.
You must have a third party, though (a server which broadcasts messages from sender to other peers).
But the beauty of this technology is that it chooses the most appropriate way to push data to clients: Polling, long connections, sockets... etc.
This provides an abstraction layer which is quite comfortable.
It has been designed to interact with javascript clients, but may be used in full-C# clients as well.
You need a third server that acts as proxy between your machine and target machine that is behind a firewall.
That is how applications like LogMeIn work.
You can do this using SSH tunnels.
Please check https://serverfault.com/questions/285616/how-to-allow-remote-connections-from-non-localhost-clients-with-ssh-remote-port
The topic is about NAT traversal.
STUN is good choice to try to communicate with client behind NAT.
But if STUN don't work,you can use RELAY service to help to pass the message between your server and remote client.RELAY service is a public service that everyone can reach it.
I have a C# applications which acts like a client and it can be installed on any system which is directly connected to public internet (through data cards or port forwarding) or they can be behind router also (without port forwarding).
The other application which is developed using java acts like a server application which is on the public internet. Now, my java application wants to push a message to C# application which is behind router. Java application has the clients public and private (192.168.x.x) IP address. Java application is supposed to run 24x7.
So, now there are two options for me:
Whenever c# application starts it will establish a socket connection with java application and this socket connection will remain open till C# application gets closed.
Whenever Java application has something for C# application it will create a socket connection with C# application then it will push the message and then close the connection.
Now, with 1st option there is a problem that there will be lots of unnecessary connection since there can be thousands of client application and it may happen that on some day there will be nothing to push for some clients. and I don't know how to go for 2nd option.
What will be the right way to accomplish this task (option 1 or 2)?
Is UPnP protocol right for 2nd option? What are the open source UPnP libraries which has both the API's (C# and Java). I found one such called ohnet. Will it be a right thing for me? I didn't found a single small example for OhNet to test.
2) is not feasible if you don't have control over network configuration at the client end. It won't in general be possible for the server to make connections to the client if the client is behind any moderately secure firewall / router.
So you will in general have have to go for some variant of 1) where the client creates a connection to the server.
You don't necessarily have to keep the connection open though - it's always possible to get the client to poll the server periodically to check if there are any new updates.
If you want realtime updates to the client from the server then you will still need to keep a connection open. This isn't necessarily a problem if you use Java NIO you should be able to handle tens of thousands of simultaneous incoming connections relatively easily.
Using option 2, will you have to queue messages for your C# client until it connects? That could make your Java application run into out of memory problems if the C# application doesn't connect.
I would definitely use method 2 by adding a static route in the router (port forward). You should - however - ensure that the server behind the router is protected from the rest of your network (DMZ).
UPDATE:
Perhaps I have missed something here (method 1 or 2) :-) - but just to make it absolutely clear: It is always the client that should initiate the connection to the server. And yes, you could allow the client to request the server for updates on a regular basis.
This topic has been discussed million times before, but let me clarify my needs:
I need a single server which controls a system and includes the necessary functions. Furthermore, there will be "n" Clients which represents only the HI/GUI and call server side functions. The server itself should be able to send data back to the clients and call client-side functions too (like shutdown, exit and so on...)
I have heard about duplex services/contracts (http://msdn.microsoft.com/en-us/library/ms731064.aspx), but I'm not sure how far I'll come with that.
How would you handle this?
I recently made a proof of concept app that made both the server and the client host a WCF service each. The client connects to the server and then in a handshake call, gives the server the connection information to allow the server create a separate connection back to the client. It worked a treat with multiple clients on network links from local lan to 64k line on remote sites at the same time.
You could use WCF, and host the service on the server in IIS, in the application on the client and let the client register it's endpoint on the server.
I need to write an application that acts as a proxy between a client and a service. All I want to do is read the data that is traveling in both directions from client to service and vice versa. In essence I want this proxy to be able to be just plugged in without the need to reconfigure port settings in either the client or the service. Is this possible? Is there any specific library I could use in the C# .Net framework that will help?
EDIT: The service is on a remote machine.
EDIT: Example: Lets assume that the client is communicating to the service via port 1234 and the service is communicating to the client via port 5678. I want the application to listen and read the data traveling through these ports without actually reconfiguring either the client or the service. Is that possible?
If you are to read/listen/capture the data then it does not need to be a proxy. I would recommend WinPcap library (http://www.winpcap.org/). Although it's a C/C++ library, I don't think it's hard for a C#/.NET application to make use of it.
If you wanna redirect the ongoing connection as soon as your proxy program is up, the short answer is hard, really hard and impossible. As far as I've known, once the connection between 2 ends is established, no way you can change it (unless you have access to the router and modify its NAT on the fly, like a load balancer...). If you just want to read & not to modify the traffic data, use WinPcap or any packet sniffer. Either of these solutions are quite expensive to implement in term of money and technical work :)
Because you didn't give us what you actual wanna do, I assume that you don't need that "much" complexity. Here a solution just in case you meet the following prerequisites:
The client connects to the service via a domain name, not an absolute IP and vice versa. This is important because we are going to change the DNS in the host file to "fake" the end-point servers to our proxy server address.
You have access rights (administrator) to the client machine & the service machine to make any change.
Then what you should do next is to:
Change the IP of the hostname of your service server on your client machine to the IP of the proxy server. This just changes the result of the OS DNS resolver. Do the reversing way for the service server.
Drop & re-establish connections between 2 client machine & service server. Now, each connection is properly "proxied" via your proxy server.
Ha, quite intricate but it works I think... Hoping someone has better solutions for this situation and I'm looking forward to hearing that.