As a system admin or developer, you’ll be routinely faced with the need to create a reverse proxy through a web server. Initially the task of setting up a target location for your redirected connection can seem like an extremely simple and effortless process. However, later, you’ll realize that your biggest challenge emerges when the authenticated layout within the server destroys the relative paths when you are modifying the structure of pre-set URLs. This will ruin your entire presentation as everything from videos, images, css style-sheets and any other resources won’t be accurately displayed. So, here’s a step-by-step guide that allows you to create a reverse proxy using IIS.
Step 1: Understanding what a URL rewrite really does
So, a URL rewrite is basically an IIS extension that you’ll have to download from:
http://www.iis.net/downloads/microsoft/url-rewrite.
This enables you to rewrite any URL while it is being executed either outbound or inbound, hence the name. This makes it the ideal too to create a reverse proxy, if your only purpose is to forward the request made.
Step 2: Entering URL Rewrites and Application Request Routing
In order to rewrite the code, you need to download and install software that allows you to reconfigure the contents of a response, when it gets volleyed back to client server. URL Rewrite 2.0 is the perfect tool for this as it allows you rewrite links without necessitating touching the coding in the actual application.
Here’s a list of software that you’re going to need:
- The latest version of IIS, compatible with all operating systems released after Windows 2008.
- URL Rewrite 2.0
- Application Request Routing
If you’re wondering where you can these modules from, Microsoft’s Web Platform Installer (WPI) would be the safest and quickest way to download and install them. The best part about using WPI is that it handles all dependencies, if any.
Step 3: Setup Routing
Now you’re going to have to setup inbound and outbound rules, but you’re going to have to capture all requests onto a root folder, in this case business1/*, so if you’re using a Default Web Site, anything that gets sent to http://localhost/business1/* will be linked through this rule, which will then rewrite it as www.business1.com, in compliance with HTTP vs HTTPS traffic rules.
The Code should look something like this:
<rule name="Route the requests for Business1" stopProcessing="true">
<match url="^business1/(.*)" />
<conditions>
<add input="{CACHE_URL}" pattern="^(https?)://" />
</conditions>
<action type="Rewrite" url="{C:1}://www.business1.com/{R:1}" />
<serverVariables>
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>
Now, let us set up a proper diversion, which involves the following steps:
- Rewrite the inbound rules, that will decipher the public address of you service.
- Rewrite the outbound rules that will rectify any relative and absolute links within the server answers.
Step 4: Write Inbound Rules
Once you’ve set up the application request routing code, you’re going to have to rewrite the inbound rules that will decipher incoming client request, using a public address. This will facilitate the transition to an internal server, as opposed to an exposed server, while also retaining parts of the request that do not need to be translated.
The figure below explains how this can be done:
You might also want to keep the following key points in mind.
- For the most part, you’d probably want to set the HTTP_ACCEPT_ENCODING server variable to zero or blank. If you don’t, you have to rewrite outbound rules in order to rewrite the response links. Also remember that you have to register a server variable in the View server variable screen if you plan on replacing it.
- The default code structure “^/(.*))” will is suffice for the bulk of your rewrites, but you’ll need different mechanism that need other pattern for things like ASP.Net form authentication and the return URL parameters. You’ll have to write several rules for each of the particular cases. And remember to activate the “Stop processing” of all rule flags.
- Your rewrite will not be limited to a site’s root folder and can redirect or even send the input URL as a parameter.
- Explicitly mentioning the prefix “http://” in to the rewrite URL will successfully add SSL offloading on to your reverse proxy. But if you want to retain the encryption, you’ll have to mention an additional condition on {CACHE_URL}, using the prefix “^(https?)://”, and then initiating rewrite URL with “{C:1}://”
Step 5: Write Outbound Rules
Once you’ve completed the inbound rule rewrite, you’re going to have to work on the outbound rules that will effectively modify the response sent from the client server. This is required if you want the links within to point to your reverse proxy instead of the actual server.
You might wonder whether you have to do this because it involves absolute links like (change http://soft1/icon.png to http://www.proxy.com/domain/soft1/icon.png), or even relative links like (change /icon.png to /domain/soft1/icon.png). Well, if you don’t do this:
- The client will request http://www.proxy.com/domain/soft1
- The inbound code rule will trigger and rewrite the address to http://soft1/
- The soft1 server will respond with a random http page that contains a <img src=”/icon.png”/>
- Finally, the client server will request http://www.proxy.com/icon.png that will lead to a “404 – page not found” error.
So technically, you will rewrite at least some of the links, unless of course, you have a single page application!
Some important tips while writing rules:
- You’ll have to assign one rule for relative paths (pattern ^/(.*)), and a separate one for absolute paths (pattern ^http://soft1/(.*))
- You can always rewrite absolute paths and make them relative ones.
- If you want the ability to rewrite, for example, 40x responses that will chain reverse proxies, you’re going to have to add a rule that will replace the server variable “RESPONSE_Location”
Author: Rahul Sharma
By Team FileCloud