Performing Local Testing in preparation for Reblaze WAF/DDoS Platform Deployment
Before you alter your DNS zone file to direct traffic for your web servers to pass through the Reblaze platform, you need to be confident that the platform will process that traffic as you expect.
This will verify
- that the platform is configured to handle your traffic
- that the platform can correctly access pages from your Origin Servers
- that your application works as expected when passed through the platform
- that your SSL traffic is handled with the correct and appropriate certificate
- that you are familiar with the features of the dashboard and the portal
Local testing can be done using a specific Hosts file entry to the Reblaze supplied specific IP address which the activereach support team will provide to you, or by using an internal DNS server with the target FQDN resolving to either the IP address we have provided to you or the portal visible CNAME.
Make sure that if you have a corporate proxy server that your test machine bypasses this or you will have the live non-Reblaze provided web server pages returned.
This may also be true if you are using PAC files or any other modification to your browser to direct it to a proxy server.
Additionally watch for anything that redirects HTTP requests like the ‘HTTPS Everywhere’ Chrome plugin or system level proxy plugins (such as the Webroot DWP).
Modifying Your HOSTs File
Alter the hosts file to point to the Reblaze specific IP address (because you can’t point to the CNAME in a hosts file). You can get the specific address for your Web App from your portal or by asking by activereach support team.
Details of how to edit your hosts file can be found at https://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/ though if you are using OSX these instructions are better – https://www.tekrevue.com/tip/edit-hosts-file-mac-os-x/
Note that your anti-virus software might prevent you from making changes to your hosts file. We have seen this behaviour with Avira but it may also be present in other AV applications.
You may also find our technical tutorial video for this will help.
Confirming Passage Through Reblaze
Access your web site and you can tell whether the traffic has come back from the Reblaze proxy if you look at the returned HTML headers as you will see
Server: rhino-core-shield
Details on how to see this in Chrome:
- View/Developer/Developer Tools/Network and reload the page
- Select the request in “Network” tab for which you want to see the headers
- Select “Headers” tab on the right pane
- You can see HTTP headers for the request
Details of how to see this in Firefox:
- Use Tools/Web Developer/Network and reload the page
- Select the element for which you want to see the headers
- The HTTP headers are displayed for that element on the right-hand side
If you do not see the reference to Reblaze in the headers, then the page is not being served via Reblaze and it is not safe therefore to make any DNS changes until this is rectified and confirmed.
If you cannot access the features in your browser to check the HTTP headers, you may be able to use a site like https://web-sniffer.net/ to do this.
Things to check
Watch for Origin Lockdown if the server is behind a load balancer. This stops the server responding to Reblaze because it expects to only speak to the load balancer. In this case we need to have the Reblaze IPs added to the relevant ACL.
You should test for all possible FQDNs that you may use to pass traffic to that Origin Server, typically this will be at least www.somewebsite.com and somewebsite.com for example, but it might include others like www.someotherbrandname.com etc
Note that if at the start of local testing you see one of your other corporate web sites rather than one you expected, we often find that you have not listed the correct Origin Server in the Web App you are testing.
You should also test using HTTPS if you expect your website or web application to be served over an SSL connection.
In general, we advise you to do your local testing in conjunction with activereach support staff (which may require you to have a purchased support plan) so that there is confirmation from wholly outside your corporate network that your pages are being served via the Reblaze platform. In particular SSL based sites can fail in a variety of complicated ways based on the combination of certificate, browser, platform, and scripting.
