WEBVTT 00:00.230 --> 00:00.740 Everyone. 00:00.740 --> 00:01.740 And welcome back. 00:01.760 --> 00:05.420 Now, in today's video, we'll be discussing about real IP. 00:05.570 --> 00:07.730 Now, this is a very important topic. 00:07.730 --> 00:12.950 And in fact, in the environment where you have a reverse proxy based setup, this is something that 00:12.950 --> 00:15.680 you will be doing in a production environment. 00:15.680 --> 00:18.440 So let's go ahead and look into it in more detail. 00:18.470 --> 00:25.370 So before we discuss about the real IP, let's look into what is the problem associated with a basic 00:25.370 --> 00:27.010 reverse proxy based setup. 00:27.020 --> 00:30.630 Now let's assume that there are three entities that are involved. 00:30.650 --> 00:33.080 First one is a web browser of a client. 00:33.110 --> 00:38.090 Second one is the Nginx reverse proxy, and third one is the actual backend server. 00:38.090 --> 00:42.800 So the IP address of the client is 192 1680.5. 00:42.980 --> 00:48.410 IP address of nginx is zero dot ten and the IP address of web server is zero dot 20. 00:48.440 --> 00:52.970 Now when a web browser sends the request to the reverse proxy. 00:53.000 --> 00:57.200 Reverse proxy will take this request and send it to the backend server. 00:57.200 --> 01:03.750 Now this backend server in its logs, it will assume that this request is coming from the Nginx reverse 01:03.750 --> 01:07.770 proxy and actually the request is also coming from the Nginx reverse proxy. 01:07.770 --> 01:14.010 But this backend server does not have any way to know the origin of the request. 01:14.010 --> 01:21.000 So the origin of the request is this client's web browser which has the IP address of 1921680.5. 01:21.030 --> 01:26.580 Now, for many of the use cases in production environment, there is a binding that needs to be done 01:26.580 --> 01:28.410 at a client IP level. 01:28.410 --> 01:35.670 So when you require a binding that needs to be done at a client IP level and the client IP address is 01:35.670 --> 01:41.700 not really reaching the application, then such use cases are very difficult to work upon. 01:41.700 --> 01:50.550 So it is considered as a best practice that Nginx will also share the real IP of the client to the backend 01:50.580 --> 01:51.180 server. 01:51.180 --> 01:58.170 So in the earlier case, if you look into the backend server, it has a log of gotta get request from 01:58.170 --> 02:02.250 192 1680. ten, which is the IP address of nginx. 02:02.250 --> 02:07.050 But in the ideal way of doing things in production environment, you will see it. 02:07.050 --> 02:16.680 Now states got get from 192 1680.5, which is nothing but the IP address of the originating client and 02:16.680 --> 02:21.450 this way of doing things is achieved with the help of real IP. 02:21.540 --> 02:24.420 So let's go ahead and look into it practically. 02:24.420 --> 02:30.870 So currently I have a reverse proxy server on the first tab and the backend application server on the 02:30.870 --> 02:31.680 second tab. 02:31.680 --> 02:36.270 Now in the application server, let's do a tail F on the access dot log. 02:36.270 --> 02:42.730 So currently I'm in the var log directory and from the reverse proxy server let's quickly do a curl 02:42.780 --> 02:46.830 localhost or let's do a curl from my web browser itself. 02:46.830 --> 02:51.750 So from my browser, let's go ahead and send a request to the Nginx reverse proxy. 02:51.780 --> 02:54.750 Now we are getting this is application server backend. 02:54.780 --> 02:56.340 This is completely fine. 02:56.340 --> 03:03.540 Now if you look into the application server log, it states that the request is received from an IP 03:03.540 --> 03:10.830 address of ten 139 0.2 This is nothing but the IP address of the nginx reverse proxy server. 03:10.830 --> 03:17.370 So if I do ifconfig you will see this is nothing but the IP address of the reverse proxy server. 03:17.520 --> 03:27.330 Now if you look into the logs associated with the reverse proxy in this log, you are actually getting 03:27.330 --> 03:29.100 the originating client IP. 03:29.100 --> 03:32.850 So this is my current ISP IP address here. 03:32.850 --> 03:37.260 So just to avoid the confusion, let's refresh the page again. 03:37.260 --> 03:38.610 So I'll refresh. 03:38.610 --> 03:43.830 And now you see this is my current IP address of my ISP. 03:44.010 --> 03:50.970 So Nginx reverse proxy is getting the IP address of the client, but the backend server is not really 03:50.970 --> 03:52.860 getting the IP address of the client. 03:52.860 --> 03:54.090 So what we want. 03:54.120 --> 04:01.650 We want to tell Nginx that this specific IP address should also be forwarded to the application server 04:01.650 --> 04:02.490 as well. 04:02.490 --> 04:09.120 So application server should receive both the IP address of the Enginex reverse proxy as well as that 04:09.120 --> 04:10.020 of the client. 04:10.020 --> 04:12.660 And this is the purpose of today's video. 04:12.750 --> 04:20.070 Now what we need to do is we have to add certain configuration, both at the reverse proxy level and 04:20.070 --> 04:21.600 the backend server level. 04:21.600 --> 04:28.680 So what we have to add at a reverse proxy level, we have to send the IP address of the client to the 04:28.680 --> 04:29.520 backend server. 04:29.520 --> 04:34.320 So this is the reason why we have this configuration here of proxy set header. 04:34.320 --> 04:37.680 So we are adding a new header of x IP. 04:37.890 --> 04:40.740 And what is the value associated with this header? 04:40.740 --> 04:49.020 It is remote underscore ADR and also to capture this specific data that is coming from the reverse proxy, 04:49.050 --> 04:52.620 we also have to add the configuration at the backend server level. 04:52.620 --> 04:58.060 So let me quickly show you now when I quickly do a cat on Etsy. 04:58.140 --> 04:59.840 Nginx Enginex. 05:00.230 --> 05:03.110 Conniff over here if you look into the log format. 05:03.140 --> 05:09.590 The log format, the first field that is being captured is the remote underscore ADR, which is nothing 05:09.590 --> 05:12.000 but the IP address of the remote client. 05:12.020 --> 05:16.910 So this is the specific field which is associated with this variable. 05:16.910 --> 05:24.290 And since we want this specific IP address to be sent to the backend server and hence we are adding 05:24.290 --> 05:29.360 a remote ADR variable over here associated with the real IP. 05:29.750 --> 05:37.910 So now what we need to do for the proxy dot conf, we also have to set a header here, so let's add 05:37.910 --> 05:38.270 it. 05:39.110 --> 05:39.710 All right. 05:39.710 --> 05:45.680 So now what we are doing, along with sending the request to the backend server, we are also adding 05:45.680 --> 05:53.540 a new header of real IP which contains the value of the remote ADR here, which is nothing but the IP 05:53.540 --> 05:59.420 address of the originating client and we are sending it to the backend application server. 05:59.630 --> 06:01.740 All right, so this is the first step. 06:01.900 --> 06:03.650 I'll quickly do a next. 06:03.720 --> 06:04.920 Things are successful. 06:04.920 --> 06:07.470 Let's quickly do a restart of enginex. 06:08.460 --> 06:09.240 Perfect. 06:09.270 --> 06:17.670 Now at this specific stage, when I refresh still here, you will see that it is only showing you the 06:17.670 --> 06:19.500 IP address of the reverse proxy. 06:19.500 --> 06:23.530 It is not really showing the IP address of the originating client. 06:23.550 --> 06:25.790 So now at this stage what is happening? 06:25.800 --> 06:33.660 The reverse proxy server is sending this remote addr value to the backend server, but the backend server 06:33.660 --> 06:37.460 log does not really have anything to capture that part. 06:37.470 --> 06:40.890 So now what we have to do, we also have to capture it. 06:40.890 --> 06:45.870 So from the backend server where we also have Nginx that is running, let's do a control C. 06:46.560 --> 06:49.110 If I do a PWD, we are in var log. 06:49.290 --> 06:55.290 Let's quickly go to Etsy Nginx here and let's modify nginx.conf. 06:55.440 --> 06:57.500 All right, nano is not there. 06:57.510 --> 06:59.610 Let's install nano here. 07:00.300 --> 07:00.930 All right. 07:02.310 --> 07:10.800 So now in the log format here under the Http context, we also have to add a field that will fetch the 07:11.100 --> 07:13.770 real IP base header that was set. 07:13.800 --> 07:16.500 So similar to what we see in this slide. 07:16.500 --> 07:17.930 We have to capture this. 07:17.940 --> 07:19.710 So let me add it here. 07:20.430 --> 07:20.850 Great. 07:20.850 --> 07:23.400 So now we are adding it at the last. 07:23.400 --> 07:25.980 So now what will happen in the log? 07:25.980 --> 07:30.300 At the last section you should see the originating client IP. 07:30.540 --> 07:32.220 All right, I'll save this. 07:32.490 --> 07:36.210 Let's do a nginx to verify things are successful. 07:36.510 --> 07:45.300 Let's do a systemctl restart nginx and let's do a tail on var log nginx access dot log. 07:47.750 --> 07:50.390 So now let's refresh the page again. 07:52.710 --> 07:59.010 And this time you see at the start you are getting the reverse proxy IP address and at the end you are 07:59.010 --> 08:02.160 getting the IP address of the originating client. 08:02.190 --> 08:02.790 Great. 08:02.790 --> 08:10.110 So I hope with this you understood the importance of the real IP, the importance of the proxy set header 08:10.110 --> 08:16.350 at the reverse proxy level and also the need of modifying the configuration at the backend server level 08:16.350 --> 08:17.050 as well. 08:17.070 --> 08:19.680 So with this, we'll conclude today's video.