NGINX-Website nur über VPN: Listener, Firewall und HTTP-Zulassungsliste

Eine private NGINX-Website braucht einen gebundenen VPN-Socket, eine begrenzte Host-Eingangsregel und eine intakte HTTP-Zugangsliste. Prüfen Sie alle drei, nicht nur einen Serverblock.

Drei unabhängige Entscheidungen stehen zwischen einer privaten Website und dem Internet: Welcher Socket die Verbindung annimmt, welcher Pfad sie zustellen darf und welchen HTTP-Clients der gewählte Server antwortet. Ein Serverblock trifft nur die erste Entscheidung. Behandeln Sie die anderen beiden als getrennte Kontrollen, sonst wirkt die Website privat, während ein alter Eingang offen bleibt. Die meisten NGINX-Fehler bei reinen VPN-Sites entstehen daraus, nur die erste Schicht zu testen.

Das Beispiel verwendet ein Linux-OpenVPN-Gateway unter 10.90.0.1 auf tun0, Clients in 10.90.0.0/24, erhaltene Quelladressen und TCP 8443, das für diesen Eingang reserviert ist. Passen Sie die Werte an, behalten Sie die Schichten.

Beginnen Sie mit dem Socket, nicht mit dem Hostnamen

Binden Sie den HTTPS-Listener an die Tunneladresse und einen eigenen Port. Eine konkrete Adresse ist leichter zu durchschauen als ein Wildcard-Socket plus Namensprüfung, weil der Kernel den Port nicht an eine andere lokale Adresse weitergibt.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Das Zertifikat muss den Diensthostnamen nennen, den Clients eingeben, und die private DNS-Ansicht muss diesen Host auf die gebundene Adresse auflösen. server_name wählt nur einen virtuellen Host aus; es authentifiziert niemanden. Ein fehlender DNS-Eintrag erzeugt einen Zertifikatsfehler, der wie ein TLS-Fehler aussieht. Prüfen Sie den Namen, bevor Sie das Zertifikat austauschen.

Lesen Sie die wirksame Konfiguration, bevor Sie die Datei hinzufügen. Includes und Wildcard-Listener können dieselbe Wurzel anderswo ausliefern, und ein Standardserver kann Anfragen beantworten, die der neue Block nie sieht.

Schließen Sie jeden anderen Listener für diesen Inhalt

Listen Sie die listen-Direktiven auf und vergleichen Sie die Wurzeln, die sie ausliefern. Ein für eine andere Anwendung hinzugefügter Block kann auf dasselbe Upstream weiterleiten, und ein alter Standardserver kann weiter antworten, nachdem der neue steht. Diese Ausgabe ist das eigentliche Inventar, nicht die Datei, die Sie gerade bearbeitet haben. Vergleichen Sie jede Wurzel, die denselben Inhalt ausliefert.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Prüfen Sie beide Adressfamilien. Eine IPv4-Bindung lässt einen IPv6-Socket unberührt, und ein neuer A-Eintrag zieht keine alte AAAA-Antwort zurück, die noch auf einen öffentlichen Pfad zeigt.

Nehmen Sie den alten virtuellen Host als separate Änderung außer Betrieb. Das Entfernen des öffentlichen Zwilling des neuen Blocks ist meist der Schritt, der den Eingang tatsächlich schließt; der private Listener fügt nur den beabsichtigten hinzu.

Begrenzen Sie den eingehenden Pfad am Host

Die Listen-Adresse begrenzt den Socket, nicht die Eingangsschnittstelle. Ein Paket, das von anderswo an diese Adresse geroutet wird, kommt trotzdem als lokale Eingabe an, deshalb braucht die Host-Firewall ihre eigene Aussage darüber, woher die Verbindung kommen darf. Darum erfüllt eine Bindung allein selten ein Audit.

Bei einer eingehenden Standard-Ablehnungspolitik ohne weitergehende Erlaubnis für diesen Dienst benennt eine begrenzte Regel Tunnel, Quellbereich, Ziel und Port gemeinsam:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Lesen Sie die wirksame Firewall-Reihenfolge, bevor Sie sie anwenden. Eine frühere breite Annahme kann die Einschränkung aushebeln, und ein früherer terminaler Drop kann verhindern, dass diese Erlaubnis überhaupt erreicht wird. Spülen Sie keine unabhängigen Regeln und schalten Sie die Firewall nicht ab, damit das Beispiel passt.

Diese Regel ist Host-Eingabe, keine Route zu einem anderen LAN-Rechner, und der äußere OpenVPN-Listener des Gateways bleibt ein separater Dienst. Wenn die Website zuvor öffentlich war, planen Sie, wie der alte Eingang außer Betrieb genommen wird und wie bestehende Sitzungen behandelt werden.

Halten Sie die HTTP-Liste intakt, während sich Standorte ändern

NGINX wertet allow- und deny-Einträge der Reihe nach aus, und die Liste auf Serverebene oben lässt den erklärten Pool vor dem abschließenden deny zu. Das Zugriffsmodul hält außerdem fest, dass ein Standort, der einen beliebigen Zugriffseintrag definiert, seine eigene Liste statt der übergeordneten verwendet. Die Reihenfolge ist ebenso wichtig wie die Einträge selbst.

Diese Zurücksetzung ist die übliche Regression. Ein neuer Upload-, API- oder Health-Standort, der einen Eintrag hinzufügt, ersetzt stillschweigend die Einschränkung auf Serverebene, und die Website wird an dem zuletzt hinzugefügten Pfad breiter.

Prüfen Sie jeden Standort, Alias und alternativen Block als Teil derselben Richtlinie. Wenn IP-Prüfungen mit NGINX-Authentifizierung kombiniert werden, verstehen Sie satisfy: Eine any-Einstellung kann einen Client über einen Mechanismus hereinlassen, während der andere nicht bestanden ist. Setzen Sie die Zugangsliste auf die Prüfliste für Standorte.

Eine HTTP-Ablehnung erfolgt, nachdem die TCP-Verbindung NGINX erreicht. Sie ergänzt die Netzwerkbeschränkung, und die eigene Autorisierung der Anwendung gilt weiterhin für jeden Benutzer.

Überprüfen Sie den Live-Pfad und den Fehlerfall

Führen Sie den Konfigurationsparser aus, prüfen Sie die lauschenden Sockets und stellen Sie dann eine neue benannte Anfrage von einem vorgesehenen Client. Bestätigen Sie, dass das Zertifikat validiert, der DNS-Name auf die gebundene Adresse auflöst und die Antwort von der erwarteten Wurzel kommt.

Testen Sie als Nächstes eine ausgeschlossene Quelle und einen alternativen Eingang. Eine funktionierende erlaubte Anfrage sagt nichts über die Pfade aus, die Sie schließen wollten, und im ausgeschlossenen Test zeigt sich ein übrig gebliebener Listener oder eine breite Firewall-Annahme.

Wiederholen Sie den Start- oder VPN-Wiederherstellungsfall. Wenn NGINX startet, bevor die Tunneladresse existiert, kann die Bindung selbst mit perfekter Datei fehlschlagen. Koordinieren Sie die Adressbereitschaft und halten Sie einen lokalen Wiederherstellungspfad bereit, bevor Sie einen gemeinsam genutzten Webserver ändern.

Notieren Sie Socket, Port, Quellbereich und HTTP-Liste, die bestanden haben. Die nächste VPN- oder DNS-Änderung kann jeden davon verschieben, und vier benannte Werte lassen sich leichter vergleichen als ein funktionierender Browser-Tab.

Ähnliche Artikel