Einführung
LXD (ausgesprochen „Lex-Dee“) ist ein System-Container-Manager, der auf Linux Containers (LXC) aufbaut, die von Canonical unterstützt werden. Das Ziel von LXD ist es, ein Erlebnis zu bieten, das einer virtuellen Maschine ähnelt, jedoch durch Containerisierung und nicht durch Hardwarevirtualisierung. Im Vergleich zu Docker zum Bereitstellen von Anwendungen bietet LXD nahezu vollständige Betriebssystemfunktionalität mit zusätzlichen Funktionen wie Snapshots, Live-Migrationen und Speicherverwaltung.
Ein Reverse-Proxy ist ein Server, der zwischen internen Anwendungen und externen Clients sitzt und Client-Anfragen an den entsprechenden Server weiterleitet. Obwohl viele gängige Anwendungen wie Node.js in der Lage sind, eigenständig als Server zu fungieren, fehlen ihnen möglicherweise eine Reihe von erweiterten Lastausgleichs-, Sicherheits- und Beschleunigungsfunktionen.
Diese Anleitung erläutert die Erstellung eines Reverse-Proxys in einem LXD-Container, um mehrere Websites in jeweils eigenen zusätzlichen Containern zu hosten. Sie werden NGINX- und Apache-Webserver verwenden und sich gleichzeitig auf NGINX als Reverse-Proxy verlassen.
Bitte beziehen Sie sich auf das folgende Diagramm, um den in diesem Handbuch erstellten Reverse-Proxy zu verstehen.
In diesem Handbuch werden Sie:
-
Installieren und konfigurieren Sie Container für NGINX- und Apache-Webserver.
-
Erfahren Sie, wie Sie einen Reverse-Proxy in einem Container installieren und konfigurieren.
-
Holen Sie sich SSL/TLS-Unterstützung durch Let’s Encrypt-Zertifikate mit automatischer Zertifikatserneuerung.
-
Fehlerbehebung bei häufigen Fehlern.
Hinweis Der Einfachheit halber der Begriff Container wird in diesem Handbuch verwendet, um die Container des LXD-Systems zu beschreiben.
Bevor Sie beginnen
-
CompleteA Beginner’s Guide to LXD:Einrichten eines Apache-Webservers in einem Container. Die Anleitung weist Sie an, einen Container namens
webzu erstellen mit dem Apache-Webserver zu Testzwecken. Entfernen Sie diesen Container, indem Sie die folgenden Befehle ausführen.lxc stop web lxc delete webHinweis
Für diese Anleitung wird LXD Version 3.3 oder höher benötigt. Überprüfen Sie die Version mit dem folgenden Befehl:
lxd --versionWenn die Version nicht 3.3 oder höher ist, aktualisieren Sie auf die neueste Version, indem Sie das Snap-Paket gemäß den Anweisungen in A Beginner’s Guide to LXD:Setting Up an Apache Webserver In a Container installieren und den folgenden Befehl verwenden:
sudo lxd.migrate -
Diese Anleitung verwendet die Hostnamen
apache1.example.comundnginx1.example.comfür die beiden Beispiel-Websites. Ersetzen Sie diese Namen durch Hostnamen, die Ihnen gehören, und richten Sie ihre DNS-Einträge so ein, dass sie auf die IP-Adresse des von Ihnen erstellten Servers verweisen. Hilfe zu DNS finden Sie in unserem DNS-Manager-Handbuch.
Container erstellen
-
Erstellen Sie zwei Container namens
apache1undnginx1, eine mit dem Apache-Webserver und eine andere mit dem NGINX-Webserver. Für zusätzliche Websites können Sie mit der von Ihnen gewählten Webserver-Software neue Container erstellen.lxc launch ubuntu:18.04 apache1 lxc launch ubuntu:18.04 nginx1 -
Erstellen Sie den
proxyContainer für den Reverse-Proxy.lxc launch ubuntu:18.04 proxy -
Listen Sie die Container mit dem list-Befehl auf.
lxc list -
Die Ausgabe sieht etwa so aus.
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+ | 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 | | +---------+---------+---------------------+-----------------------------------------------+------------+-----------+Es gibt drei Container, alle im RUNNING Staat – jeder mit seiner eigenen privaten IP-Adresse. Notieren Sie sich die IP-Adressen (sowohl IPv4 als auch IPv6) für den
proxydes Containers . Sie benötigen sie, um denproxyzu konfigurieren Container in einem späteren Abschnitt.Nachdem die Container erstellt wurden, wird in den folgenden Schritten detailliert beschrieben, wie die Webserver-Software in
apache1eingerichtet wird undnginx1Container und derproxyContainer, damit die Webserver aus dem Internet erreichbar sind.
Konfigurieren des Apache-Webserver-Containers
Bei der Verwendung eines Reverse-Proxys vor einem Webserver kennt der Webserver die IP-Adressen der Besucher nicht. Der Webserver sieht nur die IP-Adresse des Reverse-Proxys. Jeder Webserver hat jedoch eine Möglichkeit, die echte entfernte IP-Adresse eines Besuchers zu identifizieren. Für Apache wird dies mit dem Remote IP Apache-Modul durchgeführt. Damit das Modul funktioniert, muss der Reverse-Proxy so konfiguriert werden, dass er die Informationen der Remote-IP-Adresse weiterleitet.
-
Starten Sie eine Shell im
apache1Behälter.lxc exec apache1 -- sudo --user ubuntu --login -
Aktualisieren Sie die Paketliste in
apache1Behälter.sudo apt update -
Installieren Sie das Paket apache2 im Behälter.
sudo apt install -y apache2 -
Erstellen Sie die Datei
/etc/apache2/conf-available/remoteip.conf.- Datei:remoteip .conf
1 2RemoteIPHeader X-Real-IP RemoteIPTrustedProxy 10.10.10.28 fd42:67a4:b462:6ae2:216:3eff:fe00:252e
Sie können den
nanoverwenden Texteditor durch Ausführen des Befehlssudo nano /etc/apache2/conf-available/remoteip.conf. Beachten Sie, dass dies die IP-Adressen desproxysind Container, der zuvor gezeigt wurde, sowohl für IPv4 als auch für IPv6. Ersetzen Sie diese durch die IPs aus Ihrerlxc listAusgabe.Hinweis Anstatt die IP-Adressen anzugeben, können Sie auch den Hostnamen
proxy.lxdverwenden . Das Apache-Modul RemoteIP ist jedoch bei der Verwendung des Hostnamens eigenartig und verwendet nur eine der beiden IP-Adressen (entweder IPv4 oder IPv6), was bedeutet, dass der Apache-Webserver die tatsächliche Quell-IP-Adresse für einige Verbindungen nicht kennt. Indem Sie sowohl IPv4- als auch IPv6-Adressen explizit auflisten, können Sie sicher sein, dass RemoteIP die Quell-IP-Informationen von allen Verbindungen des Reverse-Proxys erfolgreich akzeptiert. -
Aktivieren Sie die neue
remoteip.confKonfiguration.sudo a2enconf remoteipEnabling conf remoteip. To activate the new configuration, you need to run: systemctl reload apache2 -
Aktivieren Sie
remoteipApache-Modul.sudo a2enmod remoteipEnabling module remoteip. To activate the new configuration, you need to run: systemctl restart apache2 -
Bearbeiten Sie die Standardwebseite für Apache, um einen Verweis darauf zu erstellen, dass sie in einem LXD-Container ausgeführt wird.
sudo nano /var/www/html/index.htmlÄndern Sie die Zeile „Es funktioniert!“ (Zeilennummer 224) zu „Es funktioniert in einem LXD-Container!“ Speichern und beenden.
-
Starten Sie den Apache-Webserver neu.
sudo systemctl reload apache2 -
Zurück zum Host.
exit
Sie haben den Apache-Webserver erstellt und konfiguriert, aber der Server ist noch nicht über das Internet erreichbar. Es wird zugänglich, nachdem Sie den proxy konfiguriert haben Container in einem späteren Abschnitt.
Erstellen des NGINX-Webserver-Containers
Wie Apache kennt NGINX die IP-Adressen von Besuchern nicht, wenn ein Reverse-Proxy vor einem Webserver verwendet wird. Stattdessen sieht er nur die IP-Adresse des Reverse-Proxys. Jede NGINX-Webserver-Software kann mit dem Real-IP-Modul die echte Remote-IP-Adresse eines Besuchers identifizieren. Damit das Modul funktioniert, muss der Reverse-Proxy entsprechend konfiguriert werden, um die Informationen bezüglich der entfernten IP-Adressen weiterzugeben.
-
Starten Sie eine Shell in
nginx1Behälter.lxc exec nginx1 -- sudo --user ubuntu --login -
Aktualisieren Sie die Paketliste in
nginx1Behälter.sudo apt update -
Installieren Sie NGINX im Behälter.
sudo apt install -y nginx -
Erstellen Sie die Datei
/etc/nginx/conf.d/real-ip.conf.- Datei:real -ip.conf
1 2real_ip_header X-Real-IP; set_real_ip_from proxy.lxd;
Sie können den
nanoverwenden Texteditor durch Ausführen des Befehlssudo nano /etc/nginx/conf.d/real-ip.conf.Hinweis Sie haben den Hostnamen des Reverse-Proxys
proxy.lxdangegeben . Jeder LXD-Container erhält automatisch einen Hostnamen, der aus dem Namen des Containers plus dem Suffix.lxdbesteht . Durch Angabe vonset_real_ip_fromFeld mitproxy.lxd, weisen Sie den NGINX-Webserver an, die echten IP-Adressinformationen für jede Verbindung zu akzeptieren, solange diese Verbindung vonproxy.lxdstammt . Die Informationen zur echten IP-Adresse befinden sich im HTTP-HeaderX-Real-IPin jeder Verbindung. -
Bearbeiten Sie die Standardwebseite für NGINX, um einen Verweis darauf zu erstellen, dass sie in einem LXD-Container ausgeführt wird.
sudo nano /var/www/html/index.nginx-debian.htmlÄndern Sie die Zeile „Welcome to nginx!“ (Zeile Nummer 14) zu „Willkommen bei nginx, das in einem LXD-Systemcontainer ausgeführt wird!“. Speichern und beenden.
-
Starten Sie den NGINX-Webserver neu.
sudo systemctl reload nginx -
Zurück zum Host.
exit
Sie haben den NGINX-Webserver erstellt und konfiguriert, aber der Server ist noch nicht über das Internet erreichbar. Es wird zugänglich, nachdem Sie den proxy konfiguriert haben Container im nächsten Abschnitt.
Reverse-Proxy einrichten
In diesem Abschnitt konfigurieren Sie den Container proxy . Sie installieren NGINX und richten es als Reverse-Proxy ein und fügen dann das entsprechende LXD-Proxy-Gerät hinzu um beide Ports 80 und 443 für das Internet verfügbar zu machen.
-
LXD-Proxy-Geräte hinzufügen um Verbindungen aus dem Internet auf die Ports 80 (HTTP) und 443 (HTTPS) auf dem Server auf die entsprechenden Ports am
proxyumzuleiten Behälter.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=trueDevice myport80 added to proxy Device myport443 added to proxyDas
lxc config device addDer Befehl nimmt als Argumente:Argument Erklärung proxyDer Name des Containers. myport80Ein Name für dieses Proxy-Gerät. proxyDer Typ des LXD-Geräts (LXD proxy Gerät). listen=tcp:0.0.0.0:80Das Proxy-Gerät lauscht auf dem Host (Standard) auf Port 80, Protokoll TCP, auf allen Schnittstellen. connect=tcp:127.0.0.1:80Das Proxy-Gerät verbindet sich mit dem Container auf Port 80, Protokoll TCP, auf der Loopback-Schnittstelle. In früheren Versionen von LXD hätten Sie localhostangeben können hier. In LXD 3.13 oder höher können Sie jedoch nur IP-Adressen angeben.proxy_protocol=trueFordern Sie an, das PROXY-Protokoll zu aktivieren, damit der Reverse-Proxy die Ursprungs-IP-Adresse vom Proxy-Gerät erhält. Hinweis
Wenn Sie ein Proxy-Gerät entfernen möchten, verwenden Sie
lxc config device remove. Wenn Sie das obige Gerätmyport80entfernen möchten , führen Sie den folgenden Befehl aus:lxc config device remove proxy myport80Dabei ist Proxy der Name des Containers und myport80 der Name des Geräts.
-
Starten Sie eine Shell im
proxyBehälter.lxc exec proxy -- sudo --user ubuntu --login -
Aktualisieren Sie die Paketliste.
sudo apt update -
Installieren Sie NGINX im Container.
sudo apt install -y nginx -
Vom Container abmelden.
logout
Leiten Sie den Datenverkehr vom Reverse-Proxy zum Apache-Webserver
Der Reverse-Proxy-Container läuft und das NGINX-Paket wurde installiert. Um als Reverse-Proxy zu arbeiten, fügen Sie die entsprechende Website-Konfiguration hinzu, damit NGINX sich identifizieren kann (mit server_name unten) den entsprechenden Hostnamen und übergeben Sie dann (mit proxy_pass unten) die Verbindung zum entsprechenden LXD-Container.
-
Starten Sie eine Shell im
proxyBehälter.lxc exec proxy -- sudo --user ubuntu --login -
Erstellen Sie die Datei
apache1.example.comin/etc/nginx/sites-available/für die Konfiguration Ihrer ersten Website.- Datei:apache1 .example.com
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15server { 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; }
Sie können
sudo nano /etc/nginx/sites-available/apache1.example.comausführen um einen Texteditor zu öffnen und die Konfiguration hinzuzufügen. Beachten Sie, dass Sie in diesem Fall nur denserver_namebearbeiten müssen der Hostname der Website sein. -
Aktivieren Sie die Website.
sudo ln -s /etc/nginx/sites-available/apache1.example.com /etc/nginx/sites-enabled/ -
Starten Sie den NGINX-Reverse-Proxy neu. Durch den Neustart des Dienstes liest und wendet NGINX die neuen Site-Anweisungen an, die gerade zu
/etc/nginx/sites-enabledhinzugefügt wurden .sudo systemctl reload nginx -
Verlassen Sie den Proxy-Container und kehren Sie zum Host zurück.
logout -
Besuchen Sie von Ihrem lokalen Computer aus die URL Ihrer Website mit Ihrem Webbrowser. Sie sollten die Standard-Apache-Seite sehen:
Hinweis Wenn Sie sich die Apache-Datei access.log ansehen (Standarddatei
/var/log/apache2/access.log), zeigt es immer noch die private IP-Adresse desproxyContainer anstelle der echten IP-Adresse. Dieses Problem ist spezifisch für den Apache-Webserver und hat damit zu tun, wie der Server die Protokolle druckt. Andere Software auf dem Webserver kann die echte IP verwenden. Um dies über die Apache-Protokolle zu beheben, lesen Sie den Abschnitt Fehlerbehebung.
Leiten Sie den Datenverkehr vom Reverse-Proxy zum NGINX-Webserver
Der Reverse-Proxy-Container wird ausgeführt und die Datei NGINX Paket installiert wurde. Um als Reverse-Proxy zu arbeiten, müssen Sie die entsprechende Website-Konfiguration hinzufügen, also NGINX identifizieren kann (mit server_name unten) den entsprechenden Hostnamen und übergeben Sie dann (mit proxy_pass unten) die Verbindung zum entsprechenden LXD-Container mit der eigentlichen Webserver-Software.
-
Starten Sie eine Shell im
proxyBehälter.lxc exec proxy -- sudo --user ubuntu --login -
Erstellen Sie die Datei
nginx1.example.comin/etc/nginx/sites-available/für die Konfiguration Ihrer zweiten Website.- Datei:nginx1 .example.com
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15server { 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; }
Sie können
sudo nano /etc/nginx/sites-available/nginx1.example.comausführen um die Konfiguration zu erstellen. Beachten Sie, dass Sie nur die Felderserver_namebearbeiten müssen der Hostname der Website sein. -
Aktivieren Sie die Website.
sudo ln -s /etc/nginx/sites-available/nginx1.example.com /etc/nginx/sites-enabled/ -
Starten Sie den NGINX-Reverse-Proxy-Dienst neu.
sudo systemctl reload nginx -
Verlassen Sie den Proxy-Container und kehren Sie zum Host zurück.
logout -
Besuchen Sie von Ihrem lokalen Computer aus die URL Ihrer Website mit Ihrem Webbrowser. Sie sollten die folgende NGINX-Standardseite sehen.
Hinzufügen von Unterstützung für HTTPS mit Let’s Encrypt
-
Starten Sie eine Shell im
proxyBehälter.lxc exec proxy -- sudo --user ubuntu --login -
Fügen Sie das Repository
ppa:certbot/certbothinzu indem Sie den folgenden Befehl ausführen.sudo add-apt-repository ppa:certbot/certbot -
Die Ausgabe sieht etwa so aus.
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 -
Installieren Sie die folgenden zwei Pakete, um a) die Erstellung von Let’s Encrypt-Zertifikaten zu unterstützen; und b) den NGINX-Reverse-Proxy automatisch konfigurieren, um Let’s Encrypt-Zertifikate zu verwenden. Die Pakete werden aus dem neu erstellten Repository gezogen.
sudo apt-get install certbot python-certbot-nginxHinweis Dadurch wird der Reverse-Proxy so konfiguriert, dass er auch als TLS-Terminierungsproxy fungiert . Jede HTTPS-Konfiguration ist nur im
proxyzu finden Container. Dadurch müssen keine Aufgaben innerhalb der Webserver-Container in Bezug auf Zertifikate und Let’s Encrypt ausgeführt werden. -
Führen Sie
certbotaus als root mit dem--nginxParameter, um die Autokonfiguration von Let’s Encrypt für die erste Website durchzuführen. Sie werden gebeten, eine gültige E-Mail-Adresse für dringende Erneuerungs- und Sicherheitsbenachrichtigungen anzugeben. Anschließend werden Sie gebeten, die Nutzungsbedingungen zu akzeptieren und ob Sie in Zukunft von der Electronic Frontier Foundation kontaktiert werden möchten. Geben Sie als Nächstes die Website an, für die Sie HTTPS aktivieren. Schließlich können Sie eine Einrichtung einrichten, die HTTP-Verbindungen automatisch auf HTTPS-Verbindungen umleitet.sudo certbot --nginxSaving 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 -
Führen Sie
certbotaus als root mit dem--nginxParameter, um die automatische Konfiguration von Let’s Encrypt für die zweite Website durchzuführen. Dies ist das zweite Mal, dass wircertbotausführen , daher werden wir direkt aufgefordert, die zu konfigurierende Website auszuwählen.sudo certbot --nginxSaving 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 -
Führen Sie nach dem Hinzufügen aller Websites einen Probelauf durch, um die Erneuerung der Zertifikate zu testen. Überprüfen Sie, ob alle Websites erfolgreich aktualisiert werden, um sicherzustellen, dass die automatisierte Einrichtung die Zertifikate ohne weiteren Aufwand aktualisiert.
sudo certbot renew --dry-runSaving 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.Note The
certbotpackage adds a systemd timer in order to activate the automated renewal of Let’s Encrypt certificates. You can view the details of this timer by runningsystemctl list-timers. -
The certbot tool edits and changes the NGINX configuration files of your websites. In doing so, certbot does not obey initial
listendirective (listen 80 proxy_protocol;) and does not add theproxy_protocolparameter to the newly addedlisten 443 ssl;lines. You must edit the configuration files for each website and append “proxy_protocol” to each “listen 443 ssl;” line.sudo nano /etc/nginx/sites-enabled/apache1.example.com sudo nano /etc/nginx/sites-enabled/nginx1.example.comlisten 443 ssl proxy_protocol; # managed by Certbot listen [::]:443 ssl proxy_protocol; # managed by CertbotNote Each website configuration file has two pairs of
listendirectives:HTTP and HTTPS, respectively. The first is the original pair for HTTP that was added in a previous section. The second pair was added by certbot for HTTPS. These are pairs because they they cover both IPv4 and IPv6. The notation[::]refers to IPv6. When adding the parameterproxy_protocol, add it before the;on each line as shown above. -
Restart NGINX.
sudo systemctl restart nginx
Troubleshooting
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 directives. 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 directives. 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 )'
NoteThe
sscommand is similar tonetstatandlsof. 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 Zustand. 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 container. 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-
Run the following command in the
apache1container to edit the configuration filehttpd.confand perform the change from%hto%a.sudo nano /etc/apache2/apache2.conf -
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.
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
- LXD Introduction
- LXD support community
- Try LXD Online
- NGINX Web Server
- Apache Web Server
- NGINX Reverse Proxy Settings
- Proxy Protocol
- TLS Termination Proxy