proxy server
#############
#############
Read this quickly first (short reads):
http://stackoverflow.com/questions/224664/difference-between-proxy-server-and-reverse-proxy-server
http://www.f5.com/glossary/load-balancer/
http://www.f5.com/glossary/load-balancing/
http://www.f5.com/glossary/reverse-proxy/
My notes from above reading (and much more)
Forward and reverse proxy are easy to understand, imagine a server to client relationship without a proxy. All traffic goes directly between the 2. Now with a proxy introduced traffic has to go thru a middle man. The only difference between a Forward and Reverse proxy is who sets up the middleman/proxy, (is the middleman closer with the client or server – closer in relationship speak not distance speak). So in a reverse proxy, the server asked for there to be a middle man for all of the incoming traffic the server has to deal with. In a forward proxy, the client asked for there to be a middle man for all of the traffic going to servers (websites etc..). Reverse proxy is used to have a middleman for many servers usually thus implementing load balancing. The clients talk to the proxy (and the clients believe the proxy is the server) but in reality proxy then distributes the traffic to one of many servers (This is called Load Balancing, and reverse proxy is a huge part of it). Reverse proxy can also be used with one server, the proxy can take the incoming traffic and compress it, thus putting less load on the server (Intelligent Compression). So traffic between client and proxy is uncompressed, but traffic between server and proxy is compressed.
SQUID can be a reverse and forward proxy. I made an article on how to setup Forward proxy with squid: HERE. And here is an article on how to use Reverse Proxy with SQUID: HERE
Forward Proxy:
* Client configured proxy (proxy is thus “closer” to client, not closer by distance terms, in reality distance can be any which way)
* Communication between Client and Proxy is secretive
* Proxy talks to Servers (instead of client talking to server), but servers don’t know about any client. servers think they are ONLY talking to proxy (they don’t know proxy is extending the information further to client – or many clients). Server is tricked into thinking that the proxy is actually a “client”
* Client knows its talking to Servers (but middle man thru Proxy) and they know the servers (can get info about server).
* Client is the mischievous entity, proxy is the mischievous entity’s middle man (doing the talking that the clients doesn’t want to do, and making the servers think its the main client)
Reverse Proxy:
* Server configured proxy (proxy is thus “closer” to server, not closer by distance terms, in reality distance can be any which way)
* Proxy talks to clients (instead of servers talking to clients – thus servers are safe), but clients don’t know about servers. client doesn’t know that proxy is not the “server”.(client doesn’t that the proxy is extending the information further to the servers – or many servers, a.k.a. load balancing). client is tricked into thinking the proxy they are talking to is the “server”
* Servers know that they are talking to many clients, and they know the clients (can get info about client).
* Server (or many servers in load balancing case) is the mischievous entity here, and the proxy is the mischievous entity’s middle man (doing the talking that the server doesn’t want to do, and making the clients think its the main man)
Below examples deal with website servers, but can apply to all.
##############
forward proxy
##############
What it is: middle man for clients that go to internet
—
Normal communication:
CLIENT->SERVER
With Proxy:
CLIENT->PROXY->SERVER
Looks more like this (the relationship of with proxy is made between CLIENT and PROXY)
(CLIENT->PROXY)->SERVER
From servers point of view
PROXY->SERVER
SERVER sees the PROXY, but he doesn’t know its a “proxy”. Server just thinks its a “client”. It doesn’t know that its client is actually doing mischievous middle-manning.
Who thinks what:
CLIENT thinks its talking to SERVER (CLIENT knows about SERVER)
SERVER thinks its talking to PROXY (SERVER thinks the PROXY is the “client” of its communication, but in reality its communication is going farther)
—
Normal communication:
X->Z
Imagine this:
X->Y->Z
X = your computer, or “client” computer on the internet
Y = the proxy web site, proxy.example.org
Z = the web site you want to visit, www.example.net
Who thinks what:
X thinks its talking to Z (it knows about Y)
Z thinks its talking to Y
Reasons to use:
1) X cant access Z (admins at X blocked Z because Z has too much porn)
2) Z blocked access from X (because X is hacking too much)
With forward proxy:
*X had to setup a deal with the proxy Y to use the proxy
*So X talks only to Y (X thinks its talking to Z) (so Reason 1 will work)
*And Y talks to both X and Y but separately
*When Y talks to Z (Z doesn’t know its actually responding to X, it thinks its only talking to Y)
Thus Reason 2 will work because Z only thinks its talking to Y
—
Examples: ssh -L or -D the pc that command is ran from is the client
##############
reverse proxy
##############
What it is: middle man for servers that talk to clients on the internet
—
Normal communication:
CLIENT->SERVER
With Proxy:
CLIENT->PROXY->SERVER
Looks more like this (the relationship of with proxy is made between CLIENT and PROXY)
CLIENT->(PROXY->SERVER)
From servers point of view
CLIENT->SERVER
SERVER sees the PROXY, but he doesnt know its a “proxy”. Server just thinks its a “client”. It doesnt know that its client is actually doing mischiveous middlemanning.
Who thinks what:
SERVER knows its talking to CLIENT (and it knows about PROXY)
CLIENT thinks its only talking to PROXY (CLIENT thinks PROXY is the “server”, but in reality its not the main man)
—
Normal communication:
X->Z
Imagine this:
X->Y->Z
What is x,y,z:
X = your computer, or “client” computer on the internet
Y = the reverse proxy web site, proxy.example.com
Z = the web site you want to visit, www.example.net
Reality of things:
Y the proxy becomes the public facing server
Z is the server with the main content but its not public facing
Who thinks what:
Z knows its talking to X (and it knows about Y)
X thinks its only talking to Y
Examples:
* load balancers are reverse proxy (load balancer knows about many servers, clients connect to load balancer thinking its the main website/server, but load balancer distributes packets based on layer4 or layer 7 questions to the appropriate servers. Servers know about their individual client connections. If its a load balancer that distributes by protocol then its a layer 4, if its a load balancer that looks at the packet data to decide where to distribute then its layer 7) – reverse proxy is in the same network (behind the same firewall as the servers)
* shells is reverse proxy and its done like this: ssh -R, the pc that command is ran from is the server. The reverse proxy is in the cloud (not in the same network as the servers, thus an opening can be maintained on the firewalls)
Reasons to use:
1) Lots of traffic many servers, one middle man (reverse proxy):
* Load-balancing: Z wants to force all traffic to its website thru Y first. Y can be a broker of a sort, a middle man but on the side of the server.
2) Z is worried about showing off its servers to the world.
* Making your main servers hidden and showing off to the world less important machines.
3) tl;dr You can use this to have another type of communication that breaks NAT, meaning if there is a firewall that doesnt allow certain inbound communication (because a port is not open – not port forwarded) – we can still get in.
Imagine this setup (for this example I will focus on Reverse SSH, aka reverse ssh proxy):
All that needs to happen is this:
* client(your home pc)–>server(your work pc)
That’s the mission.
However your blocked by an annoying firewall:
* client->Firewall->Server
Client trying to reach server would fail at firewall(work firewall)
So your home pc cant get to work pc because blocked by work firewall (typical!)
* client->| Server (meaning client fails connection to server because of the firewalls inbound blocking)
* The end game that will get you thru will look like this:
* client->proxy->firewall->server
* homepc->proxy->firewall->workpc
Since we are using ssh for the proxy-ing: the firewall will not know about homepc because packets are ssh encrypted
Who thinks what:
* client will think its talking to proxy
* server will think its talking to client (it knows there is a proxy – we setup the connection to the proxy from the server)
Important side notes:
* proxy server needs to be outside of the firewall of the servers(work pc) network. So that an opening can be maintained on the firewall for the client to later access (on behalf of proxy/masked as the proxy)
* ssh is a client ssh tool, its used to connect to ssh servers, this tool is only on the pc that you need to access (the one that is behind a strict firewall)
* openssh or sshd is an ssh server, that’s what’s on our beloved www.proxy.com server
* For this to work the ssh server (openssh or dropbear) only has to be on 1 machine
* the work machine has a service you want to access, that service maybe a website(exmple2), or maybe its also the work pcs ssh server (example1). So in example1 there are 2 ssh servers (one on proxy, and one on work pc). Dont let the
So to fix that:
To make the proxy server a usable one in this scenario we need to make it an ssh server:
* The proxy can be an ssh server (lets say its provided by openssh or dropbear who cares – its a free ssh server)
* ssh server gives us the benefit of encrypted packets
Client—->not encrypted—>proxy<—encrypted<–firewall<—-encrypted<—server
Easy to remember: packets are encrypted from proxy to server and vice versa. they are encrypted on the longest route. (usually the proxy is closer to client, and as you will read later on the proxy can be the client as well and client can be the proxy)
One example:
* Server has a continuous ever lasting connection to proxy, (the firewall allows all outbound connections to be made outbound, most firewalls do)
Setting up the connection from Work to Proxy (its encrypted because of ssh – thus work firewall doesnt know anything):
* your work pc makes a continuous connection to the server, its a typical port 22 tcp outbound connection that a firewall will allow (in this case the ssh/proxy server will listen to ssho n port 2222). And this connection lasts all day and night, so when you get home that connection is still in place. At work pc issued this command “ssh -R 54321:localhost:22 www.proxy.com -p 2222”. Meaning work pc connect me to www.proxy.com which listens on ssh on port 2222 tcp. Then tell that www.proxy.com to have a port open on its system and that port is 54321 tcp. So that when another computer (can be the proxy itself) connects to the proxy on port 54321, it will be shot over (tunnelled) all the way to the work pc’s port 22 (work pcs port 22)
Connection from home:
* When your home you connect to the proxy on a certain port (5431), which then is really a connection between you and your work pc port 22, so now you have complete control of your work pc from home on port 22.
* Your command is “ssh www.proxy.com -p 54321” and you will be connected to the ssh server on your work pc (note in this example since we are trying to access the work pcs ssh server, there was another ssh server. however for this reverse proxy via ssh to work you will need only 1 ssh server – as seen below – the ssh server on the proxy is the required one)
Another example:
* Server has a continuous ever lasting connection to proxy, (the firewall allows all outbound connections to be made outbound, most firewalls do)
Setting up the connection from Work to Proxy (its encrypted because of ssh – thus work firewall doesnt know anything):
* your work pc is a webserver and you need access to it from from. At the work pc you make an outbound connection to an ssh server (this time on typical port number 22) and this connection lasts all day and night. When you get home that connection is still alive. The command that you issues at the work pc “ssh -R 54321:localhost:80 www.proxy.com” or also this would work “ssh -R 54321:localhost:80 www.proxy.com -p 22”. By default ssh tries to connect to specified server (www.proxy.com) on port 22 so you can tell it to connect on 22 or just dont tell it what port to connect on (it will still use 22).
Connection from home:
* When your home you connect to the proxy on a certain port (5431), which then is really a connection between you and your work pc port 80 (a webserver). So open up a browser and go to “http://www.proxy.com:54231” and you will be greeted with the work pcs site (note if the work pcs needs other protocols not just ssh to make the site work, then your out of luck on those services working, but http will work)
Note about who is connecting and who is listening ports:
* In example 1 where the work pc was an ssh server we were trying to access from home:
work pc had listening on port 22 with openssh or dropbear ssh program
After the ssh -R command:
proxy server was now listening on port 54321 with openssh or dropbear ssh program
Also proxy server was constantly listening on its port 2222 with openssh or dropbear ssh program
Connections:
Work pc to proxy/ssh server 2222 (and 2222 is being listened to)
(NOTE: source port from work pc is randomly generated here)
Client connecting to PC when about to access work pc, connection is made from client to proxy port 54321 (54321 is being is listening on by proxy)
(NOTE: source port from client pc to port 54321 is randomly generated)
* In example 2 where the work pc was a web server we were trying to access from home:
work pc had listening on port 80 with apache2 webserver
After the ssh -R command:
proxy server was now listening on port 54321
Also proxy server was constantly listening on its port 22
Connections:
Work pc to proxy/ssh server 22 (and 22 is being listened to)
(NOTE: source port from work pc is randomly generated here)
Client connecting to PC when about to access work pc, connection is made from client to proxy port 54321 (54321 is being is listening on by proxy)
(NOTE: source port from client pc to port 54321 is randomly generated)
How path looks like:
* Example1: Connection from home pc to proxy is on port 54231, then when packet gets to proxy:54321 it will be immediately transposed to go to workpc:22 (and it will look like its sourced from proxy:2222)
* Example2: Connection from home pc to proxy is on port 54231, then when packet gets to proxy:54321 it will be immediately transposed to go to workpc:80 (and it will look like its sourced from proxy:22)
Note about client pc can be the same as the proxy pc (home pc can be the proxy as well):
As long as from work you can access your home pc. Then from home you can access your work pc (dont even need a separate proxy), just make your home pc the proxy. But wait then its not a proxy? Well the traffic is still encrypted and the firewall wont know anything either way.
The proxy in both examples was a separate entity all together called www.proxy.com. But we could of just set the proxy server to be our home pc. So that the home pc who is the client is also the proxy server.
* homepc,proxy->firewall->workpc
* At work you would connect to your home pcs ssh server instead of www.proxy.com
“ssh -R 54321:localhost:22 www.home.com”
“ssh -R 54320:localhost:80 www.home.com” (notice i changed number to 54320, to illustrate that you can have several connections just not to the same ports, listening ports need to be different)
* Then to connect from client to server you will need the proxy. But wait the client is home pc and so is the proxy. So just have the client connect in on localhost. So to connect to work pcs port 22 from homepc/proxy: “ssh localhost -p 54321”. To connect to webserver on workpc from homepc/proxy, browse web to “http://localhost:54320”