Video lZVAI3PqgHc

[00:00] Hi, how's it going? My name is Jay. In this video we're going to have a quick look at how you can configure Nginx as a reverse proxy. This is a proxy being one of the most widely used uses for

[00:18] Nginx instance. Let's get straight into it. So what we're going to look at is of course we'll So, Perl could look at a high-level understanding of a forward proxy and reverse proxy.

[00:30] We'd look at the proxy class directive, which Nginx utilizes to forward the request to upstream or a backend server. And then we'll also look at redefining the request address. Essentially, we'll try and capture all the details of the original request error or the original client,

[00:47] and how to forward that details to the actual backend server via the proxy. So, before we jump in and talk about reverse proxy in particular, I'd just like to highlight the fact that Nginx is extremely lightweight, resilient, very, very popular as a web server,

[01:05] but the functionality of Nginx does not act, does not stop at reverse proxy or web server. The green boxes you see on the screen right now, these are all the functionalities you

[01:19] can achieve with a single instance of Nginx. Also on top of that you can run Nginx wherever you want. I've painted a few robots of a few cloud providers here, however you can run Nginx on any cloud as

[01:31] far as you've got a supported Linux operating system. With that let's get started. So the focus on this video is also the proxy. So let's jump right into it. So what exactly is a reverse proxy?

[01:44] So generally, there are two ways to think about a proxy. One is a forward proxy, which is essentially a client-side proxy, which conceals the identity or acts in place of the client.

[01:59] And the second one is a reverse proxy, which is a server-side proxy, which conceals the identity of the actual backend application service or at times acts in place of the backend application service.

[02:11] Organizations generally deploy Nginx as a reverse proxy and as I mentioned earlier this is the one of the most common use cases for Nginx instance. Now how does Nginx does that? Nginx does proxying by utilizing the proxy path directive.

[02:29] So the proxy path directive moves an incoming request to a request and destination at the backend. So address can be a domain name, an IP address, port, Unix socket, upstream name, or even a set of variables.

[02:46] Syntax for this redactue or the proxy bar redactue is very simple. It's proxy cast followed by a destination. And it's only generally utilized in a server and location context.

[03:00] In the example you see on the screen right now, what we have is hthtps.example.com. Nginx matches this specific request against the slash and forwards the request of the destination, which in this case is 10.1.1.4.

[03:14] So the destination IP address is most likely a web server or an application server sitting behind a firewall. And perhaps the IP address of the Nginx plus instance or Nginx instance which you see here,

[03:28] would only be the IP address which would have access to the back-end application server. So the client connects to this reverse proxy, and the reverse proxy, which is the Nginx instance, has access to the back-end application server.

[03:42] Sound easy? And it definitely is, and we'll have a look at how easy it is to configure reverse proxy in the demo after. However, one thing we need to understand is the behavior of NGNX.

[03:54] And NGNX's default behavior is to close the connection before it goes out and initiates a new connection to the backend. So in this process some of the original request information will be lost So for example when an original request is made from a client or a browser from your laptop

[04:16] it's the reverse proxy and the information goes to the back-end service. And you next terminate that connection at that reverse proxy point. So you want to try and ensure that you capture some of the details like the actual IP address of the original client, the first details, what you are,

[04:32] why did the request you want to try and capture it and you want to forward that to the back end or the actual application server. The reason for this task is because the log files of the back-end application server captures the request coming from Nginx instance and now if every single request

[04:47] has originated from the Nginx release proxy to try and make sense of the data which is collected at the back-end gets, it's an impossible task because every single request from the application

[05:02] for a perspective comes from variable proxy and you don't want that you want to try and capture the original IP address and follow that path. So how do we do that? In the example what we see right

[05:16] now what we can use is a directive called proxy set header and essentially what this directive does is it enables Nginx to redefine or rewrite the request header which comes in. So essentially

[05:29] in this case what happens is nginx replaces the host header with the variable which is dollar host when it sends the request to the backend server in the second example what we have here

[05:41] is a proxy set header captures the original ip address of the requester and forwards that to the backend application server essentially telling the backend application server that this is the ip

[05:54] of the original requester for this request. And the final proxy set header, what you see over here, creates a list of various addresses that the IP and the request has actually traversed through

[06:08] before it hits the back-end application server. So in some of the cases you probably have a couple of rep servers, a couple of proxies before the actual request hits the back-end

[06:20] application server. So in a scenario like that, Nginx would go out and collect all those IPs and send that information to the actual backend application server. So from a slide-wise perspective, this is all I had. So this just like the thing, gives

[06:36] you a high-level understanding of what a real course is that. So with that, let's quickly jump into a demo. So I'll show you how that actually works in action. What I have here on my local computer is a virtual machine.

[06:53] And this virtual machine... ... ... ... ... ... ... ...

[07:05] ... ... ... ... ... ... ... nginx-b and you see that I've got nginx24 installed on it.

[07:17] Let's jump in here and have a look at the configuration. So if you do cap nginx.cont, it's a stock standard configuration is what I have, nothing fancy over here.

[07:34] If I cd to comp3 directory, that is where I have my configuration code. You will ls on it. You see that I've got a default.comf, which essentially is acting as a real foxy.

[07:52] In my case, my backend application is still running on the same host. In your case, this application would be perhaps somewhere in the backend or could be a different IP address. In my scenario, it's that application is running on the local host. But it's chatweb.comf. This is the

[08:09] actual application which we are trying to run. So in this scenario, as you can see, Nginx is acting as a web server, hosting the application and also acting as a reverse proxy for this case So as simple as that I can go out and do curl localhost 9001

[08:38] This is the actual application. This is, in a way, the backend application which Nginx is routing to. So Nginx is acting as a Google's proxy, listening to port 80, and every time that request comes in, it proxy passes that request through the backing of the upstream server, in our case which is the port 9001.

[08:56] So, in a scenario like this, if I was to try and access this box for my local computer, so let's jump out here. I'll do this and what I have is open the terminal window and so what I'm doing is

[09:15] accessing my VM from my local machine. I'll just make a call and the IP address for this virtual machine is 192.168.153.187 and hit enter on there you get the

[09:28] response back that this is what it is actually doing. Let's see if I can actually access the actual application on port 9001 as well. Hopefully I should be able to access,

[09:40] but if I can, nothing to worry, but let's do the test. And yes of course, opening my test, so you should do this and go hit 9001, you're still able to access the backing application.

[09:54] In your production environment, this should be stopped because only the local host of the reverse proxy or the IP address of the reverse proxy will be allowed to access the backend application. But a simple test. However, the point I'm trying to make here is to try and

[10:10] show you what information gets captured in the logs. So let's just zoom in and have a look at the logs.

[10:22] So if you access the logs over here, you can see that these logs, it's not really giving you a lot of information so you can see the pass command is actually a code request in fact every single request is a code

[10:34] request so let's just go and make a browser-based request and hit refresh a couple of times so I'm just accessing the browser out here in fact I can just do that here as well

[10:48] example.com hit refresh a couple of times and let's look at the cat log right now and see what

[11:01] there we go we've captured some information however you can see it is not relevant information which we can utilize and you want to try and capture the actual requestor the URI which was requested and

[11:15] want to forward that to the backend application server. So for that let's go out and edit our config file to try and capture those specific details using the variable, using the directive we talked about earlier. So let's just jump in to get it from

[11:34] Topping map was most secure password and what I have is I have configured a few it's enter, essentially just to ensure that my fact fingers don't seal the show and I'm typing

[11:52] it correctly, I've got this pre-prepared. So leave it there. So essentially what we're doing is we're setting proxy set header and then the host and we're replacing the value with the variable. So the entire list of nginx variables is available on nginx.all where you can capture those values

[12:08] from by defining a variable itself. And being a little cheeky, and I've just added a sample header. So when we go access the browser, we just want to try and see that we've injected our response header, which we should be able to see.

[12:22] Okay, I'm just going to save this over here. Closes and grow CID and dimension Perfect So we reloaded the configuration everything works fine and if I was to try and do a curl on localhost

[12:42] and now this is port 9000, and I'm going to try and do a V to try and get more information. Let's hit enter, and hey, there we go, so the cheeky little header which I inserted, test header,

[12:55] has made it true in the response header. So essentially it goes to show that all the information which we provided, it is actually going out and capturing that. However, to try and test it, let's just try and write a custom log file

[13:08] so that we can actually view the specific proxy set header values which we have set. So for that, we need to create new log formats to try and capture the specific values we have inserted.

[13:20] So for that, I leave the file again, the Nginx Compile again. Just make this full screen so life's a little easier.

[13:39] And what I'm going to do once again is to save myself from embarrassment. I'll just copy and paste the text over here and also out here what we need is access

[13:57] logs. So essentially for this specific server we are writing that to a separate log file and this is also a very good practice so if you've got a few

[14:09] different servers running you want to try and create separate access files for capturing logs for each separate server. So essentially it's just very neat if something was to go wrong with it. We should try and dig through some data very very

[14:22] easy if you're writing a separate file. And out here I've just written a customized log format. I've called it custom log and that's what I'm utilizing out here. And I've just gone out and typed in some requests which I am capturing. Let's save

[14:37] that. Also I'll share the link to all these details in my GitHub repo which you can look on the links down below. Perfect. Now that we've reloaded that, let's go out

[14:53] and do cd-wag-o-gnax and see what file. And we've got the custom access of file. Let's just sale that file. And see what we get. So now that we've done this, at this

[15:11] state I'm just accessing it from the box itself so you see that the IP addresses and the host IP would all look very similar because everything's running from my local computer so let's just go out and hit enter here hit refresh and there

[15:26] we go it captured all the details out here as you can see that this is a Firefox travel so the user client it's captured all the details of the user client the proxy hosting it's routed so this request is routed to this specific

[15:39] backend. The proxy IP address is what you requested. The client IP address is exactly the same because I'm trying to access it from the inbox itself. So as you can see, it has captured all the information for us and it's populated

[15:54] right here. So in short, this is all I wanted to show you in terms of engineering Nginx as a proxy, setting proxies at header values to ensure that you capture all the values and pass it to the actual backend application server.

[16:08] and you can go out and make configuration changes in your log files to try and capture relevant information. Perfect guys, so thanks for watching the studio. I'll see you guys very soon. Thank you very much. Bye.

[16:38] Thank you.