☰

Nginx Reverse-SSL-Proxy mit mehreren Subdomains

tag-icon • tag-icon nginx reverse-proxy ssl-certificate
Nginx Reverse-SSL-Proxy mit mehreren Subdomains

Ich versuche, ein allgemeines Konfigurationsbeispiel für meine aktuelle Situation zu finden. Wir haben ein Wildcard-SSL-Zertifikat für mehrere Subdomänen, die sich auf mehreren internen IIS-Servern befinden.

site1.example.com (X.X.X.194) -> IISServer01:8081
site2.example.com (X.X.X.194) -> IISServer01:8082
site3.example.com (X.X.X.194) -> IISServer02:8083

Ich möchte den eingehenden SSL-Verkehr über einen Servereintrag abwickeln und dann die spezifische Domäne an die interne IIS-Anwendung weitergeben. Ich habe anscheinend zwei Möglichkeiten:

  1. Coden Sie für jede Subdomäne einen Standortabschnitt (scheint anhand der Beispiele, die ich gefunden habe, chaotisch zu sein)

  2. Leiten Sie den unverschlüsselten Datenverkehr zurück an denselben Nginx-Server, der mit unterschiedlichen Servereinträgen für jeden Subdomänen-Hostnamen konfiguriert ist. (Zumindest scheint dies eine Option zu sein).

Mein ultimatives Ziel besteht darin, einen Großteil unseres SSL-Verkehrs so zu konsolidieren, dass er über Nginx läuft, sodass wir HAProxy zum Lastenausgleich der Server verwenden können.

Funktioniert Ansatz Nr. 2 innerhalb von Nginx, wenn ich die Proxy_Set_Header-Einträge richtig einrichte?

Ich stelle mir in meiner endgültigen Konfigurationsdatei (unter Verwendung von Ansatz Nr. 2) ungefähr Folgendes vor:

server {
  listen Y.Y.Y.174:443; #Internally routed IP address
  server_name *.example.com;

  proxy_pass http://Y.Y.Y.174:8081;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site1.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer01:8081;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site2.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer01:8082;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site3.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer02:8083;
}

Das scheint eine Möglichkeit zu sein, aber ich bin nicht sicher, ob es die beste ist. Übersehe ich einen einfacheren Ansatz dafür?

Antwort1

Ich würde so etwas machen (getestet mit nginx 1.4.2, scheint zu funktionieren):

server {
  listen 127.0.0.1:443 ssl;
  server_name site1.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.2:8081;
  }
}

server {
  listen 127.0.0.1:443 ssl;
  server_name site2.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.2:8082;
  }
}

server {
  listen 127.0.0.1:443 ssl;
  server_name site3.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.3:8083;
  }
}

Mit mindestens diesem darin common.conf:

ssl on;
ssl_certificate  /path/to/cert;
ssl_certificate_key  /path/to/key;

Antwort2

Ob Sie es glauben oder nicht, Sie können Folgendes tun:

ssl_session_cache shared:SSL:2m;
ssl_session_timeout 5m;

server {
    listen Y.Y.Y.174:443 default_server ssl;
    server_name _;
    ssl_certificate /etc/pki/tls/certs/server.chained.crt;
    ssl_certificate_key /etc/pki/tls/private/server.key;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site1.example.com;
    [...]
    proxy_pass http://IISServer01:8081;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site2.example.com;
    [...]
    proxy_pass http://IISServer01:8082;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site3.example.com;
    [...]
    proxy_pass http://IISServer02:8083;
}

Keine Includes, das Zertifikat wird nur einmal in den Speicher geladen und die Sitzung sollte sogar zwischengespeichert bleiben, wenn der Benutzer von einer Subdomäne zur nächsten wechselt, was Ihnen jede Menge Handshake-Leistung erspart.

Ich kann keine Dokumentation darüber hinaus findendieser Server Fault-Beitragzu erklären, warum das funktioniert, aber ich kann Ihnen versichern, dass es funktioniert.

verwandte Informationen