Questa guida ti guiderà attraverso l'installazione e la configurazione di NGINX per consentire l'esecuzione di più server fisici, macchine virtuali o una combinazione di entrambi dietro un unico indirizzo IP pubblico. È possibile scegliere di eseguire un certo numero di server Web su macchine virtuali e amministrarli localmente oppure potrebbe essere richiesto di utilizzare strumenti di accesso remoto come SSH per ciascuno degli host. Ad esempio, se l'accesso locale non sarà disponibile al di fuori del normale orario lavorativo. Questa guida può facilitare entrambi gli scenari.
Le configurazioni mostrate qui sarebbero più adatte a un laboratorio domestico oa una rete di piccole imprese che presenta limitazioni sugli indirizzi IP pubblici disponibili. Ci sarebbero poche ragioni per eseguire una configurazione come questa, quando hai più server o macchine virtuali noleggiati da un servizio di hosting, ti verrà comunque assegnato un indirizzo IP pubblico per ogni server o host.
Ti mostrerò come installare NGINX e fare configurazioni che consentiranno al server di agire come proxy inverso per HTTP(S), SSH, FTP e MySQL/MariaDB. Presumo che per il server host NGINX tu abbia:accesso locale, una nuova installazione di Ubuntu 18.04 e che tu abbia scelto di installare il server SSH durante le fasi di installazione del server Ubuntu.
Questa configurazione funziona bene per me, ma per favore capisci che non posso garantire che funzionerà per te. Naturalmente, se trovi qualcosa che non va, fammi sapere in modo che possa essere corretto. Assicurati di leggere l'intera guida prima di iniziare, c'è una parte (stream) in cui mostro due modi per gestirla.
Per iniziare
In questa guida utilizzerò i seguenti nomi host e indirizzi IP.
rproxy.example.com 192.168.1.1 web1.example.com 192.168.1.2 db1.exmple.com 192.168.1.3
Dovresti avere un account utente non root sul server per un'installazione del server Ubuntu 18.04 standard che hai creato durante l'installazione. Inizia accedendo al server in cui installerai NGINX con quell'utente. Poiché molto probabilmente si tratta di un server locale, potrebbe essere necessario accedere direttamente al server la prima volta per configurare il server SSH. Per farlo, ovviamente, avrai bisogno di una tastiera e di un monitor collegati al server.
Nota:se come me utilizzi un software di virtualizzazione come VMWare che include un'interfaccia browser, dovresti avere una console all'interno di quel sistema e puoi eseguire questo passaggio senza accesso "diretto". Potresti tentare di eseguire l'intera configurazione all'interno di quella console, tuttavia, ho scoperto che alcune funzionalità come copia e incolla non funzionavano nella console basata su browser sebbene questo potrebbe essere specifico del browser, quindi potrebbe valere la pena provare a vedere se puoi.
Preparazione del server host
Nella shell della tua console (browser o connesso direttamente)
sudo nano /etc/ssh/sshd_config
Decommenta le righe:Port cambia il numero della porta in qualcosa come 23456, ListenAddress e cambialo in 0.0.0.0. Per coloro che potrebbero non avere familiarità con nano, premere CTRL + X, digitare y, quindi premere Invio. Questo salverà e chiuderà un file, se non sono state apportate modifiche al file, CTRL + x chiuderà il file senza chiedere di salvare. Verrai riportato al prompt dei comandi.
Non approfondirò il resto delle impostazioni all'interno di questo file perché questa è già una guida considerevolmente lunga e ci sono molte guide che ti mostreranno quali impostazioni dovresti modificare per una serie di cose, come usare le chiavi SSH e consentire SSH di root Accedere. Puoi anche trovare queste guide proprio qui sul sito web di HowtoForge.
Una volta completate le modifiche, sarà necessario riavviare il server ssh in modo che le modifiche abbiano effetto. Il tuo attuale accesso non è influenzato da questo riavvio.
systemctl restart ssh
Verifica di essere in grado di accedere utilizzando SSH da un terminale su un altro computer all'interno della tua rete locale.
ssh [email protected] -p23456
Tieni aperto questo terminale dopo aver effettuato correttamente l'accesso utilizzando SSH e disconnettersi dalla console/server. Non è più necessario utilizzarlo per il resto di questa guida.
Da questo momento in poi eseguirai i comandi a livello di root dal tuo terminale. Il comando successivo eliminerà la necessità di anteporre i comandi successivi con sudo.
sudo -s
Aggiorna il database dei pacchetti Apt e aggiorna Ubuntu per assicurarti di avere installato i pacchetti più recenti.
apt update && apt -y upgrade
Se durante l'aggiornamento dovessi vedere qualcosa che segnala l'installazione di nuovi kernel, dovresti riavviare una volta che apt ha terminato l'aggiornamento per assicurarti di lavorare su un sistema completamente aggiornato.
Impostazione del nome host del server proxy inverso.
hostnamectl set-hostname rproxy.example.com
Se stai eseguendo un server virtuale, potresti avere un file denominato cloud.cfg che deve essere modificato per preservare il nome host impostato qui. Il comando seguente mostrerà un file con contenuto o una pagina vuota. Se vedi una pagina vuota, puoi semplicemente CTRL + x e saltare questo passaggio perché non c'è niente da fare per te.
nano /etc/cloud/cloud.cfg
Cambia la riga di conservazione del nome host in true e chiudi/salva il file.
If your system is currently local only you will need to show this server where your other servers/virtual hosts are.
nano /etc/hosts
Il file hosts avrà un aspetto simile dopo aver apportato le modifiche, gli indirizzi IP e gli host dovrebbero corrispondere alla tua infrastruttura.
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
Installazione di NGINX
apt install -y nginx
Dopo l'installazione dovresti controllare la tua versione di NGINX, è fondamentale che tu abbia una versione 1.9 o successiva per consentirti di Reverse proxy per SSH e MySQL/MariaDB.
nginx -v
Come puoi vedere, ho installato NGINX versione 1.14 che è l'impostazione predefinita in Ubuntu 18.04 (10 ottobre 2019)
nginx version: nginx/1.14.0 (Ubuntu)
Preparazione di NGINX per funzionare come proxy inverso
Con questa configurazione, non servirai alcun sito Web direttamente dal server host del proxy inverso. Creerai una nuova struttura di directory in /etc/nginx/. Ciò manterrà le configurazioni NGINX predefinite nel caso in cui desideri ripristinare queste modifiche in un secondo momento o decidere di voler effettivamente servire anche i siti Web direttamente da questo host. È possibile eseguire la configurazione predefinita insieme a queste configurazioni del proxy inverso, tuttavia se Apache2 sarà sullo stesso server, avrà bisogno di porte alternative su cui ascoltare e sarà comunque necessario eseguire il proxy inverso dei siti Web serviti da questa istanza di Apache2.
Costruisci la struttura della directory del proxy inverso
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled
Ora che hai la struttura a posto, puoi procedere con la creazione dei file di configurazione. Io uso nano ma puoi usare l'editor con cui ti senti a tuo agio. Nano creerà/aggiornerà i file durante il salvataggio.
Before you proceed, open an empty document on your computer or get a pen and paper to note down the ports you configure.
Configurazione dei proxy inversi del server Web (http)
Crea i file di configurazione http per i siti Web adattandoli di conseguenza
nano http/available/example.com.conf
Copia il blocco del server nella pagina aperta nel terminale con nano regolando di conseguenza.
# 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;
}
} Configurazione di proxy inversi SSH, MySQL/MariaDB (stream)
Prima di procedere, decidi quale desideri utilizzare, per host o per servizio. Per host, creerai una configurazione per ogni host che potrebbe essere utile per modificare rapidamente le impostazioni di un singolo host. Per servizio, avrai le porte di servizio per tutti i server in un file per ciascuno, SSH, MySQL/MariaDB e FTP.
Utilizzo di configurazioni per servizio
Aggiungi le configurazioni 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.
Aggiungi le configurazioni 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.
Ora crea le configurazioni del proxy inverso 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.
Utilizzo dei file di configurazione Per 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;
}
Creazione del file host per 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;
}
Come puoi vedere, è un po' poco ortodosso. Stai utilizzando le porte pubbliche in modo non standard, scegliendo le porte di cui hai bisogno e quindi indirizzandole a NGINX. Ciò sarebbe normale, tranne per il fatto che ora stai utilizzando una porta diversa per ciascun servizio su ciascun server a cui desideri accedere in remoto. Ciò significa che, utilizzando SSH come esempio, un numero di porta diverso per ogni host abilitato SSH 22 222 2222 22222, ad esempio, punterebbe alla porta 22 su quattro diversi server o macchine virtuali.
Questo non è il caso di NGINX per il proxy inverso per i siti Web, purché NGINX abbia una configurazione del server definita per un sito Web, funzionerà correttamente con solo le porte 80 e 443 inoltrate ad esso.
A questo punto probabilmente ti sei reso conto che potresti semplicemente utilizzare i passaggi HTTP e saltare i passaggi del flusso e invece inoltrare più porte per più servizi al server/Indirizzo IP appropriato. In effetti, questo può essere fatto. Tuttavia, aggiungerebbe un altro livello di complessità e diventerebbe difficile da mantenere con l'aumento del numero di server poiché potrebbe essere necessario modificare le porte predefinite su ciascun server per ssh, mysql e ftp. Questa configurazione è già complessa, tuttavia potrebbe essere eseguita se lo desideri.
L'utilizzo di un proxy inverso per questi servizi nel modo in cui ti ho mostrato riduce notevolmente la complessità fornendo un unico posto per apportare queste modifiche alla configurazione e non avresti bisogno di apportare modifiche alle porte nell'intera infrastruttura.
Come bonus aggiuntivo a questa configurazione, gli altri server nella tua infrastruttura devono solo ascoltare su interfacce locali e porte predefinite se è quello che preferisci. Se stai gestendo localmente, puoi utilizzare gli indirizzi IP locali e le porte di servizio predefinite per accedere ai servizi richiesti, quindi non dovrai fare riferimento alle tue note per ricordare le porte corrette, devi solo conoscere l'indirizzo IP e le credenziali di accesso.
Unendo tutto
Per iniziare a utilizzare le configurazioni del proxy inverso NGINX dovrai apportare alcune modifiche al file di configurazione principale. Commenta la riga di inclusione corrente nel blocco http (se non stai servendo anche i siti Web direttamente da NGINX).
cd /etc/nginx && nano nginx.conf
Nota le parti evidenziate di seguito per determinare cosa è necessario modificare.
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;
# }
#}
Attiva le configurazioni del proxy inverso.
Innanzitutto, abilita tutte le configurazioni http
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled
Abilita tutte le configurazioni di streaming
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabled
Eseguire un test per verificare che la configurazione di NGINX come proxy inverso sia corretta.
nginx -T
Nell'output, dovresti vedere un messaggio di successo insieme a tutte le configurazioni personalizzate che hai effettuato in precedenza.
Riavvia NGINX per mettere in azione le configurazioni del proxy inverso.
systemctl restart nginx
Verificare che NGINX sia in ascolto su tutte le porte configurate. verifica in base alle tue note che tutte le porte siano mostrate nei risultati.
netstat -tulpn | grep nginx
L'output dovrebbe essere simile a questo
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
Apertura del server per il traffico
Ora che NGINX è in ascolto ed è pronto a fungere da proxy inverso per tutte le connessioni in cui vogliamo consentire il traffico, disabilita temporaneamente UFW mentre esegui i passaggi successivi. Semplificherà la risoluzione dei problemi se le cose non funzionano correttamente.
ufw disable
Porte di inoltro
Sfortunatamente, non sono in grado di darti indicazioni qui. Dovrai consultare il manuale del tuo router o cercare il tuo router online per imparare come farlo. In sintesi, tuttavia, si desidera inoltrare ciascuna delle porte su cui NGINX è in ascolto alla macchina host NGINX. Nel mio router specifico, sono in grado di configurare "applicazioni" personalizzate.
Ciò mi consente di assegnare un numero qualsiasi di porte o intervalli di porte non assegnati all'applicazione personalizzata che verrà quindi assegnata a un indirizzo IP LAN o a un dispositivo connesso specifico identificato dal suo nome host. In ogni caso, ciò significa che sono in grado di cambiare tutte le porte assegnate a quell'applicazione personalizzata su qualsiasi host sulla mia rete senza dover eliminare tutte le porte e riassegnarle. Questa è un'opzione eccellente da avere e ti consiglio vivamente di scegliere un router che lo supporti.
Questa piccola ma incredibilmente utile funzionalità nel firewall del mio router mi ha spinto a installare un secondo proxy inverso che rispecchia le configurazioni del mio proxy inverso attivo. L'ho spento e sono in grado di avviarlo e di passare alle porte in meno di 3 minuti dalla scoperta. Immagino che ci siano società di hosting professionali che farebbero fatica a rispettare i tempi di risposta per il ripristino di emergenza e tutto ciò è nato dal desiderio di eseguire più server su una rete domestica.
Letsencrypt SSL gratuito per il server proxy inverso
Installa il plug-in Certbot e Certbot NGINX. Questo passaggio viene eseguito qui perché non è possibile creare un certificato finché non si dispone di DNS funzionale per tutti i (sotto)nomi di dominio elencati in un certificato e si è in grado di stabilire una connessione al dominio tramite HTTP. Completando questo dopo aver inoltrato le porte al proxy inverso, funge anche da test aggiuntivo per le tue configurazioni. Se il certificato fallisce perché non è possibile raggiungere il dominio, vedrai un avviso di errore significativo nell'output.
Per assicurarti di ottenere l'ultima versione di certbot, aggiungi il repository di certbot prima dell'installazione. I repository di Ubuntu sono spesso una versione o più dietro una versione del software e se riesci a ottenerle, vuoi davvero le ultime versioni stavle di tutto il tuo software.
add-apt-repository ppa:certbot/certbot
apt install -y certbot python-certbot-plugin
Con certbot e il plugin nginx di certbot installati, ora puoi creare i certificati per NGINX.
Questo comando deve essere ripetuto per tutti i domini e sottodomini per i quali desideri fornire SSL. Se è la prima volta che esegui certbot, dovrai accettare i termini e le condizioni.
certbot --nginx -d example.com -d www.example.com
Nota che se hai una configurazione del server funzionante con SSL sull'host upstream, dovrai assicurarti che le opzioni selezionate qui corrispondano a quelle sul server host, in particolare, se reindirizzi a https sul server upstream, dovresti farlo anche qui .
Per chiarezza, example.com esiste su un altro server e ho scelto di reindirizzare da http a https all'interno di ISPConfig, quindi per questo motivo scelgo di farlo qui. Il file di configurazione verrà aggiornato e ora vedo che Certbot ha aggiunto alcune sue configurazioni.
Controllo che le cose funzionino.
Ora che hai traffico in grado di fluire verso il tuo proxy inverso, dovresti verificare che tutto funzioni come previsto. Verifica che i siti Web funzionino correttamente, esegui connessioni e attività SSH, FTP e MySQL/MariaDB. Una volta che sei soddisfatto che tutto funzioni come dovrebbe, abiliterai UFW e aggiungerai regole per consentire ciascuna delle porte.
Protezione del server proxy inverso
ufw enable
Ti consigliamo di consentire, 80 e 443 da qualsiasi luogo. e probabilmente limitare SSH, FTP e MySQL/MariaDB a un indirizzo IP o un nome host. Puoi commentare le regole per identificare rapidamente a quale servizio/server hai assegnato la porta.
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
Aggiornamento di Apache2
Quando vengono eseguiti dietro un proxy inverso, i file di registro Apache2 registreranno l'indirizzo IP del server proxy inverso anziché l'indirizzo IP del visitatore del sito web. Per ripristinare la normale registrazione dell'indirizzo IP su Apache2 è disponibile un modulo per correggere questo comportamento.
Completa i seguenti passaggi su ciascun server Web con un'istanza Apache2 installata.
sudo apt install -y libapache2-mod-rpaf
Per assicurarsi che Apache2 ora registrerà gli indirizzi IP corretti, apportare una piccola modifica al file rpaf.conf. Ubuntu 18.04 ha già creato il file per noi, dobbiamo solo modificarlo cambiando l'indirizzo IP evidenziato in quello dell'host 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> Note finali
NGINX e Apache2 nello stesso host
Non ci sono due servizi in grado di ascoltare sulla stessa porta all'interno di un server o di una macchina virtuale. Se NGINX è installato sullo stesso server o macchina virtuale di un server Web Apache2, sarà necessario modificare la porta su cui Apache2 è in ascolto. NGINX richiede le porte 80 e 443 per eseguire le sue funzioni HTTP(S) poiché sono le porte predefinite per HTTP e HTTPS.
Fare riferimento alla sezione http di questa guida e aggiungere le configurazioni del proxy inverso per i siti Web serviti da questa istanza di Apache2 allo stesso modo di quelli degli altri server nella rete.
Cambiare la porta di ascolto di Apache2
Se hai installato un sistema di gestione del server come ISPConfig, questo sistema gestisce i file vhost di Apache2, quindi dovresti cercare come modificare le porte su cui Apache2 è in ascolto. Cerca nei forum ISPConfig e quindi apporta le modifiche necessarie. Altrimenti, dovresti consultare i forum di Ubuntu o il sito Web di Apache2 per come eseguire queste modifiche.
Note: Apache2 ports do not need to be altered when it is the only web server installed on server or virtual machine.