GNU/Linux >> Linux Esercitazione >  >> Panels >> Docker

Una guida per principianti a LXD:configurazione di un proxy inverso per ospitare più siti web

Introduzione

LXD (pronunciato "Lex-Dee") è un gestore di container di sistema basato su Linux Containers (LXC) supportato da Canonical. L'obiettivo di LXD è fornire un'esperienza simile a una macchina virtuale ma attraverso la containerizzazione anziché la virtualizzazione hardware. Rispetto a Docker per la distribuzione di applicazioni, LXD offre funzionalità del sistema operativo quasi complete con funzionalità aggiuntive come snapshot, migrazioni live e gestione dello storage.

Un proxy inverso è un server che si trova tra le applicazioni interne e i client esterni, inoltrando le richieste dei client al server appropriato. Sebbene molte applicazioni comuni, come Node.js, siano in grado di funzionare come server da sole, potrebbero non avere una serie di funzionalità avanzate di bilanciamento del carico, sicurezza e accelerazione.

Questa guida spiega la creazione di un proxy inverso in un container LXD per ospitare più siti Web, ciascuno nei propri container aggiuntivi. Utilizzerai i server web NGINX e Apache, facendo affidamento anche su NGINX come proxy inverso.

Fare riferimento al diagramma seguente per comprendere il proxy inverso creato in questa guida.

In questa guida potrai:

  • Installa e configura i container per i server Web NGINX e Apache.

  • Scopri come installare e configurare un proxy inverso in un container.

  • Ottieni il supporto SSL/TLS tramite i certificati Let's Encrypt con rinnovo automatico del certificato.

  • Risoluzione dei problemi di errori comuni.

Nota Per semplicità, il termine contenitore viene utilizzato in questa guida per descrivere i container del sistema LXD.

Prima di iniziare

  1. CompleteA Beginner's Guide to LXD:Configurazione di un server Web Apache in un container. La guida ti indica di creare un contenitore chiamato web con il server Web Apache a scopo di test. Rimuovi questo contenitore eseguendo i seguenti comandi.

    lxc stop web
lxc delete web
    Nota

    Per questa guida è necessaria la versione 3.3 o successiva di LXD. Verifica la versione con il seguente comando:

    lxd --version

    Se la versione non è 3.3 o successiva, aggiorna all'ultima versione installando il pacchetto snap come indicato in Guida per principianti a LXD:configurazione di un server Web Apache in un container e utilizza il comando seguente:

    sudo lxd.migrate

  2. Questa guida utilizza i nomi host apache1.example.com e nginx1.example.com per i due siti Web di esempio. Sostituisci questi nomi con i nomi host che possiedi e imposta le loro voci DNS in modo che puntino all'indirizzo IP del server che hai creato. Per assistenza con il DNS, consulta la nostra Guida al gestore DNS.

Creazione dei container

  1. Crea due contenitori chiamati apache1 e nginx1 , rispettivamente uno con il server web Apache e un altro con il server web NGINX. Per eventuali siti Web aggiuntivi, puoi creare nuovi contenitori con il software del server Web scelto.

    lxc launch ubuntu:18.04 apache1
lxc launch ubuntu:18.04 nginx1

  2. Crea il proxy contenitore per il proxy inverso.

    lxc launch ubuntu:18.04 proxy

  3. Elenca i contenitori con il comando list.

    lxc list

  4. L'output è simile al seguente.

    +---------+---------+---------------------+-----------------------------------------------+------------+-----------+
|  NAME   |  STATE  |        IPV4         |                     IPV6                      |    TYPE    | SNAPSHOTS |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
| apache1 | RUNNING | 10.10.10.204 (eth0) | fd42:67a4:b462:6ae2:216:3eff:fe01:1a4e (eth0) | PERSISTENT |           |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
| nginx1  | RUNNING | 10.10.10.251 (eth0) | fd42:67a4:b462:6ae2:216:3eff:febd:67e3 (eth0) | PERSISTENT |           |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
| proxy   | RUNNING | 10.10.10.28 (eth0)  | fd42:67a4:b462:6ae2:216:3eff:fe00:252e (eth0) | PERSISTENT |           |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+

    Ci sono tre container, tutti in RUNNING stato – ognuno con il proprio indirizzo IP privato. Prendi nota degli indirizzi IP (sia IPv4 che IPv6) per il contenitore proxy . Ti serviranno per configurare il proxy contenitore in una sezione successiva.

    Ora che i contenitori sono stati creati, i seguenti passaggi descrivono in dettaglio come configurare il software del server Web in apache1 e nginx1 contenitori e il proxy contenitore in modo che i server Web siano accessibili da Internet.

Configurazione del contenitore del server Web Apache

Quando si utilizza un proxy inverso davanti a un server Web, il server Web non conosce gli indirizzi IP dei visitatori. Il server Web vede solo l'indirizzo IP del proxy inverso. Tuttavia, ogni server web ha un modo per identificare il vero indirizzo IP remoto di un visitatore. Per Apache, questo viene eseguito con il modulo Apache IP remoto. Affinché il modulo funzioni, il proxy inverso deve essere configurato per trasmettere le informazioni sull'indirizzo IP remoto.

  1. Avvia una shell in apache1 contenitore.

    lxc exec apache1 -- sudo --user ubuntu --login

  2. Aggiorna l'elenco dei pacchetti in apache1 contenitore.

    sudo apt update

  3. Installa il pacchetto apache2 nel contenitore.

    sudo apt install -y apache2

  4. Crea il file /etc/apache2/conf-available/remoteip.conf .

    File:remoteip .conf
    1
2

    RemoteIPHeader X-Real-IP
RemoteIPTrustedProxy 10.10.10.28 fd42:67a4:b462:6ae2:216:3eff:fe00:252e

    Puoi usare il nano editor di testo eseguendo il comando sudo nano /etc/apache2/conf-available/remoteip.conf . Nota, questi sono gli indirizzi IP del proxy container mostrato in precedenza, sia per IPv4 che per IPv6. Sostituisci questi con gli IP dal tuo lxc list uscita.

    Nota Invece di specificare gli indirizzi IP, puoi anche utilizzare il nome host proxy.lxd . Tuttavia, il modulo RemoteIP Apache è peculiare quando si utilizza il nome host e utilizza solo uno dei due indirizzi IP (IPv4 o IPv6), il che significa che il server Web Apache non conosce il vero indirizzo IP di origine per alcune connessioni. Elencando esplicitamente sia gli indirizzi IPv4 che IPv6, puoi essere certo che RemoteIP accetti correttamente le informazioni IP di origine da tutte le connessioni del proxy inverso.

  5. Abilita il nuovo remoteip.conf configurazione.

     sudo a2enconf remoteip

    Enabling conf remoteip.
To activate the new configuration, you need to run:
systemctl reload apache2

  6. Abilita il remoteip Modulo Apache.

     sudo a2enmod remoteip

    Enabling module remoteip.
To activate the new configuration, you need to run:
systemctl restart apache2

  7. Modifica la pagina Web predefinita per Apache per fare un riferimento che viene eseguito all'interno di un contenitore LXD.

     sudo nano /var/www/html/index.html

    Cambia la riga "Funziona!" (riga numero 224) a "Funziona all'interno di un container LXD!" Salva ed esci.

  8. Riavvia il server web Apache.

     sudo systemctl reload apache2

  9. Torna all'host.

     exit

Hai creato e configurato il server web Apache, ma il server non è ancora accessibile da Internet. Diventa accessibile dopo aver configurato il proxy contenitore in una sezione successiva.

Creazione del contenitore del server Web NGINX

Come Apache, NGINX non conosce gli indirizzi IP dei visitatori quando utilizza un proxy inverso davanti a un server web. Vede invece solo l'indirizzo IP del proxy inverso. Ogni software del server web NGINX può identificare il vero indirizzo IP remoto di un visitatore con il modulo Real IP. Affinché il modulo funzioni, il proxy inverso deve essere configurato di conseguenza per trasmettere le informazioni relative agli indirizzi IP remoti.

  1. Avvia una shell in nginx1 contenitore.

    lxc exec nginx1 -- sudo --user ubuntu --login

  2. Aggiorna l'elenco dei pacchetti in nginx1 contenitore.

    sudo apt update

  3. Installa NGINX nel contenitore.

    sudo apt install -y nginx

  4. Crea il file /etc/nginx/conf.d/real-ip.conf .

    File:real -ip.conf
    1
2

    real_ip_header    X-Real-IP;
set_real_ip_from  proxy.lxd;

    Puoi usare il nano editor di testo eseguendo il comando sudo nano /etc/nginx/conf.d/real-ip.conf .

    Nota Hai specificato il nome host del proxy inverso, proxy.lxd . Ogni contenitore LXD ottiene automaticamente un nome host, che è il nome del contenitore più il suffisso .lxd . Specificando il set_real_ip_from campo con proxy.lxd , stai indicando al server web NGINX di accettare le informazioni sull'indirizzo IP reale per ciascuna connessione, a condizione che la connessione provenga da proxy.lxd . Le informazioni sull'indirizzo IP reale si trovano nell'intestazione HTTP X-Real-IP in ogni connessione.

  5. Modifica la pagina Web predefinita per NGINX per fare un riferimento che viene eseguito all'interno di un contenitore LXD.

     sudo nano /var/www/html/index.nginx-debian.html

    Cambia la riga "Benvenuto in nginx!" (riga numero 14) a "Benvenuto in nginx in esecuzione in un contenitore di sistema LXD!". Salva ed esci.

  6. Riavvia il server web NGINX.

     sudo systemctl reload nginx

  7. Torna all'host.

     exit

Hai creato e configurato il server web NGINX, ma il server non è ancora accessibile da Internet. Diventa accessibile dopo aver configurato il proxy contenitore nella sezione successiva.

Configurazione del proxy inverso

In questa sezione configurerai il contenitore proxy . Installerai NGINX e lo configurerai come proxy inverso, quindi aggiungi il dispositivo proxy LXD appropriato per esporre entrambe le porte 80 e 443 a Internet.

  1. Aggiungi LXD dispositivi proxy per reindirizzare le connessioni da Internet alle porte 80 (HTTP) e 443 (HTTPS) sul server alle rispettive porte al proxy contenitore.

     lxc config device add proxy myport80 proxy listen=tcp:0.0.0.0:80 connect=tcp:127.0.0.1:80 proxy_protocol=true
 lxc config device add proxy myport443 proxy listen=tcp:0.0.0.0:443 connect=tcp:127.0.0.1:443 proxy_protocol=true

    Device myport80 added to proxy
Device myport443 added to proxy

    Il lxc config device add il comando prende come argomenti:

    Argomento Spiegazione
    proxy Il nome del contenitore.
    myport80 Un nome per questo dispositivo proxy.
    proxy Il tipo di dispositivo LXD (LXD proxy dispositivo).
    listen=tcp:0.0.0.0:80 Il dispositivo proxy è in ascolto sull'host (predefinito) sulla porta 80, protocollo TCP, su tutte le interfacce.
    connect=tcp:127.0.0.1:80 Il dispositivo proxy si connette al container sulla porta 80, protocollo TCP, sull'interfaccia di loopback. Nelle versioni precedenti di LXD avresti potuto specificare localhost qui. Tuttavia, in LXD 3.13 o versioni successive, puoi specificare solo indirizzi IP.
    proxy_protocol=true Richiesta di abilitare il protocollo PROXY in modo che il proxy inverso ottenga l'indirizzo IP di origine dal dispositivo proxy.
    Nota

    Se vuoi rimuovere un dispositivo proxy, usa lxc config device remove . Se desideri rimuovere il dispositivo sopra myport80 , esegui il comando seguente:

    lxc config device remove proxy myport80

    Dove proxy è il nome del container e myport80 è il nome del dispositivo.

  2. Avvia una shell nel proxy contenitore.

    lxc exec proxy -- sudo --user ubuntu --login

  3. Aggiorna l'elenco dei pacchetti.

    sudo apt update

  4. Installa NGINX nel contenitore.

    sudo apt install -y nginx

  5. Esci dal contenitore.

    logout

Traffico diretto al server Web Apache dal proxy inverso

Il contenitore del proxy inverso è in esecuzione ed è stato installato il pacchetto NGINX. Per funzionare come proxy inverso, aggiungi la configurazione del sito Web appropriata in modo che NGINX possa identificare (con server_name sotto) il nome host appropriato, quindi passare (con proxy_pass di seguito) il collegamento all'apposito contenitore LXD.

  1. Avvia una shell nel proxy contenitore.

    lxc exec proxy -- sudo --user ubuntu --login

  2. Crea il file apache1.example.com in /etc/nginx/sites-available/ per la configurazione del tuo primo sito web.

    File:apache1 .esempio.com
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

    server {
        listen 80 proxy_protocol;
        listen [::]:80 proxy_protocol;

        server_name apache1.example.com;

        location / {
                include /etc/nginx/proxy_params;

                proxy_pass http://apache1.lxd;
        }

        real_ip_header proxy_protocol;
        set_real_ip_from 127.0.0.1;
}

    Puoi eseguire sudo nano /etc/nginx/sites-available/apache1.example.com per aprire un editor di testo e aggiungere la configurazione. Nota, in questo caso devi solo modificare il server_name essere il nome host del sito web.

  3. Abilita il sito web.

    sudo ln -s /etc/nginx/sites-available/apache1.example.com /etc/nginx/sites-enabled/

  4. Riavvia il proxy inverso NGINX. Riavviando il servizio, NGINX legge e applica le nuove istruzioni del sito appena aggiunte a /etc/nginx/sites-enabled .

    sudo systemctl reload nginx

  5. Esci dal container proxy e torna all'host.

    logout

  6. Dal tuo computer locale, visita l'URL del tuo sito web con il tuo browser web. Dovresti vedere la pagina predefinita di Apache:

    Nota Se guardi il file Apache access.log (file predefinito /var/log/apache2/access.log ), mostra ancora l'indirizzo IP privato del proxy contenitore invece del vero indirizzo IP. Questo problema è specifico del server Web Apache e ha a che fare con il modo in cui il server stampa i log. Altri software sul server web sono in grado di utilizzare l'IP reale. Per risolvere questo problema tramite i log di Apache, consulta la sezione Risoluzione dei problemi.

Traffico diretto al server Web NGINX dal proxy inverso

Il contenitore del proxy inverso è in esecuzione e il NGINX il pacchetto è stato installato. Per funzionare come proxy inverso, devi aggiungere la configurazione del sito Web appropriata, quindi NGINX può identificare (con server_name sotto) il nome host appropriato, quindi passare (con proxy_pass di seguito) la connessione al container LXD appropriato con il software del server web vero e proprio.

  1. Avvia una shell nel proxy contenitore.

    lxc exec proxy -- sudo --user ubuntu --login

  2. Crea il file nginx1.example.com in /etc/nginx/sites-available/ per la configurazione del tuo secondo sito web.

    File:nginx1 .esempio.com
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

    server {
        listen 80 proxy_protocol;
        listen [::]:80 proxy_protocol;

        server_name nginx1.example.com;

        location / {
                include /etc/nginx/proxy_params;

                proxy_pass http://nginx1.lxd;
        }

        real_ip_header proxy_protocol;
        set_real_ip_from 127.0.0.1;
}

    Puoi eseguire sudo nano /etc/nginx/sites-available/nginx1.example.com per creare la configurazione. Nota, devi solo modificare i campi server_name essere il nome host del sito web.

  3. Abilita il sito web.

    sudo ln -s /etc/nginx/sites-available/nginx1.example.com /etc/nginx/sites-enabled/

  4. Riavvia il servizio proxy inverso NGINX.

    sudo systemctl reload nginx

  5. Esci dal container proxy e torna all'host.

    logout

  6. Dal tuo computer locale, visita l'URL del tuo sito web con il tuo browser web. Dovresti vedere la seguente pagina NGINX predefinita.

Aggiunta del supporto per HTTPS con Let's Encrypt

  1. Avvia una shell nel proxy contenitore.

    lxc exec proxy -- sudo --user ubuntu --login

  2. Aggiungi il repository ppa:certbot/certbot eseguendo il comando seguente.

    sudo add-apt-repository ppa:certbot/certbot

  3. L'output è simile al seguente.

    This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu(s).
      More info: https://launchpad.net/~certbot/+archive/ubuntu/certbot
     Press [ENTER] to continue or Ctrl-c to cancel adding it.

     Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
     ...
     Fetched 3360 kB in 2s (2018 kB/s)
     Reading package lists... Done

  4. Installare i seguenti due pacchetti per a) supportare la creazione di certificati Let's Encrypt; e b) configurare automaticamente il proxy inverso NGINX per utilizzare i certificati Let's Encrypt. I pacchetti vengono estratti dal repository appena creato.

    sudo apt-get install certbot python-certbot-nginx
    Nota Questo configura il proxy inverso in modo che funga anche da proxy di terminazione TLS . Qualsiasi configurazione HTTPS si trova solo nel proxy contenitore. In questo modo non è necessario eseguire alcuna attività all'interno dei contenitori del server web relativa ai certificati e Let's Encrypt.

  5. Esegui certbot come root con --nginx parametro per eseguire l'autoconfigurazione di Let's Encrypt per il primo sito web. Ti viene chiesto di fornire un indirizzo email valido per il rinnovo urgente e gli avvisi di sicurezza. Ti viene quindi chiesto di accettare i Termini di servizio e se desideri essere contattato dalla Electronic Frontier Foundation in futuro. Quindi, fornisci il sito Web per il quale stai attivando HTTPS. Infine, puoi scegliere di configurare una struttura che reindirizza automaticamente le connessioni HTTP alle connessioni HTTPS.

    sudo certbot --nginx

    Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): [email protected]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: apache1.example.com
2: nginx1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for apache1.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/apache1.example.com

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/apache1.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://apache1.example.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=apache1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/apache1.example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/apache1.example.com/privkey.pem
   Your cert will expire on 2019-10-07. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

  6. Esegui certbot come root con --nginx parametro per eseguire l'autoconfigurazione di Let's Encrypt per il secondo sito web. Questa è la seconda volta che eseguiamo certbot , quindi ci viene chiesto direttamente di selezionare il sito web da configurare.

    sudo certbot --nginx

    Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: apache1.example.com
2: nginx1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 2
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for nginx1.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/nginx1.example.com

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/nginx1.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://nginx1.example.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=nginx1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/nginx1.example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/nginx1.example.com/privkey.pem
   Your cert will expire on 2019-10-07. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

  7. Dopo aver aggiunto tutti i siti Web, eseguire una prova a secco per testare il rinnovo dei certificati. Verifica che tutti i siti Web vengano aggiornati correttamente per garantire che la struttura automatizzata abbia aggiornato i certificati senza ulteriori sforzi.

    sudo certbot renew --dry-run

    Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/apache1.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for apache1.example.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/apache1.example.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nginx1.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for nginx1.example.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/nginx1.example.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/apache1.example.com/fullchain.pem (success)
  /etc/letsencrypt/live/nginx1.example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
    Nota Il certbot il pacchetto aggiunge un timer di sistema al fine di attivare il rinnovo automatico dei certificati Let's Encrypt. Puoi visualizzare i dettagli di questo timer eseguendo systemctl list-timers .

  8. Lo strumento certbot modifica e cambia i file di configurazione NGINX dei tuoi siti web. In tal modo, certbot non obbedisce a listen iniziale direttiva (listen 80 proxy_protocol; ) e non aggiunge il proxy_protocol parametro al nuovo listen 443 ssl; Linee. È necessario modificare i file di configurazione per ciascun sito Web e aggiungere "proxy_protocol" a ciascun "listen 443 ssl;" linea.

     sudo nano /etc/nginx/sites-enabled/apache1.example.com
 sudo nano /etc/nginx/sites-enabled/nginx1.example.com

    listen 443 ssl proxy_protocol; # managed by Certbot
listen [::]:443 ssl proxy_protocol; # managed by Certbot
    Nota Ogni file di configurazione del sito web ha due coppie di listen direttive:rispettivamente HTTP e HTTPS. La prima è la coppia originale per HTTP che è stata aggiunta in una sezione precedente. La seconda coppia è stata aggiunta da certbot per HTTPS. Queste sono coppie perché coprono sia IPv4 che IPv6. La notazione [::] si riferisce a IPv6. Quando si aggiunge il parametro proxy_protocol , aggiungilo prima del ; su ogni riga come mostrato sopra.

  9. Riavvia NGINX.

    sudo systemctl restart nginx

Risoluzione dei problemi

Browser Error “SSL_ERROR_RX_RECORD_TOO_LONG”

You have configured Certbot and created the appropriate Let’s Encrypt configuration for each website. But when you access the website from your browser, you get the following error.

Secure Connection Failed

An error occurred during a connection to apache1.example.com. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

This error is caused when the NGINX reverse proxy in the proxy container does not have the proxy_protocol parameter in the listen 443 direttive. Without the parameter, the reverse proxy does not consume the PROXY protocol information before it performs the HTTPS work. It mistakenly passes the PROXY protocol information to the HTTPS module, hence the record too long error.

Follow the instructions in the previous section and add proxy_protocol to all listen 443 direttive. Finally, restart NGINX.

Error “Unable to connect” or “This site can’t be reached”

When you attempt to connect to the website from your local computer and receive Unable to connect or This site can’t be reached errors, it is likely the proxy devices have not been configured.

Run the following command on the host to verify whether LXD is listening and is able to accept connections to ports 80 (HTTP) and 443 (HTTPS).

sudo ss -ltp '( sport = :http || sport = :https )'
Nota

The ss command is similar to netstat and lsof . It shows information about network connections. In this case, we use it to verify whether there is a service on ports 80 and 443, and which service it is.

  • -l , to display the listening sockets,
  • -t , to display only TCP sockets,
  • -p , to show which processes use those sockets,
  • ( sport = :http || sport = :https ) , to show only ports 80 and 443 (HTTP and HTTPS, respectively).

In the following output we can verify that both ports 80 and 443 (HTTP and HTTPS, respectively) are in the LISTEN stato. In the last column we verify that the process listening is lxd itself.

State     Recv-Q  Send-Q   Local Address:Port   Peer Address:Port
LISTEN    0       128                  *:http              *:*       users:(("lxd",pid=1301,fd=7),("lxd",pid=1301,fd=5))
LISTEN    0       128                  *:https             *:*       users:(("lxd",pid=1349,fd=7),("lxd",pid=1349,fd=5))

If you see a process listed other than lxd , stop that service and restart the proxy contenitore. By restarting the proxy container, LXD applies the proxy devices again.

The Apache access.log Shows the IP Address of the Proxy Container

You have set up the apache1 container and verified that it is accessible from the internet. But the logs at /var/log/apache2/access.log still show the private IP address of the proxy container, either the private IPv4 (10.x.x.x ) or the private IPv6 addresses. What went wrong?

The default log formats for printing access logs in Apache only print the IP address of the host of the last hop (i.e. the proxy server). This is the %h format specifier as shown below.

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common

The %h must be manually replaced with the %a format specifier, which prints the value as returned by the real RemoteIP Apache module.

LogFormat "%v:%p %a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%a %l %u %t \"%r\" %>s %O" common

  1. Run the following command in the apache1 container to edit the configuration file httpd.conf and perform the change from %h to %a .

    sudo nano /etc/apache2/apache2.conf

  2. Reload the Apache web server service.

     sudo systemctl reload apache2

Next Steps

You have set up a reverse proxy to host many websites on the same server and installed each website in a separate container. You can install static or dynamic websites in the containers. For dynamic websites, you may need additional configuration; check the respective documentation for setup using a reverse proxy. In addition, you may also use NGINX as a reverse proxy for non-HTTP(S) services.

Maggiori informazioni

Si consiglia di consultare le seguenti risorse per ulteriori informazioni su questo argomento. Sebbene questi siano forniti nella speranza che possano essere utili, tieni presente che non possiamo garantire l'accuratezza o la tempestività dei materiali ospitati esternamente.

  • LXD Introduction
  • LXD support community
  • Try LXD Online
  • NGINX Web Server
  • Apache Web Server
  • NGINX Reverse Proxy Settings
  • Proxy Protocol
  • TLS Termination Proxy

Docker

  1. Come configurare un proxy inverso Nginx

  2. Che cos'è un contenitore Docker:una guida introduttiva per principianti

  3. Ospita più siti Web su contenitori Docker

  4. Guida per principianti a NFS in CentOS / RHEL

  5. Guida per principianti a SELinux

Una guida per principianti a LVM

Impostazione di un IP statico su Ubuntu:una guida per principianti

Una guida per principianti a Cron Jobs

Come impostare il proxy inverso Nginx

Guida per principianti al mondo Docker

Guida per principianti alla gestione degli utenti MySQL