WEBVTT 00:00.230 --> 00:00.700 Heroine. 00:00.710 --> 00:01.700 And welcome back. 00:01.700 --> 00:06.710 So in today's video, we will be discussing about one of the interesting feature of Nginx, which is 00:06.710 --> 00:09.020 that of a reverse proxy based setup. 00:09.140 --> 00:14.990 So at a high level overview, a reverse proxy is a type of proxy server which retrieves the resource 00:14.990 --> 00:18.200 on behalf of a client from one or more servers. 00:18.200 --> 00:23.870 So this can be better understood with the diagram that we have here where you have a internal network 00:23.870 --> 00:27.530 on the right hand side and you have a client on the left hand side. 00:27.560 --> 00:33.500 Now when you discuss about internal network, one of the primary server here is the application server, 00:33.500 --> 00:40.130 which actually hosts the application for your organization and what you have, you have a Nginx server 00:40.160 --> 00:41.510 that is available Now. 00:41.510 --> 00:47.030 What will happen is when a client wants to load the application, what will happen? 00:47.030 --> 00:54.020 The request first goes to the Nginx server here from the Nginx server, it goes to the application server, 00:54.020 --> 01:00.090 it receives the response back from the application server and the response is sent back to the client. 01:00.090 --> 01:04.950 So this type of setup is referred to as a reverse proxy based setup. 01:04.950 --> 01:11.730 And this type of setup provides great amount of advantages, primarily because you have a Nginx that 01:11.730 --> 01:15.420 is sitting between the client and the application server here. 01:15.450 --> 01:19.770 Now a reverse proxy can play a key role in a lot of use cases. 01:19.770 --> 01:24.960 Some of them include it hides the existence of the original back end servers. 01:24.960 --> 01:31.950 For example, Client will never really know what are the IP addresses or what are the application servers 01:31.950 --> 01:33.680 that are running behind the scenes. 01:33.690 --> 01:39.630 Second important thing is that it can protect the back end servers from web based attacks, as well 01:39.630 --> 01:42.270 as denial of service attacks and various others. 01:42.270 --> 01:47.220 So basically what happens, let's say a client wants to bring down the application server so he might 01:47.220 --> 01:51.870 use various kind of attacks, maybe a layer seven attacks like SQL injection, etcetera. 01:51.870 --> 01:58.710 So what you can do is at the Enginex level itself, you can have a tight security control, maybe you 01:58.710 --> 02:03.450 can have a VRF, maybe you can have various denial of service controls, etcetera. 02:03.450 --> 02:10.020 So whatever attack that client is trying to send, it will be controlled at a enginex level itself. 02:10.020 --> 02:13.380 It will never reach your backend application server. 02:13.380 --> 02:17.730 So this is one of the great advantages of reverse proxy based setup. 02:17.730 --> 02:24.090 Along with that, you can also have caching functionality, SSL termination proxy and various others. 02:24.090 --> 02:27.600 So let's do one thing before we discuss more in detail about it. 02:27.600 --> 02:30.990 Let's quickly look into how exactly this setup looks like. 02:30.990 --> 02:34.470 So for today's demo, we have three servers that are available. 02:34.470 --> 02:38.640 First one is the Nginx proxy, second one is the application server. 02:38.640 --> 02:44.190 So very similar to what we were discussing, Nginx proxy here and the application server here. 02:44.190 --> 02:49.830 And third, we have the authentication server which will be discussing at a later part of this video. 02:49.830 --> 02:54.180 So first let's quickly look into this setup that we have discussed till now. 02:54.180 --> 02:58.860 Let's quickly open up the IP address associated with the application server. 02:58.860 --> 03:04.620 Let me paste it within the browser and here you see you have a simple message stating that this is a 03:04.620 --> 03:06.030 application server. 03:06.030 --> 03:12.810 Now we already have a reverse proxy based setup configured, so when a client makes a request to Nginx, 03:12.840 --> 03:18.450 automatically requests will be sent to application server, a response will be received and the response 03:18.450 --> 03:20.070 will be sent back to the client. 03:20.070 --> 03:23.670 So now let's open up the Nginx proxy IP address. 03:23.670 --> 03:25.410 I'll add it here. 03:25.530 --> 03:29.700 And again here you see it states this is a application server. 03:29.700 --> 03:36.780 So now at this stage the client does not really know that the actual response of this is coming from 03:36.780 --> 03:38.550 the backend application server. 03:38.580 --> 03:41.220 The Nginx is hiding that completely. 03:41.220 --> 03:48.030 Here now to quickly show you, I'm currently within the application server and let's do a tail f on 03:48.030 --> 03:55.530 var log nginx access dot log to actually show you that the request is being routed from the reverse 03:55.530 --> 03:57.540 proxy to this application server. 03:57.540 --> 04:02.130 So let's do one thing from the Nginx proxy IP ending with 90. 04:02.130 --> 04:03.330 So this is the tab. 04:03.330 --> 04:05.040 Let's do a control F5. 04:05.430 --> 04:10.440 And if you see over here, the request actually came to this application server. 04:10.440 --> 04:12.720 So this is the request that has come. 04:12.720 --> 04:18.000 Now if you look into the IP address here, that is ten 139 0.3. 04:18.000 --> 04:20.790 So this is basically a private IP address here. 04:20.820 --> 04:26.640 Now we had also made a request just the moment before from our web browser, and this request basically 04:26.640 --> 04:27.600 had a public IP. 04:27.600 --> 04:31.110 So this is my current IP address of my ISP. 04:31.200 --> 04:37.470 However, this new request that has come, this request has come from the private IP, which is nothing 04:37.470 --> 04:41.490 but the IP address of this nginx reverse proxy server. 04:41.520 --> 04:47.070 Now, in the idle environment, the client should not be able to directly communicate to the application 04:47.070 --> 04:51.690 server only the nginx should be able to communicate to the application server. 04:51.690 --> 04:57.990 However, for easy understanding, we explored both the connection of client to the application server 04:57.990 --> 04:59.790 first and the client to the. 04:59.970 --> 05:02.660 Techniques reverse proxy to the application server. 05:02.680 --> 05:09.430 Now, along with this, the nginx reverse proxy server can also route the request based on the Uri of 05:09.430 --> 05:10.110 that request. 05:10.120 --> 05:14.950 For example, let's say that there are two servers now you have an application server and you have a 05:14.950 --> 05:16.300 authentication server. 05:16.330 --> 05:21.700 Authentication server is basically used to authenticate a client, maybe through Gmail, maybe through 05:21.730 --> 05:23.140 username, password, etcetera. 05:23.140 --> 05:29.500 So when a client makes a request, this request, if you will see is associated with login dot PHP. 05:29.510 --> 05:31.360 So client wants to authenticate. 05:31.390 --> 05:35.280 Now Nginx receives this request and what nginx does. 05:35.290 --> 05:42.640 Nginx knows that whenever a authentication related request has come from the client, that request should 05:42.640 --> 05:44.440 go to the authentication server. 05:44.440 --> 05:51.340 And if you have a non authentication based request, that request should be sent to the application 05:51.340 --> 05:51.850 server. 05:51.850 --> 05:58.270 So you have great amount of flexibility related to the rules that you configure at a reverse proxy based 05:58.270 --> 05:58.720 level. 05:58.720 --> 06:00.620 So let's also look into it. 06:00.620 --> 06:01.670 So let's do one thing. 06:01.670 --> 06:04.600 This is the IP address of our reverse proxy server. 06:04.610 --> 06:07.040 Now we also have a authentication server. 06:07.040 --> 06:14.960 So this time when we make a request, something like admin index dot HTML, this time it is stating 06:14.960 --> 06:16.760 that this is a auth server. 06:16.760 --> 06:24.890 So basically Nginx determined that the client is trying to connect to a Uri of admin so it will go ahead 06:24.890 --> 06:29.870 and route the request to the authentication server and not the application server. 06:29.900 --> 06:31.910 Now let me also quickly show you. 06:31.910 --> 06:34.610 So this is basically the authentication server. 06:34.610 --> 06:39.800 Let's quickly do a tale on var log, Nginx access dot log. 06:40.100 --> 06:50.480 All right, now let's go ahead and do a Ctrl F5 and this time you see a request was made to admin index.html 06:50.480 --> 06:59.630 and this request was taken from a 10.1 39 .0.3, which is nothing but the IP address of a reverse proxy 06:59.630 --> 07:00.950 based nginx server. 07:00.950 --> 07:03.620 So this is basically the private IP address. 07:03.620 --> 07:09.170 So to avoid the confusion, let me quickly show you if I quickly do a ifconfig in our nginx reverse 07:09.170 --> 07:10.160 proxy server. 07:10.160 --> 07:17.240 So you basically have a private IP address here which is ten 139 0.3 and also the public IP address 07:17.240 --> 07:18.860 which is ending with 90. 07:18.890 --> 07:26.210 So from the browser, we had made the request from this specific IP address and then Nginx through private 07:26.240 --> 07:33.620 network, routed the traffic via ten 139 0.3 to the authentication server here. 07:33.740 --> 07:34.340 Great. 07:34.340 --> 07:40.730 So I hope with this you understood the basic concept of reverse proxy and also its associated architecture. 07:40.730 --> 07:43.190 And with this we'll conclude today's video.