NGINX - Historial de revisiones

Admin: /* Proxy inverso */

2024-09-02T12:00:10Z

Proxy inverso

← Revisión anterior		Revisión del 12:00 2 sep 2024
Línea 140:		Línea 140:
	Un punto a favor, si tenemos contratado un certificado SSL para hacer peticiones seguras, este certificado basta conque esté en el servidor proxy inverso y no hace falta que lo tengan los demás equipos. Tampoco es obligatorio que el resto de equipos se administren con NGINX, pueden ser [[Apache]] u otro servicio.		Un punto a favor, si tenemos contratado un certificado SSL para hacer peticiones seguras, este certificado basta conque esté en el servidor proxy inverso y no hace falta que lo tengan los demás equipos. Tampoco es obligatorio que el resto de equipos se administren con NGINX, pueden ser [[Apache]] u otro servicio.
	[[Archivo:ExProxyInverso.png\|centro\|miniaturadeimagen]]		[[Archivo:ExProxyInverso.png\|centro\|miniaturadeimagen]]

			=== NGINX y HTTPS ===
			Para hacer que nuestro web sea considerado seguro, éste debe tener un certificado SSL.


			Una vez creado, alquilado o auto-generado, deberemos especificarlo en nuestro fichero de configración añadiendo
			<code>listen 443 ssl; # managed by Certbot

			# RSA certificate
			ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
			ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot

			include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

			# Redirect non-https traffic to https
			if ($scheme != "https") {
			return 301 <nowiki>https://$host$request_uri</nowiki>;
			} # managed by Certbot</code>
			NOTA - en este ejemplo hemos generado un certificado con [[letsencrypt]] .

Admin en 10:37 19 jul 2024

2024-07-19T10:37:03Z

← Revisión anterior		Revisión del 10:37 19 jul 2024
Línea 139:		Línea 139:

	Un punto a favor, si tenemos contratado un certificado SSL para hacer peticiones seguras, este certificado basta conque esté en el servidor proxy inverso y no hace falta que lo tengan los demás equipos. Tampoco es obligatorio que el resto de equipos se administren con NGINX, pueden ser [[Apache]] u otro servicio.		Un punto a favor, si tenemos contratado un certificado SSL para hacer peticiones seguras, este certificado basta conque esté en el servidor proxy inverso y no hace falta que lo tengan los demás equipos. Tampoco es obligatorio que el resto de equipos se administren con NGINX, pueden ser [[Apache]] u otro servicio.
			[[Archivo:ExProxyInverso.png\|centro\|miniaturadeimagen]]

Admin: /* Proxy inverso */

2024-07-08T12:59:47Z

Proxy inverso

← Revisión anterior		Revisión del 12:59 8 jul 2024
Línea 134:		Línea 134:
	* '''Escalabilidad:''' El proxy inverso puede facilitar la adición de nuevos servidores de origen a medida que crece la demanda.		* '''Escalabilidad:''' El proxy inverso puede facilitar la adición de nuevos servidores de origen a medida que crece la demanda.
	* '''Alta disponibilidad:''' El proxy inverso puede enrutar el tráfico alrededor de los servidores de origen que no están disponibles.		* '''Alta disponibilidad:''' El proxy inverso puede enrutar el tráfico alrededor de los servidores de origen que no están disponibles.
			Dado que todo el tráfico y peticiones web pasarán por el equipo, hace falta configurar [[SELinux]] para permitir el tráfico con:<blockquote>sudo setsebool –P httpd_can_network_connect on</blockquote>Resumiendo, el cliente pedirá acceder a diferentes lugares de la web de la empresa, y estos lugares son gestionados por diferentes servidores, por ejemplo:

			Accederá a empresa.com y de aquí a www.empresa.com ( que está en un servidor en la red interna), a ventas.empresa.com ( que está en otro servidor) o a nextcloud.empresa.com ( ubicado en un tercer equipo interno), haciendo un total de 4 equipos: el proxy y tres equipos destino con sus correspondientes configuraciones.

			Un punto a favor, si tenemos contratado un certificado SSL para hacer peticiones seguras, este certificado basta conque esté en el servidor proxy inverso y no hace falta que lo tengan los demás equipos. Tampoco es obligatorio que el resto de equipos se administren con NGINX, pueden ser [[Apache]] u otro servicio.

Admin: /* Proxy inverso */

2024-07-08T12:26:06Z

Proxy inverso

← Revisión anterior		Revisión del 12:26 8 jul 2024
Línea 127:		Línea 127:
	# '''El servidor de origen envía el recurso al proxy inverso.'''		# '''El servidor de origen envía el recurso al proxy inverso.'''
	# '''El proxy inverso recibe el recurso del servidor de origen y lo envía al cliente.'''		# '''El proxy inverso recibe el recurso del servidor de origen y lo envía al cliente.'''

			Los proxies inversos ofrecen varias ventajas, entre ellas:

			* '''Seguridad:''' El proxy inverso puede ocultar los servidores de origen a Internet, lo que dificulta su ataque. También puede agregar funciones de seguridad adicionales, como autenticación y autorización.
			* '''Rendimiento:''' El proxy inverso puede mejorar el rendimiento al almacenar en caché contenido estático, como imágenes y CSS. También puede distribuir la carga entre varios servidores de origen.
			* '''Escalabilidad:''' El proxy inverso puede facilitar la adición de nuevos servidores de origen a medida que crece la demanda.
			* '''Alta disponibilidad:''' El proxy inverso puede enrutar el tráfico alrededor de los servidores de origen que no están disponibles.

Admin: /* Proxy inverso */

2024-07-08T12:25:25Z

Proxy inverso

← Revisión anterior		Revisión del 12:25 8 jul 2024
Línea 120:		Línea 120:

	=== Proxy inverso ===		=== Proxy inverso ===
			En Nginx, un '''proxy inverso''' es un servidor que actúa como intermediario entre los clientes y los servidores de origen. Funciona de la siguiente manera:

			# '''Los clientes solicitan recursos a un nombre de dominio o dirección IP virtual.''' Esta dirección está configurada para apuntar al proxy inverso.
			# '''El proxy inverso recibe la solicitud del cliente y la analiza.''' Determina qué servidor de origen es responsable de atender la solicitud.
			# '''El proxy inverso se comunica con el servidor de origen correspondiente y solicita el recurso.'''
			# '''El servidor de origen envía el recurso al proxy inverso.'''
			# '''El proxy inverso recibe el recurso del servidor de origen y lo envía al cliente.'''

Admin en 12:24 8 jul 2024

2024-07-08T12:24:14Z

← Revisión anterior		Revisión del 12:24 8 jul 2024
Línea 118:		Línea 118:

	return 301 $scheme://www.empresa.com$request_uri; #scheme sirve para aplicar tanto en http como https y request_uri sirve para asociar la página solicitada por el cliente</blockquote>NOTA - recordemos reiniciar el servidor en cada cambio.		return 301 $scheme://www.empresa.com$request_uri; #scheme sirve para aplicar tanto en http como https y request_uri sirve para asociar la página solicitada por el cliente</blockquote>NOTA - recordemos reiniciar el servidor en cada cambio.

			=== Proxy inverso ===

Admin: /* Bloques de servidor */

2024-07-08T12:22:28Z

Bloques de servidor

@@ Línea 91: / Línea 91: @@
 Un ejemplo de bloque nos lo encontramos en la directiva por defecto "server" en la que se especifican los valores por defecto como la ruta del directorio, los ficheros de log de acceso o error o el puerto de escucha ( 80).
   NOTA  - por una cuestión de organización, los ficheros de cada bloque, igual que cualquier añadido, serán individuales en el directorio "/etc/nginx/conf.d/".
+Un ejemplo, tengamos presente que queremos que "www.empresa.com" tenga otro directorio de alojamiento, para ello creamos el fichero:<blockquote>/etc/nginx/conf.d/www.com</blockquote>Con este contenido:<blockquote>server {

Admin: /* Bloques de servidor */

2024-07-08T09:25:53Z

Bloques de servidor

← Revisión anterior		Revisión del 09:25 8 jul 2024
Línea 88:		Línea 88:

	En [[Apache]] sería comparable a los '''VirtualHost''' pero más avanzado.		En [[Apache]] sería comparable a los '''VirtualHost''' pero más avanzado.

			Un ejemplo de bloque nos lo encontramos en la directiva por defecto "server" en la que se especifican los valores por defecto como la ruta del directorio, los ficheros de log de acceso o error o el puerto de escucha ( 80).
			NOTA - por una cuestión de organización, los ficheros de cada bloque, igual que cualquier añadido, serán individuales en el directorio "/etc/nginx/conf.d/".
			A

Admin en 12:38 4 jul 2024

2024-07-04T12:38:51Z

← Revisión anterior		Revisión del 12:38 4 jul 2024
Línea 86:		Línea 86:
	=== Bloques de servidor ===		=== Bloques de servidor ===
	Un caso práctico sería, tener un servidor que publica la web '''www.empresa.com''', pero ha crecido y quiere otro servidor exclusivo para las ventas, bajo el dominio '''ventas.empresa.com'''. Esto implicaría la compra de dos equipos, pero eso se puede realizar desde el mismo equipo servidor NGINX.		Un caso práctico sería, tener un servidor que publica la web '''www.empresa.com''', pero ha crecido y quiere otro servidor exclusivo para las ventas, bajo el dominio '''ventas.empresa.com'''. Esto implicaría la compra de dos equipos, pero eso se puede realizar desde el mismo equipo servidor NGINX.

			En [[Apache]] sería comparable a los '''VirtualHost''' pero más avanzado.

Admin en 12:23 4 jul 2024

2024-07-04T12:23:21Z

← Revisión anterior		Revisión del 12:23 4 jul 2024
Línea 82:		Línea 82:

	'''NOTA''' - seguramente [[SELinux]] bloquee la navegación de proxy y se soluciona aplicando:<blockquote>sudo setsebool httpd_can_network_connect 1</blockquote>Con lo que se permite el tráfico en la red por el protocolo http.		'''NOTA''' - seguramente [[SELinux]] bloquee la navegación de proxy y se soluciona aplicando:<blockquote>sudo setsebool httpd_can_network_connect 1</blockquote>Con lo que se permite el tráfico en la red por el protocolo http.
	~~IMPORTANTE~~! ~~hay~~ que tener en cuenta las páginas ~~dinàmicas~~, es decir, cuando se precisa un usuario y contraseña para acceder a una web, obviamente, no va a replicar una validación por lo que eso ya se ~~veria~~ reflejado en la configuración de la base de datos.		¡IMPORTANTE! Hay que tener en cuenta las páginas dinámicas, es decir, cuando se precisa un usuario y contraseña para acceder a una web, obviamente, no va a replicar una validación, por lo que eso ya se vería reflejado en la configuración de la base de datos.

			=== Bloques de servidor ===
			Un caso práctico sería, tener un servidor que publica la web '''www.empresa.com''', pero ha crecido y quiere otro servidor exclusivo para las ventas, bajo el dominio '''ventas.empresa.com'''. Esto implicaría la compra de dos equipos, pero eso se puede realizar desde el mismo equipo servidor NGINX.