My Intranet users are accessing the Internet through a proxy on the network. I need to monitor and filter certain requests to that proxy on a few machines. In essence, I need to proxy the proxy on the local machine.
How do I insert a local application as a relay between the local system and the Intranet proxy?
I would have to change the local proxy settings to an endpoint on the local machine, which in turn should relay HTTP requests to the outside proxy. But, I have no experience with writing proxies. Is this even possible?
Edit: The term I was looking for is tunneling, not proxying through a proxy. It is possible and I managed it with a TCP pipe.
Why not use an existing proxy server? This has all required capabilities and you don't have to worry about stability and performance.
I wrote a custom TCP tunnel that forwards requests to the Intranet proxy and pointed the browser proxy to the local machine.
Related
I'm having a windows application that will be deployed on multiple pcs in different networks. This applications need to launch some actions upon receiving appropriate request from external service.
For this, I got HttpListener that waits for requests and performs required actions.
The issue is with NAT and security. When windows application starts it needs to tell external service that it's alive and how it can be reached (being behind NAT it's not as trivial, some kind of tunneling is needed?). When external service needs something to be executed on windows application, it sends it a request and application should proceed with actions and send response to the server.
What is the best way to expose my Windows Application behind NAT to external service (tunneling?) and how to make it secure (HTTPS?)? Or, maybe, there is a better solution for this kind of remote calls (RPC?)?
Sending http requests to clients behind NAT means, that you have to manually create a route in your NAT router for each client that forwards a port on the external IP to a fixed internal IP.
To make it secure, you have two options:
Use TLS (https) = each client needs a cert and accept https
Leave the requests insecure but keep them in a "secure environment". This could be done with an VPN connection between your server and the NAT network (while defining the local network as secure).
Such a setup works fine if you want to run a server application (one host) and are willing to invest some time. It will typically shorten your life if you want to do that with a large amount of client applications in a company network.
There are technologies available to send messages to clients without having to configure anything on routers. For .Net we have SignalR which combines multiple approaches and uses "the best possible": https://dotnet.microsoft.com/apps/aspnet/signalr
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.
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.
I'm writing an application with both a desktop and a mobile app component. The desktop app is being written in c#, and I'd like to be able to open it up to act as a server for the mobile app (similar to what AirVideo does). How can I accomplish this without requiring the user to configure their firewall and/or router?
Ideally, I want to self host a restful wcf service in the desktop app. I've tried this already, but the automatic configuration of the firewall doesn't allow remote connections to the wcf service, since it appears to be hosted by the system process. Is there a workaround for this behavior?
Edit: I've solved the router problem as best I can through the use of the NATUPnP COM library (http://pietschsoft.com/post/2009/02/05/NET-Framework-Communicate-through-NAT-Router-via-UPnP.aspx). I still need to know how to allow remote connections through the firewall to a self-hosted WCF service without any manual configuration of the firewall (I'm okay with the user prompt to allow connections once the app is launched).
Set a specific port in your router that is designated to route to your server address,
So if your router real ip is a.b.c.d, you should set up that all communication to a.b.c.d:port# is being routed to your server local address. (a.b.c.d:port# --> serverIP)
The settings for this can be achieved from your router configuration.
In a situation where you cannot tinker with the router setting/firewall settings:
This means you cannot use ports to listen to incoming connections and can only use outgoing connections. to overcome that you will have to use a 3rd server with real IP-Address which will function as a listener for both sides. Typical scenario can be described as follows:
Client Side - A (Desktop)
Client Side - B (Smartphone)
Server Side - S (Communications Server)
S --> Open port for listening to incoming connections.
A --> Connect to S every x seconds to check if requests to do something are waiting.
B --> Connect to S. (issues a waiting request for A)
That way S is served as a proxy to glue both sides' communications.
I am a newbie in remoting concepts(C# Remoting).Actually i done some projects using
remoting concepts, i need to employ a proxy between the client and server , if client
wants to communicate with the server or vice-versa it should be done through this proxy
only.i saw a namespace Remoting.Proxy ,will it help? anyone giveme some suggestions on
how to do this it will be very useful for me.
I heard that if the request is through proxy it will be more secure.if my server address is(182.575.069.67) and my proxy runs in 192.168.0.8 then all my clients must send their messages to the proxy and the proxy server must forward this to the actual server.This is what i am trying to do
The "Proxy" namespace refers to the idea that there needs to be a local object, working en-proxy for the remoting client.
If you need all traffic to the server to go through a proxy, you should create two executables: the server, and the proxy server.
The server could accept requests only from the proxy service, while the proxy service itself could be promiscuous.
However, I'm not sure why you would need to set up a proxy service, since you should be able to put any of your autorization / authentication code directly into the server service anyways.
Proxies in C# (especially in the System.Remoting namespace) are local, in-process objects that represent an object in a different process.
They're named after the Proxy Object pattern, not after proxy servers.