Eine Anleitung zum Installieren eines Reverse-Proxys für HTTP(S), SSH und MySQL/MariaDB mit NGINX
Dieser Leitfaden führt Sie durch die Installation und Konfiguration von NGINX, um den Betrieb mehrerer physischer Server, virtueller Maschinen oder einer Kombination aus beiden hinter einer einzigen öffentlich zugänglichen IP-Adresse zu ermöglichen. Sie können wählen, ob Sie eine Reihe von Webservern auf virtuellen Maschinen betreiben und diese lokal verwalten möchten, oder ob Sie Remote-Zugriffstools wie SSH für jeden der Hosts verwenden müssen. Zum Beispiel, wenn der lokale Zugang außerhalb der normalen Geschäftszeiten nicht verfügbar ist. Dieser Leitfaden kann beide Szenarien erleichtern.
Die hier gezeigten Konfigurationen eignen sich am besten für ein Heimlabor oder ein kleines Firmennetzwerk, das Einschränkungen bei den verfügbaren öffentlichen IP-Adressen hat. Es gäbe wenig Grund, eine solche Konfiguration auszuführen, wenn Sie mehrere Server oder virtuelle Maschinen von einem Hosting-Dienst gemietet haben, wird Ihnen ohnehin eine öffentlich zugängliche IP-Adresse für jeden Server oder Host zugewiesen.
Ich zeige Ihnen, wie Sie NGINX installieren und Konfigurationen vornehmen, die es dem Server ermöglichen, als Reverse-Proxy für HTTP(S), SSH, FTP und MySQL/MariaDB zu fungieren. Ich gehe davon aus, dass Sie für den NGINX-Hostserver: lokalen Zugriff, eine Neuinstallation von Ubuntu 18.04 und dass Sie sich für die Installation des SSH-Servers während der Installationsschritte des Ubuntu-Servers entschieden haben.
Diese Konfiguration funktioniert für mich gut, aber bitte verstehen Sie, dass ich keine Garantie dafür geben kann, dass dies für Sie funktioniert. Natürlich, wenn du etwas Falsches findest, lass es mich wissen, damit es korrigiert werden kann. Bitte stellen Sie sicher, dass Sie den gesamten Leitfaden lesen, bevor Sie beginnen, es gibt einen Teil (Streams), in dem ich zwei Möglichkeiten zeige, ihn zu verwalten.
Erste Schritte
In diesem Handbuch werde ich die folgenden Hostnamen und IP-Adressen verwenden.
rproxy.example.com 192.168.1.1 web1.example.com 192.168.1.2 db1.exmple.com 192.168.1.3
Sie sollten auf dem Server ein Nicht-Root-Benutzerkonto für eine Standard Ubuntu 18.04 Serverinstallation haben, die Sie während der Installation erstellt haben. Melden Sie sich zunächst auf dem Server an, auf dem Sie NGINX mit diesem Benutzer installieren werden. Da es sich höchstwahrscheinlich um einen lokalen Server handelt, müssen Sie sich möglicherweise beim ersten Mal direkt am Server anmelden, um den SSH-Server zu konfigurieren. Dazu benötigen Sie natürlich eine Tastatur und einen am Server angeschlossenen Monitor.
Hinweis: Wenn Sie wie ich Virtualisierungssoftware wie VMWare verwenden, die eine Browseroberfläche enthält, dann sollten Sie eine Konsole in diesem System haben und können diesen Schritt ohne „direkten“ Zugriff durchführen. Sie könnten versuchen, diese gesamte Konfiguration innerhalb dieser Konsole durchzuführen, aber ich habe festgestellt, dass einige Funktionen wie Kopieren und Einfügen in der browserbasierten Konsole nicht funktionierten, obwohl dies browserspezifisch sein könnte, so dass es sich lohnen könnte, zu versuchen, zu sehen, ob Sie es können.
Vorbereitung des Hostservers
In Ihrer Konsolen-Shell (Browser oder direkt verbunden)
sudo nano /etc/ssh/sshd_config
Entkommentieren Sie die Zeilen: Port ändern Sie die Portnummer auf etwas wie 23456, ListenAddress und ändern Sie diese auf 0.0.0.0.0.0. Für diejenigen, die mit Nano nicht vertraut sind, drücken Sie STRG + X, geben Sie y ein und drücken Sie dann die Eingabetaste. Dadurch wird eine Datei gespeichert und geschlossen, wenn keine Änderungen an der Datei vorgenommen wurden, wird die Datei mit STRG + x ohne Aufforderung zum Speichern geschlossen. Sie gelangen zurück zur Eingabeaufforderung.
Ich werde nicht in den Rest der Einstellungen in dieser Datei graben, da dies bereits ein ziemlich langer Leitfaden ist und es viele Leitfäden gibt, die Ihnen zeigen, welche Einstellungen Sie für eine Reihe von Dingen ändern sollten, wie z.B. die Verwendung von SSH-Schlüsseln und das Zulassen von root-SSH-Logins. Sie können diese Anleitungen auch direkt hier auf der HowtoForge-Website finden.
Wenn die Änderungen abgeschlossen sind, müssen Sie den ssh-Server neu starten, damit die Änderungen wirksam werden. Ihr aktuelles Login ist von diesem Neustart nicht betroffen.
systemctl restart ssh
Vergewissern Sie sich, dass Sie sich mit SSH von einem Terminal auf einem anderen Computer in Ihrem lokalen Netzwerk aus anmelden können.
ssh user@192.168.1.1 -p23456
Halten Sie dieses Terminal nach erfolgreicher Anmeldung mit SSH offen und melden Sie sich von der Konsole/Server ab. Sie müssen es für den Rest dieses Handbuchs nicht mehr verwenden.
Von diesem Zeitpunkt an werden Sie von Ihrem Terminal aus Befehle auf Root-Ebene ausführen. Mit dem nächsten Befehl entfällt die Notwendigkeit, nachfolgende Befehle mit sudo voranzustellen.
sudo -s
Aktualisieren Sie die Apt-Paketdatenbank und aktualisieren Sie Ubuntu, um sicherzustellen, dass Sie die neuesten Pakete installiert haben.
apt update && apt -y upgrade
Sollten Sie während des Upgrades etwas sehen, das über neue Kernel berichtet, die installiert werden, sollten Sie einen Neustart durchführen, sobald apt das Upgrade abgeschlossen hat, um sicherzustellen, dass Sie auf einem vollständig aktualisierten System arbeiten.
Setzt den Hostnamen des umgekehrten Proxy-Servers.
hostnamectl set-hostname rproxy.example.com
Wenn Sie einen virtuellen Server betreiben, verfügen Sie möglicherweise über eine Datei namens cloud.cfg, die geändert werden muss, um den hier eingestellten Hostnamen zu erhalten. Der folgende Befehl zeigt entweder eine Datei mit Inhalt oder eine leere Seite an. Wenn du eine leere Seite siehst, kannst du einfach STRG + x drücken und diesen Schritt überspringen, da du nichts zu tun hast.
nano /etc/cloud/cloud.cfg
Ändern Sie die Zeile preserve hostname auf true und schließen/speichern Sie die Datei.
If your system is currently local only you will need to show this server where your other servers/virtual hosts are.
nano /etc/hosts
Die Hosts-Datei wird nach den Änderungen in etwa so aussehen, die IP-Adressen und Hosts sollten zu Ihrer eigenen Infrastruktur passen.
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
Installation von NGINX
apt install -y nginx
Nach der Installation sollten Sie Ihre NGINX-Version überprüfen, es ist wichtig, dass Sie eine Version 1.9 oder höher haben, damit Sie den Proxy für SSH und MySQL/MariaDB umkehren können.
nginx -v
Wie Sie sehen können, habe ich NGINX Version 1.14 installiert, was der Standard in Ubuntu 18.04 (10. Oktober 2019) ist.
nginx version: nginx/1.14.0 (Ubuntu)
Vorbereitung von NGINX auf die Funktion als Reverse Proxy
Mit dieser Konfiguration werden Sie keine Websites direkt vom Reverse-Proxy-Hostserver aus bedienen. Sie erstellen eine neue Verzeichnisstruktur unter /etc/nginx/. Dadurch bleiben die standardmäßigen NGINX-Konfigurationen erhalten, falls Sie diese Änderungen später rückgängig machen oder entscheiden, dass Sie Websites auch tatsächlich direkt von diesem Host aus bedienen möchten. Es ist möglich, die Standardkonfiguration zusammen mit diesen umgekehrten Proxy-Konfigurationen auszuführen, aber wenn sich Apache2 auf demselben Server befindet, benötigt es alternative Ports zum Abhören und Sie müssen trotzdem die Websites, die diese Instanz von Apache2 bedient, umkehren.
Aufbau der Reverse-Proxy-Verzeichnisstruktur
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled
Nachdem Sie die Struktur festgelegt haben, können Sie mit der Erstellung der Konfigurationsdateien fortfahren. Ich benutze Nano, aber du kannst den Editor benutzen, mit dem du dich wohl fühlst. Nano erstellt/aktualisiert die Dateien beim Speichern.
Before you proceed, open an empty document on your computer or get a pen and paper to note down the ports you configure.
Konfiguration von Webserver-Reverse-Proxies (http)
Erstellen Sie die http-Konfigurationsdatei(en) für die Website(s), die sich entsprechend anpassen.
nano http/available/example.com.conf
Kopieren Sie den Serverblock in die im Terminal geöffnete Seite mit entsprechender Nano-Anpassung.
# 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; } }
Konfiguration von SSH, MySQL/MariaDB Reverse Proxies (Stream)
Bevor Sie fortfahren, entscheiden Sie sich, welche Sie verwenden möchten, pro Host oder pro Dienst. Pro Host erstellen Sie für jeden Host eine Konfiguration, die nützlich sein kann, um schnell die Einstellungen eines einzelnen Hosts zu ändern. Pro Dienst haben Sie die Dienstports für alle Server in einer Datei für jeden, SSH, MySQL/MariaDB und FTP.
Verwendung von Konfigurationen pro Dienst
Fügen Sie die SSH-Konfigurationen hinzu.
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.
Fügen Sie die MySQL/MariaDB-Konfigurationen hinzu.
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.
Erstellen Sie nun die FTP Reverse Proxy-Konfigurationen.
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.
Verwendung von Konfigurationsdateien pro 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;
}
Erstellen der Hostdatei für 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;
}
Wie du sehen kannst, ist es ein wenig unorthodox. Sie verwenden öffentliche Ports auf nicht standardmäßige Weise, wählen die benötigten Ports aus und verweisen sie dann auf NGINX. Dies wäre normal, außer dass Sie jetzt für jeden Dienst auf jedem Server, auf den Sie aus der Ferne zugreifen möchten, einen anderen Port verwenden. Das bedeutet, dass beispielsweise bei Verwendung von SSH eine andere Portnummer für jeden SSH-fähigen Host 22 222 2222 22222 22222 auf Port 22 auf vier verschiedenen Servern oder virtuellen Maschinen zeigen würde.
Dies ist nicht der Fall bei NGINX to Reverse Proxy für Websites, solange NGINX eine Serverkonfiguration für eine Website definiert hat, wird es korrekt funktionieren, wenn nur die Ports 80 und 443 an ihn weitergeleitet werden.
An dieser Stelle haben Sie wahrscheinlich bemerkt, dass Sie einfach die HTTP-Schritte verwenden und die Stream-Schritte überspringen und stattdessen mehrere Ports für die verschiedenen Dienste an die entsprechende Server/IP-Adresse weiterleiten können. Das ist in der Tat möglich. Es würde jedoch eine weitere Ebene der Komplexität hinzufügen und mit zunehmender Anzahl der Server schwierig zu pflegen sein, da Sie möglicherweise die Standardports auf jedem Server für ssh, mysql und ftp ändern müssen. Diese Konfiguration ist bereits komplex, aber sie kann auch durchgeführt werden, wenn Sie es wünschen.
Wenn Sie einen Reverse-Proxy für diese Dienste so verwenden, wie ich es Ihnen gezeigt habe, verringern Sie die Komplexität erheblich, indem Sie einen einzigen Ort für diese Konfigurationsänderungen zur Verfügung stellen, und Sie müssten keine Änderungen an den Ports in Ihrer gesamten Infrastruktur vornehmen.
Als zusätzlichen Bonus zu dieser Konfiguration müssen die anderen Server in Ihrer Infrastruktur nur auf lokale Schnittstellen und Standard-Ports hören, wenn Sie das bevorzugen. Wenn Sie lokal verwalten, können Sie die lokalen IP-Adressen und Standard-Service-Ports verwenden, um auf die erforderlichen Dienste zuzugreifen, so dass Sie nicht auf Ihre Notizen zurückgreifen müssen, um sich die richtigen Ports zu merken, sondern nur die IP-Adresse und die Anmeldedaten kennen müssen.
Alles zusammenbringen
Um mit der Verwendung der NGINX Reverse-Proxy-Konfigurationen zu beginnen, müssen Sie einige Änderungen an der Hauptkonfigurationsdatei vornehmen. Kommentieren Sie die aktuelle Include-Zeile im http-Block aus (wenn Sie keine Websites direkt von NGINX aus bedienen).
cd /etc/nginx && nano nginx.conf
Beachten Sie die hervorgehobenen Teile unten, um festzustellen, was geändert werden muss.
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;
# }
#}
Aktivieren Sie die Reverse-Proxy-Konfigurationen.
Aktivieren Sie zunächst alle http-Konfigurationen.
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled
Alle Stream-Konfigurationen aktivieren
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabled
Führen Sie einen Test durch, um sicherzustellen, dass die Konfiguration von NGINX als Reverse-Proxy korrekt ist.
nginx -T
In der Ausgabe sollten Sie eine Erfolgsmeldung zusammen mit allen benutzerdefinierten Konfigurationen sehen, die Sie zuvor vorgenommen haben.
Starten Sie NGINX neu, um die Reverse-Proxy-Konfigurationen in Aktion zu setzen.
systemctl restart nginx
Überprüfen Sie, ob NGINX alle konfigurierten Ports überwacht. Überprüfen Sie anhand Ihrer Notizen, ob alle Ports in den Ergebnissen angezeigt werden.
netstat -tulpn | grep nginx
Die Ausgabe sollte etwa so aussehen
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
Öffnen des Servers für den Datenverkehr
Nun, da NGINX zuhört und bereit ist, als Reverse-Proxy für alle Verbindungen zu fungieren, die wir zulassen wollen, deaktivieren Sie UFW vorübergehend, während Sie die nächsten Schritte durchführen. Es erleichtert die Fehlersuche, wenn die Dinge nicht richtig funktionieren.
ufw disable
Weiterleiten von Ports
Leider kann ich Ihnen hier keine Orientierung geben. Sie müssen das Handbuch Ihres Routers lesen oder Ihren Router online nachschlagen, um zu erfahren, wie Sie dies tun können. Zusammenfassend lässt sich sagen, dass Sie jeden der Ports, auf denen NGINX hört, an den NGINX-Hostcomputer weiterleiten möchten. In meinem spezifischen Router bin ich in der Lage, benutzerdefinierte „Anwendungen“ einzurichten.
Dies ermöglicht es mir, der benutzerdefinierten Anwendung eine beliebige Anzahl von nicht zugewiesenen Ports oder Portbereichen zuzuweisen, die dann entweder einer LAN-IP-Adresse oder einem bestimmten angeschlossenen Gerät zugewiesen werden, das durch seinen Hostnamen identifiziert wird. Auf jeden Fall bedeutet dies, dass ich in der Lage bin, alle dieser benutzerdefinierten Anwendung zugeordneten Ports auf jeden Host in meinem Netzwerk umzustellen, ohne alle Ports löschen und neu zuweisen zu müssen. Dies ist eine ausgezeichnete Option, und ich empfehle dir dringend, einen Router zu wählen, der ihn unterstützt.
Diese kleine, aber unglaublich nützliche Funktion in meiner Router-Firewall veranlasste mich, einen zweiten Reverse-Proxy zu installieren, der die Konfigurationen meines aktiven Reverse-Proxy spiegelt. Ich habe es ausgeschaltet und kann hochfahren und die Ports in weniger als 3 Minuten nach der Entdeckung darauf umschalten lassen. Ich stelle mir vor, dass es professionelle Hosting-Unternehmen gibt, die sich schwer tun würden, diese Bearbeitungszeit für Disaster Recovery einzuhalten, und all dies entstand aus dem Wunsch heraus, mehrere Server in einem Heimnetzwerk zu betreiben.
Kostenlose Letsencrypt SSL für den Reverse Proxy Server
Installieren Sie Certbot und Certbot NGINX Plugin. Dieser Schritt wird hier durchgeführt, da Sie erst dann ein Zertifikat erstellen können, wenn Sie über funktionsfähiges DNS für alle in einem Zertifikat aufgeführten (sub.)Domain-Namen verfügen und eine Verbindung zur Domain über HTTP herstellen können. Wenn Sie dies tun, nachdem Sie die Ports an den Reverse-Proxy weitergeleitet haben, dient es auch als zusätzlicher Test für Ihre Konfigurationen. Wenn das cert fehlschlägt, weil die Domain nicht erreichbar ist, erhalten Sie einen aussagekräftigen Fehlerhinweis in der Ausgabe.
Um sicherzustellen, dass Sie die neueste certbot-Version erhalten, fügen Sie vor der Installation das certbot-Repository hinzu. Ubuntu-Repositorien sind oft eine Version oder mehr hinter einer Softwareversion und Sie wollen wirklich die neuesten Stavle-Versionen Ihrer gesamten Software, wenn Sie sie bekommen können.
add-apt-repository ppa:certbot/certbot apt install -y certbot python-certbot-plugin
Mit certbot und dem installierten certbot nginx Plugin können Sie nun die Zertifikate für NGINX erstellen.
Dieser Befehl sollte für alle Domänen und Subdomänen wiederholt werden, für die Sie SSL bereitstellen möchten. Wenn dies das erste Mal ist, dass certbot läuft, müssen Sie die Allgemeinen Geschäftsbedingungen akzeptieren.
certbot --nginx -d example.com -d www.example.com
Beachten Sie, dass Sie, wenn Sie eine funktionierende Serverkonfiguration mit SSL auf dem Upstream-Host haben, sicherstellen müssen, dass die hier ausgewählten Optionen mit denen auf dem Host-Server übereinstimmen, insbesondere, wenn Sie auf den Upstream-Server auf https umleiten, sollten Sie dies auch hier tun.
Aus Gründen der Übersichtlichkeit ist example.com auf einem anderen Server vorhanden, und ich habe mich dafür entschieden, http innerhalb von ISPConfig auf https umzuleiten, also habe ich mich aus diesem Grund dafür entschieden, dies hier zu tun. Die Konfigurationsdatei wird aktualisiert und ich sehe nun, dass Certbot einige eigene Konfigurationen hinzugefügt hat.
Überprüfen, ob die Dinge funktionieren.
Nun, da Sie Traffic haben, der zu Ihrem Reverse-Proxy fließen kann, sollten Sie überprüfen, ob alles wie vorgesehen funktioniert. Überprüfen Sie, ob Websites ordnungsgemäß funktionieren, führen Sie SSH-, FTP- und MySQL/MariaDB-Verbindungen und Aufgaben durch. Sobald Sie überzeugt sind, dass alles so funktioniert, wie es sein sollte, werden Sie UFW aktivieren und Regeln hinzufügen, um jeden der Ports zuzulassen.
Sicherung des Reverse-Proxy-Servers
ufw enable
Sie werden 80 und 443 von überall her zulassen wollen und wahrscheinlich SSH, FTP und MySQL/MariaDB auf eine IP-Adresse oder einen Hostnamen beschränken. Sie können die Regeln kommentieren, um schnell zu erkennen, welchem Dienst/Server Sie den Port zugewiesen haben.
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
Aktualisierung von Apache2
Wenn Apache2-Logdateien hinter einem Reverse-Proxy laufen, wird die IP-Adresse des Reverse-Proxy-Servers anstelle der IP-Adresse des Website-Besuchers gespeichert. Um die normale IP-Adressprotokollierung im Apache2 wiederherzustellen, steht ein Modul zur Verfügung, das dieses Verhalten korrigiert.
Führen Sie die folgenden Schritte auf jedem Webserver mit einer installierten Apache2-Instanz durch.
sudo apt install -y libapache2-mod-rpaf
Um sicherzustellen, dass der Apache2 nun die richtigen IP-Adressen speichert, nehmen Sie eine kleine Änderung an der Datei rpaf.conf vor. Ubuntu 18.04 hat die Datei bereits für uns erstellt, wir müssen sie nur bearbeiten und die markierte IP-Adresse auf die des NGINX Reverse Proxy-Hosts ändern.
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>
Schlussbemerkungen
NGINX und Apache2 im selben Host
Es können nicht zwei Dienste auf demselben Port innerhalb eines Servers oder einer virtuellen Maschine lauschen. Wenn NGINX auf demselben Server oder derselben virtuellen Maschine wie ein Apache2-Webserver installiert ist, müssen Sie den Port ändern, an dem Apache2 lauscht. NGINX benötigt die Ports 80 und 443, um seine HTTP(S)-Funktionen auszuführen, da sie die Standard-Ports für HTTP und HTTPS sind.
Lesen Sie den Abschnitt http in diesem Handbuch und fügen Sie Reverse-Proxy-Konfigurationen für Websites hinzu, die von dieser Apache2-Instanz bedient werden, genauso wie die anderer Server im Netzwerk.
Ändern des Apache2-Listenports
Wenn Sie ein Servermanagementsystem wie ISPConfig installiert haben, verarbeitet dieses System die Apache2 vhost-Dateien, daher sollten Sie untersuchen, wie Sie die Ports ändern können, an denen Apache2 lauscht. Durchsuchen Sie die ISPConfig-Foren und nehmen Sie dann die erforderlichen Anpassungen vor. Andernfalls sollten Sie sich im Ubuntu-Forum oder auf der Apache2-Website informieren, wie Sie diese Änderungen durchführen können.
Note: Apache2 ports do not need to be altered when it is the only web server installed on server or virtual machine.