El experimentador que no sabe lo que está buscando no comprenderá lo que encuentra. (Claude Bernard).
Building a Quick Reverse Proxy
Obtener enlace
Facebook
X
Pinterest
Correo electrónico
Otras aplicaciones
Thanks to: https://joshuarogers.net
In theory, a reverse proxy is extremely similar. The difference is that whereas a proxy server normally proxies outbound traffic, a reverse proxy proxies inbound traffic. By parsing all of the incoming requests, we can perform filtering and load balancing, or as we plan in this case, we can hide several servers behind a pool of IPs and decide which one to should be used to field our request based on the HTTP headers.
###The Setup### Assuming we’ve already got an Ubuntu machine available, we should be able to get NGinx installed extremely quickly. If you’re using another platform, be it Windows, Mac, or another Linux, you can still run NGinx, but you’ll need to find the correct installation method for your particular system.
sudo apt-get install nginx
Simple enough.
###Configuration### Next, we’ll need to add some configuration directives for NGinx to follow. For the following steps, I’ll assume NGinx configuration to reside in /etc/nginx. Let’s create a new configuration file in /etc/nginx/sites-available. We’ll name it after the site we’re proxying. In this case, we’ll do /etc/nginx/sites-available/jira.conf.
The first thing that we’re going to need to add is a definition of our upstream server. In our case, we’ll assume that Jira is using it’s default port (8080) and that it is hosted internally on 10.1.2.3.
upstreamjira{server10.1.2.3:8080;}
Next we’re going to need to let NGinx know which requests should be handled by our new rules. For this, we’ll add a server section to the configuration. This will tell it to listen on port 80 of all NICs, and to only field requests for jira.example.com.
server{listen*:80;server_namejira.example.com;}
Now that we’ve directed NGinx which sites should be affected by our directives, we should define what the directives actually are. For this, we’ll add a location item inside of the server item.
We’re doing several things here. To start with, we’re defining that requests should be proxied to the upstream that we defined earlier. 2 Next, we’re going to define a few headers that should be passed along upstream. To start with, we’re going to make sure that the host header being sent to the final server is the same as we received. Next, we add some information about the machine requesting the page into X-Real-IP and X-Forwarded-For. Finally, we set a three minute timeout for connecting to the proxy, and another three minutes for receiving, or sending data. 3
At this point, our completed configuration file should look as follows:
###Verification### With the configuration complete, we have a total of three more actions before we’re done. Earlier, we placed our configuration file in /etc/nginx/sites-available. While it is good to keep a copy of the configuration there, NGinx won’t actually load it from here, so we need to create a symlink to this file in sites-enabled.
Now that we’ve linked the file into place, let’s have NGinx verify our configuration doesn’t have a problem.
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
If there were no errors, we should be able to restart NGinx now.
sudo service nginx restart
Requests to jira.example.com should now show our actual Jira instance, without having to dedicate an IP just for it. By repeating this strategy at the network gateway, we can greatly expand the number of servers we can provide external access for without having to add more IPs. 45
###Edit### The last configuration file said ‘localhost’ originally instead of ‘10.1.2.3’. Props to David Ruttka for noticing. Also, added note four about timeout length.
###Footnotes### [^1]: They noticed. Oh, believe me, they noticed. They’re probably emailing you about it right now.
Actual content filtering assumes that we aren’t using HTTPS. At that point, the best we could do would really be host-based filtering. ↩
Technically we didn’t have to defined the upstream. We could have just defined our address in the proxy_pass line. While this would have worked, it doesn’t lend itself to a maintainable script, as addresses change or fallbacks are added. ↩
Three minutes is a bit long, right? Well, most of the time, yes. If you’re doing bulk operations on a large number of items in Jira, however, you’ll discover that everything is run in one go rather than in batches. Now, three minutes goes from being a long stretch of time to a gamble that it might not be long enough. ↩
An important detail here. We now have the capability to expose large numbers of internal servers to our public network. However, it seems a reminder might be necessary that could != should. ↩
It is important to note that this only works for HTTP and HTTPS traffic. ↩
Thank to: https://fortixpert.blogspot.com/ Este artículo describe cómo configurar FortiGate para Hairpin con el uso de set match-vip y match-vip-only. En este escenario, tanto el PC como el Servidor están detrás de FortiGate y el PC quiere conectarse al Servidor apuntando a su dirección externa (92.0.2.10) en lugar de la real (10.10.10.10). Esto se llama Hairpin NAT. Solución : La solución dependerá de cómo sea el objeto IP Virtual (VIP). Solución 1 : La interfaz externa en el VIP está configurada a una interfaz particular (en este caso a wan1) #config firewall vip edit "VIP" set extip 92.0.2.10 set extintf 'wan1' set mappedip 10.10.10.10 next end Nota: En este escenario, la IP externa VIP puede ser la misma que la IP de la interfaz (es decir, 92.0.2.2) Se necesitan dos políticas: 1) Una política de entrada con ...
🔧 Paso 1: Editar el archivo de configuración de Nginx Objetivo: Configurar el servidor Nginx para que rechace solicitudes HTTP que usen los métodos PUT, DELETE y TRACE, devolviendo un código de estado 405 (Method Not Allowed) . ¿Por qué hacerlo? Por razones de seguridad . Algunos métodos HTTP como PUT , DELETE y TRACE pueden representar riesgos si no son utilizados correctamente. Si tu aplicación no los necesita, es recomendable deshabilitarlos. Instrucciones: Abre el archivo de configuración de Nginx. Generalmente se encuentra en: /etc/nginx/nginx.conf O también puede estar dentro del directorio: /etc/nginx/sites-available/ dependiendo de cómo esté estructurada tu instalación. Busca la sección que tenga location / { ... } o agrégala dentro del bloque server { ... } . Dentro de ese bloque, agrega las siguientes condiciones: location / { if ($request_method = PUT) { return 405; } if ($request_method = DELETE) { return 405; } ...
Thanks to: http://www.cisco.com Introduction A problem with static routes is that no inherent mechanism exists to determine if the route is up or down. The route remains in the routing table even if the next hop gateway becomes unavailable. Static routes are removed from the routing table only if the associated interface on the security appliance goes down. In order to solve this problem, a static route tracking feature is used to track the availability of a static route and, if that route fails, remove it from the routing table and replace it with a backup route. This document provides an example of how to use the static route tracking feature on the PIX 500 Series Security Appliance or the ASA 5500 Series Adaptive Security Appliance in order to enable the device to use redundant or backup Internet connections. In this example, static route tracking allows the security appliance to use an inexpensive connection to a secondary Internet service provider (ISP) in the event th...
Comentarios
Publicar un comentario
Dime si la información de este blog te sirvio.