I want all web traffic (HTTP, HTTPS and DNS - Are there any others?) goes through a local application and goes to a server application and from there goes to internet. How can I do this?
I have wrote an Async TCP server and I know socket Async programming in C# using SocketAsyncEventArgs (I am not a master with just one project but I think I can understand some basics).
The only way to do this is to write a Windows network driver - you cannot do this from userland. This is how VPNs work.
There are userland tunnels you can develop that tunnel a single connection, but they require the user to configure their applications to use it first, so you cannot unilaterally redirect all network activity.
From your question, I'm guessing you're not too familiar with Winsock internals or writing kernel network drivers, so for now I'm going to say I think this is a take above your level of competence right now.
However if you'll settle for a bit of an impure approach, you can implement a SOCKS proxy easily enough, but this requires configuring browsers to use your proxy server - at least this way you'll tunnel HTTP and HTTPS, however I'm uncertain about whether or not browsers use SOCKS servers for DNS or if they use the OS-provided DNS functionality.
Like #Dai suggested, use a SOCKS proxy. It operates above the transport layer, therefore a SOCKS server can be configured to serve any application protocol operating on typical TCP/UDP.
This is exactly what TOR does to mask all traffic, not just HTTP.
Related
Here's a scenario that I want to implement using C# or C++.
I want to connect PC-1 to PC-2 over internet and use PC-2 as the gateway for PC-1, so that all the outgoing and incoming traffic to PC-1 gets routed through PC-2. I know about using proxy servers and VPN. But I'd like to implement this on my own using 2 applications, preferably in .NET, that run on these 2 computers.
Edit: I need something similar to a VPN network, when I enable the program in PC-1 it should route entire traffic to PC-2 not just http traffic. I am not sure where to start with.
Any help would be highly appreciated.
My system has a server and multiple clients. the server has a service for the clients and each client has a service too, for talking to other clients.
I forward the server's service port manually on the router but the future client can not do it by him self after the installation.
Is there a way to automatically forward ports by code from the client side through the installation?
My main question is - Does this approach is wise? Should the system needs to be build deferentially?
Project details:
C# - WCF, Communication - NetTcpBinding.
The server is on my computer (Home network). Server's service port : 8080.
The clients can be installed everywhere. Client's service port: 8081.
*I'm not known with the IIS technology, can it help in this scenario?
The model you're describing sounds like a mesh network, generally you do not want clients to forward ports, be it automatically or not.
If it's absolutely necessary you could implement UPnP, there is an elaborate article here describing how to do so in .NET with a library. Note that you will have to select a different port.
I would strongly recommend to go for a different option though, having the server manage connections between clients is more managable and safer. There are very few valid arguments in favor of a model where a server is present and clients omit it at times:
Bandwidth, the server might not be able to handle all the data with reasonable throughput (i.e. torrent)
Security, the server might be only there for client updates (i.e. P2P chatclient with updater)
From the sound of it, your project does not apply to either.
EDIT: Because you have indicated the project is basically a torrent client, I would recommend reading up on the UPnP article.
I'm developing a multiple client / multiple server program in C#, and before I got down to the nitty gritty, I was wondering if anyone has ever worked on a similar project and might be able to share their tips / ideas for implementation.
The servers will sit on many PCs, and listen for incoming connections from clients (Or should the Servers broadcast, and the clients listen?).
When a client starts, it should populate a list of potential server IP addresses automatically.
When a server closes, the client should remove that server from it's list.
When a new server starts, the clients should be notified and have it added to their list.
A server may also act as a client, and should be able to see itself, as well as all other servers.
A message sent from a client to the server, that affects the server, should broadcast the change to all connected clients.
Should my server be a Windows Service? What advantages/disadvantages does that present?
Any ideas on how I might go about getting started on this? I've been looking into UDP Multicast, and LAN Scans. I'm using C# and .NET 4.0
EDIT: Found this: http://code.google.com/p/lidgren-network-gen3/ Does anyone have any experience with it and can recommend/not recommend it?
I would suggest NetPeerTcpBinding WCF communications to create a Peer Mesh. Clients and Servers would all join a mesh using a Peer resolver. You can use PNRP or create a custom peer resolver (.Net actually provides you with an implementation called CustomPeerResolverService). See Peer To Peer Networking documentation.
Also you can implement a Discovery service using DiscoveryProxy. With a discovery service, services can announce their endpoints. The discovery service can then service find requests (see FindCriteria) to return endpoints that match the requests. This is referred to as Managed Discovery. Another mode is Ad Hoc Discovery. Each service will announce their endpoints via UDP and discovery clients will probe the network for these endpoints.
I have actually implemented a Managed Discovery service in combination with Peer 2 Peer WCF networking to provide a redundant mesh of discovery services that all share published service endpoints via P2P. Using Managed Discovery I have found performs far better as Ad Hoc Discovery using UDP probing is slower and has some limitations crossing some network boundaries while Managed Discovery leverages a centralized repository of announced service endpoints.
Either/both technologies I think can lead to your solution.
So is this effectively a peer to peer style network (almost like bittorrent), where all servers are clients, but not all clients are servers.
and the requirements are every client should hold a list of all other servers (which are, in turn, clients).
The problem lies in getting the server IPs to the clients in the first place. You can use a master server that has a fixed DNS to act as a kind of tracker, which all of the servers check in to, and the clients check periodically.
Another option (or an additional method) is to use a peer exchange style system, where each of the clients and servers use UDP broadcast packets over a local network to discover each other and then transfer the servers they know of, kind of like a routing protocol. However if the PCs are spread out over a non local network such as the internet, there's little chance that they will ever discover each other on their own, making this method only useful when used in conjunction with other methods of finding servers. Also, you will probably have to deal with router UPnP to allow clients to connect to each other through each others router NAT, so this method is probably too complex for the gains you get. (However, if you're just on a LAN, this is all you need!)
A third option (and again, this sounds a lot like torrent technology), is to use Distributed Hash Tables to store information about the IPs of your servers in the cloud, without having to rely on a central master server.
I have had a shot at a project like this before (a pure P2P, server-less messaging system), but could never get it to work. Without a huge amount of peers, or a master server to track all of the other servers, it is very difficult to reliably retrieve the IPs of all the servers.
Basically, I want to know how can I intercept/sniff all tcp/udp network traffic for some specific application like the tunneling applications do? For example ProxyCap allows to tunnel all traffic for specific application to some proxy. So as I can understand those programs can intercept all traffic before they change/reroute it.
I've tried using winpcap but even Wireshark. But it doesn't work if you have proxycap installed. I mean, it does not capture application traffic:
Traffic from my program intercepted by the ProxyCap
ProxyCap redirects it all to localhost proxy
My localhost proxy is actually a Your-Freedom gateway proxy
Your-freedom proxy sends traffic to their servers (traffic goes to internet).
When I start Wireshark sniffing (which is based on winpcap driver) I see only traffic from step #4 (when it goes to the internet). And this traffic is not raw (it's packed/encoded) so it doesn't work for me to sniff it.
So since I need to sniff all the traffic I thought that I either find a way to sniff before ProxyCap (or after it, but I don't think it's possible since traffic redirected to the loopback proxy).
I want to ask you guys - is there a way to intercept/sniff traffic like ProxyCap (or other tunneling applications) do?
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.