Esta guía lo guiará a través de la instalación y configuración de NGINX para permitir la ejecución de múltiples servidores físicos, máquinas virtuales o una combinación de ambos detrás de una sola dirección IP pública. Puede optar por ejecutar una serie de servidores web en máquinas virtuales y administrarlos localmente o es posible que deba utilizar herramientas de acceso remoto como SSH para cada uno de los hosts. Por ejemplo, si el acceso local no estará disponible fuera del horario comercial normal. Esta guía puede facilitar ambos escenarios.
Las configuraciones que se muestran aquí se adaptarían mejor a una red de laboratorio doméstico o pequeña empresa que tiene limitaciones en las direcciones IP públicas disponibles. Habría pocas razones, si las hubiera, para ejecutar una configuración como esta, cuando tiene varios servidores o máquinas virtuales alquiladas de un servicio de alojamiento, se le asignará una dirección IP pública para cada servidor o host de todos modos.
Le mostraré cómo instalar NGINX y realizar configuraciones que permitirán que el servidor actúe como un proxy inverso para HTTP(S), SSH, FTP y MySQL/MariaDB. Supongo que para el servidor host NGINX tiene:acceso local, una instalación nueva de Ubuntu 18.04 y que optó por instalar el servidor SSH durante los pasos de instalación del servidor Ubuntu.
Esta configuración funciona bien para mí, pero comprenda que no puedo garantizar que funcione para usted. Por supuesto, si encuentra algo mal, hágamelo saber para que pueda corregirse. Asegúrese de leer la guía completa antes de comenzar, hay una parte (transmisiones) donde muestro dos formas de administrarlo.
Cómo empezar
En esta guía, usaré los siguientes nombres de host y direcciones IP.
rproxy.example.com 192.168.1.1 web1.example.com 192.168.1.2 db1.exmple.com 192.168.1.3
Debe tener una cuenta de usuario no root en el servidor para una instalación de servidor Ubuntu 18.04 estándar que creó durante la instalación. Comience iniciando sesión en el servidor donde instalará NGINX con ese usuario. Como es muy probable que se trate de un servidor local, es posible que deba iniciar sesión en el servidor directamente la primera vez para configurar el servidor SSH. Por supuesto, necesitará un teclado y un monitor conectados al servidor para hacer esto.
Nota:si, como yo, usa software de virtualización como VMWare que incluye una interfaz de navegador, entonces debe tener una consola dentro de ese sistema y puede realizar este paso sin acceso "directo". Podría intentar realizar toda esta configuración dentro de esa consola, sin embargo, descubrí que algunas funciones, como copiar y pegar, no funcionaron en la consola basada en el navegador, aunque esto podría ser específico del navegador, por lo que puede valer la pena intentar ver si tú puedes.
Preparación del servidor host
En el shell de su consola (navegador o conectado directamente)
sudo nano /etc/ssh/sshd_config
Descomente las líneas:Port cambie el número de puerto a algo así como 23456, ListenAddress y cámbielo a 0.0.0.0. Para aquellos que no estén familiarizados con nano, presione CTRL + X, escriba y, y luego presione enter. Esto guardará y cerrará un archivo, si no se realizaron cambios en el archivo, CTRL + x cerrará el archivo sin solicitar que se guarde. Volverá a la línea de comandos.
No profundizaré en el resto de las configuraciones dentro de este archivo porque ya es una guía considerablemente larga y hay muchas guías que le mostrarán qué configuraciones debe cambiar para una serie de cosas, como usar claves SSH y permitir SSH raíz acceso. También puede encontrar esas guías aquí mismo en el sitio web de HowtoForge.
Con los cambios completos, deberá reiniciar el servidor ssh para que los cambios surtan efecto. Su inicio de sesión actual no se ve afectado por este reinicio.
systemctl restart ssh
Verifique que pueda iniciar sesión usando SSH desde una terminal en otra computadora dentro de su red local.
ssh [email protected] -p23456
Mantenga este terminal abierto después de iniciar sesión correctamente mediante SSH y cierre sesión en la consola/servidor. Ya no necesita usarlo para el resto de esta guía.
A partir de este momento, ejecutará comandos de nivel raíz desde su terminal. El siguiente comando eliminará la necesidad de anteponer sudo a los comandos subsiguientes.
sudo -s
Actualice la base de datos de paquetes de Apt y actualice Ubuntu para asegurarse de tener instalados los paquetes más recientes.
apt update && apt -y upgrade
Si ve algo durante la actualización que informa que se están instalando nuevos núcleos, debe reiniciar una vez que apt haya terminado de actualizarse para asegurarse de que está trabajando en un sistema completamente actualizado.
Configuración del nombre de host del servidor proxy inverso.
hostnamectl set-hostname rproxy.example.com
Si está ejecutando un servidor virtual, es posible que tenga un archivo llamado cloud.cfg que deba modificarse para conservar el nombre de host que se establece aquí. El siguiente comando mostrará un archivo con contenido o una página vacía. Si ve una página vacía, puede simplemente CTRL + x y omitir este paso ya que no hay nada que hacer.
nano /etc/cloud/cloud.cfg
Cambie la línea de preservar nombre de host a verdadero y cierre/guarde el archivo.
If your system is currently local only you will need to show this server where your other servers/virtual hosts are.
nano /etc/hosts
El archivo de hosts se verá así después de realizar los cambios, las direcciones IP y los hosts deben coincidir con su propia infraestructura.
127.0.0.1 localhost 127.0.1.1 rproxy.example.com 192.168.1.2 web1.example.com 192.168.1.3 db1.example.com # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Instalando NGINX
apt install -y nginx
Después de la instalación, debe verificar su versión de NGINX, es fundamental que tenga una versión 1.9 o superior para permitirle el proxy inverso para SSH y MySQL/MariaDB.
nginx -v
Como puede ver, tengo instalada la versión 1.14 de NGINX, que es la predeterminada en Ubuntu 18.04 (10 de octubre de 2019)
nginx version: nginx/1.14.0 (Ubuntu)
Preparación de NGINX para funcionar como proxy inverso
Con esta configuración, no atenderá ningún sitio web directamente desde el servidor host de proxy inverso. Creará una nueva estructura de directorios en /etc/nginx/. Esto preservará las configuraciones predeterminadas de NGINX en caso de que desee revertir estos cambios más tarde o decida que realmente también desea servir sitios web directamente desde este host. Es posible ejecutar la configuración predeterminada junto con estas configuraciones de proxy inverso; sin embargo, si Apache2 estará en el mismo servidor, necesitará puertos alternativos para escuchar y aún necesitará el proxy inverso de los sitios web a los que sirve esta instancia de Apache2.
Crear la estructura del directorio del proxy inverso
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled
Ahora que tiene la estructura en su lugar, puede continuar con la creación de los archivos de configuración. Yo uso nano, pero puedes usar el editor con el que te sientas cómodo. Nano creará/actualizará los archivos al guardarlos.
Before you proceed, open an empty document on your computer or get a pen and paper to note down the ports you configure.
Configuración de servidores web proxy inversos (http)
Cree los archivos de configuración http para los sitios web ajustándolos en consecuencia
nano http/available/example.com.conf
Copie el bloque del servidor en la página abierta en la terminal con nano ajuste en consecuencia.
# Note down ports 80 and 443
server {
server_name example.com www.example.com;
listen 80;
set $upstream 192.168.1.2;
location / {
proxy_pass_header Authorization;
proxy_pass http://$upstream;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
client_max_body_size 0;
proxy_read_timeout 10000s;
proxy_redirect off;
}
} Configuración de proxies inversos SSH, MySQL/MariaDB (stream)
Antes de continuar, decida cuál desea utilizar, por host o por servicio. Por host, creará una configuración para cada host que puede ser útil para cambiar rápidamente la configuración de un solo host. Por servicio, tendrá los puertos de servicio para todos los servidores en un archivo para cada uno, SSH, MySQL/MariaDB y FTP.
Uso de configuraciones por servicio
Agregue las configuraciones de SSH.
nano stream/available/ssh.conf
# Note down the listen ports
upstream web1-ssh {
server 192.168.1.2:22;
}
server {
listen 22002;
proxy_pass web1-ssh;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
# Add as many upstream and server block pairs as you will need for your remote accessed SSH servers.
Agregue las configuraciones de MySQL/MariaDB.
nano stream/available/db.conf
# Note down the listen ports
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
# Add as many upstream/server block pairs as you will need for your remote accessed MySQL/MariaDB servers to this file.
Ahora cree las configuraciones de proxy inverso de FTP.
nano stream/available/ftp.conf
upstream web1-ftp {
server 192.168.1.3:21
}
server {
listen 21002;
proxy_pass web1-ftp;
}
# Add as many upstream/server block pairs as you will need for your remote accessed FTP servers.
Uso de archivos de configuración por host
nano /etc/nginx/rproxy/stream/available/web1.example.com.conf
# Note down the listen ports
upstream web1-ssh {
server 192.168.1.3:22;
}
server {
listen 22002;
proxy_pass web-ssh;
}
Creando el archivo host para db1.example.com
nano /etc/nginx/rproxy/stream/available/db1.example.com.conf
# Note down the listen ports
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
Como puede ver, es un poco poco ortodoxo. Está utilizando puertos públicos de una manera no estándar, eligiendo los puertos que necesita y luego apuntándolos a NGINX. Esto sería normal excepto que ahora está utilizando un puerto diferente para cada servicio en cada servidor al que desea acceder de forma remota. Esto significa que, usando SSH como ejemplo, un número de puerto diferente para cada host habilitado para SSH 22 222 2222 22222, por ejemplo, apuntaría al puerto 22 en cuatro servidores o máquinas virtuales diferentes.
Este no es el caso de NGINX a proxy inverso para sitios web, siempre que NGINX tenga una configuración de servidor definida para un sitio web, funcionará correctamente con solo los puertos 80 y 443 reenviados a él.
En este punto, probablemente se haya dado cuenta de que podría simplemente usar los pasos de HTTP y omitir los pasos de transmisión y, en su lugar, reenviar múltiples puertos para los múltiples servicios al servidor/dirección IP apropiados. De hecho, esto se puede hacer. Sin embargo, agregaría otra capa de complejidad y se volvería difícil de mantener a medida que aumenta la cantidad de servidores porque es posible que deba cambiar los puertos predeterminados en cada servidor para ssh, mysql y ftp. Esta configuración ya es compleja, pero podría hacerse si quisieras.
El uso de un proxy inverso para estos servicios de la manera que le mostré reduce significativamente la complejidad al proporcionar un lugar único para realizar estos cambios de configuración y no necesitará realizar cambios en los puertos en toda su infraestructura.
Como una ventaja adicional de esta configuración, los otros servidores de su infraestructura solo necesitan escuchar en las interfaces locales y los puertos predeterminados, si eso es lo que prefiere. Si está administrando localmente, puede usar las direcciones IP locales y los puertos de servicio predeterminados para acceder a los servicios requeridos, por lo que no necesitará consultar sus notas para recordar los puertos correctos, solo necesita conocer la dirección IP y las credenciales de inicio de sesión.
Reunir todo
Para comenzar a usar las configuraciones de proxy inverso de NGINX, deberá realizar algunas modificaciones en el archivo de configuración principal. Comente la línea de inclusión actual en el bloque http (si no está sirviendo sitios web directamente desde NGINX también).
cd /etc/nginx && nano nginx.conf
Tenga en cuenta las partes resaltadas a continuación para determinar qué necesita cambiar.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascri$
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
# include /etc/nginx/sites-enabled/*;
# Reverse proxy http configuration files.
include /etc/nginx/rproxy/http/enabled/*.conf;
}
stream {
# Reverse proxy stream configuration files.
include /etc/nginx/rproxy/streams/enabled/*.conf;
}
#mail {
# # See sample authentication script at:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}
Activa las configuraciones de proxy inverso.
Primero, habilite todas las configuraciones http
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled
Habilite todas las configuraciones de transmisión
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabled
Realice una prueba para comprobar que la configuración de NGINX como proxy inverso es correcta.
nginx -T
En el resultado, debería ver un mensaje de éxito junto con todas las configuraciones personalizadas que haya realizado anteriormente.
Reinicie NGINX para poner en marcha las configuraciones del proxy inverso.
systemctl restart nginx
Verifique para asegurarse de que NGINX esté escuchando en todos los puertos configurados. verifique con sus notas que todos los puertos se muestran en los resultados.
netstat -tulpn | grep nginx
La salida debería verse así
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22002 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22003 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33062 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33063 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4964/nginx: master
Abrir el servidor para trafico
Ahora que NGINX está escuchando y listo para actuar como proxy inverso para todas las conexiones que queremos permitir el tráfico, deshabilite temporalmente UFW mientras realiza los siguientes pasos. Facilitará la resolución de problemas si las cosas no funcionan correctamente.
ufw disable
Puertos de reenvío
Desafortunadamente, no puedo darte una guía aquí. Deberá consultar el manual de su enrutador o buscar su enrutador en línea para aprender cómo hacerlo. Sin embargo, en resumen, desea reenviar cada uno de los puertos en los que NGINX está escuchando a la máquina host de NGINX. En mi enrutador específico, puedo configurar "aplicaciones" personalizadas.
Esto me permite asignar cualquier cantidad de puertos o rangos de puertos no asignados a la aplicación personalizada que luego se asignará a una dirección IP de LAN o a un dispositivo conectado específico identificado por su nombre de host. En cualquier caso, esto significa que puedo cambiar todos los puertos asignados a esa aplicación personalizada a cualquier host en mi red sin tener que eliminar todos los puertos y reasignarlos. Esta es una excelente opción y le recomiendo que elija un enrutador que lo admita.
Esta característica pequeña pero increíblemente útil en el firewall de mi enrutador me llevó a instalar un segundo proxy inverso que reflejaba las configuraciones de mi proxy inverso activo. Lo tengo apagado y puedo iniciar y cambiar los puertos en menos de 3 minutos desde el descubrimiento. Me imagino que hay empresas de alojamiento profesional que tendrían dificultades para cumplir con ese tiempo de respuesta para la recuperación ante desastres y todo esto se debió al deseo de ejecutar varios servidores en una red doméstica.
Letsencrypt SSL gratuito para el servidor proxy inverso
Instale el complemento Certbot y Certbot NGINX. Este paso se realiza aquí porque no puede crear un certificado hasta que tenga un DNS funcional para todos los (sub.) nombres de dominio enumerados en un certificado y pueda establecer una conexión con el dominio a través de HTTP. Al completar esto después de haber reenviado los puertos al proxy inverso, también actúa como una prueba adicional para sus configuraciones. Si el certificado falla porque no se puede acceder al dominio, verá un aviso de error significativo en el resultado.
Para asegurarse de obtener la última versión de certbot, agregue el repositorio de certbot antes de la instalación. Los repositorios de Ubuntu suelen estar una o más versiones por detrás de una versión de software y usted realmente quiere las últimas versiones estándar de todo su software si puede obtenerlas.
add-apt-repository ppa:certbot/certbot
apt install -y certbot python-certbot-plugin
Con certbot y el complemento certbot nginx instalados, ahora puede crear los certificados para NGINX.
Este comando debe repetirse para todos los dominios y subdominios para los que desea proporcionar SSL. Si es la primera vez que ejecuta certbot, deberá aceptar los términos y condiciones.
certbot --nginx -d example.com -d www.example.com
Tenga en cuenta que si tiene una configuración de servidor en funcionamiento con SSL en el host ascendente, deberá asegurarse de que las opciones seleccionadas aquí coincidan con las del servidor host, específicamente, si redirige a https en el servidor ascendente, debe hacerlo aquí también. .
Para mayor claridad, example.com existe en otro servidor, y seleccioné redirigir http a https dentro de ISPConfig, por esa razón, seleccioné hacerlo aquí. El archivo de configuración se actualizará y ahora veo que Certbot ha agregado algunas configuraciones propias.
Comprobando que las cosas funcionan.
Ahora que tiene tráfico capaz de fluir a su proxy inverso, debe verificar que todo funcione según lo previsto. Comprobar que los sitios web funcionan correctamente, realizar conexiones y tareas SSH, FTP y MySQL/MariaDB. Una vez que esté satisfecho de que todo funciona como debería, habilitará UFW y agregará reglas para permitir cada uno de los puertos.
Asegurar el servidor proxy inverso
ufw enable
Querrá permitir, 80 y 443 desde cualquier lugar. y probablemente restrinja SSH, FTP y MySQL/MariaDB a una dirección IP o nombre de host. Puede comentar las reglas para identificar rápidamente a qué servicio/servidor ha asignado el puerto.
ufw allow 80
ufw allow 443
ufw allow from 1.2.3.4 to any port 22002 comment 'web1 SSH'
ufw allow from somehost.domain.com to any port 33061 comment 'db1 MySQL/MariaDB'
ufw reload
ufw status numbered
Actualizando Apache2
Cuando se ejecuta detrás de un proxy inverso, los archivos de registro de Apache2 registrarán la dirección IP del servidor proxy inverso en lugar de la dirección IP del visitante del sitio web. Para restablecer el registro normal de direcciones IP en Apache2, hay un módulo disponible para corregir este comportamiento.
Complete los siguientes pasos en cada servidor web con una instancia de Apache2 instalada.
sudo apt install -y libapache2-mod-rpaf
Para asegurarse de que Apache2 registrará ahora las direcciones IP correctas, realice una pequeña modificación en el archivo rpaf.conf. Ubuntu 18.04 ya ha creado el archivo para nosotros, solo tenemos que editarlo cambiando la dirección IP resaltada a la del host del proxy inverso NGINX.
nano /etc/apache2/mods-available/rpaf.conf
<ifmodule rpaf_module="">
RPAFenable On
# When enabled, take the incoming X-Host header and
# update the virtualhost settings accordingly:
RPAFsethostname On
# Define which IP's are your frontend proxies that sends
# the correct X-Forwarded-For headers:
RPAFproxy_ips 127.0.0.1 ::1
# Change the header name to parse from the default
# X-Forwarded-For to something of your choice:
# RPAFheader X-Real-IP
</ifmodule> Notas Finales
NGINX y Apache2 en el mismo host
Dos servicios no pueden escuchar en el mismo puerto dentro de un servidor o máquina virtual. Si NGINX está instalado en el mismo servidor o máquina virtual que un servidor web Apache2, deberá cambiar el puerto en el que escucha Apache2. NGINX requiere los puertos 80 y 443 para realizar sus funciones HTTP(S), ya que son los puertos predeterminados para HTTP y HTTPS.
Vuelva a consultar la sección http de esta guía y agregue configuraciones de proxy inverso para los sitios web atendidos por esta instancia de Apache2 de la misma manera que los demás servidores de la red.
Cambiando el puerto de escucha de Apache2
Si tiene instalado un sistema de administración de servidores como ISPConfig, este sistema maneja los archivos vhost de Apache2, por lo que debe investigar cómo cambiar los puertos en los que escucha Apache2. Busque en los foros de ISPConfig y luego haga los ajustes necesarios. De lo contrario, debe consultar los foros de Ubuntu o el sitio web de Apache2 para saber cómo realizar estos cambios.
Note: Apache2 ports do not need to be altered when it is the only web server installed on server or virtual machine.