it-swarm.com.de

Leiten Sie alle http-Anforderungen hinter Amazon ELB an https um, ohne if zu verwenden

Derzeit habe ich eine ELB, die sowohl http://www.example.org als auch https://www.example.org bedient.

Ich möchte es so einrichten, dass jede Anfrage, die auf http://www.example.org verweist, auf https://www.example.org umgeleitet wird.

Die ELB sendet die https-Anforderungen als http-Anforderungen. Verwenden Sie dazu:

server {
      listen         80;
       server_name    www.example.org;
       rewrite        ^ https://$server_name$request_uri? permanent;
}

funktioniert nicht, da Anfragen an https://www.example.org weiterhin an Port 80 auf nginx gesendet werden.

Ich weiß, dass es möglich ist, es umzuschreiben als

server {
      listen         80;
      server_name    www.example.org;
      if ($http_x_forwarded_proto != "https") {
          rewrite ^(.*)$ https://$server_name$1 permanent;
      }
}

Aber alles, was ich gelesen habe, besagte, dass if innerhalb der Nginx-Konfiguration um jeden Preis vermieden werden sollte, und dies wäre für jede einzelne Anfrage. Dies bedeutet auch, dass ich eine spezielle separate Konfiguration für die Integritätsprüfung einrichten muss ( wie hier beschrieben : "... wenn Sie sich hinter einer ELB befinden, bei der die ELB als HTTPS-Endpunkt fungiert und nur sendet Wenn Sie HTTP-Datenverkehr zu Ihrem Server durchführen, können Sie nicht mehr mit einer HTTP 200 OK-Antwort auf die von der ELB benötigte Integritätsprüfung antworten.

Ich denke darüber nach, das Login in den Code der Webanwendung und nicht in die Nginx-Konfiguration einzufügen (und für die Zwecke dieser Frage nehmen wir an, dass es sich um eine Django-basierte Anwendung handelt), bin mir aber nicht sicher, ob dies mehr Aufwand bedeuten würde als das if in der Konfiguration.

27
Jordan Reiter

Wenn es so richtig funktioniert, haben Sie keine Angst davor. http://wiki.nginx.org/IfIsEvil

Es ist wichtig zu beachten, dass das Verhalten von if nicht inkonsistent ist, da es bei zwei identischen Anforderungen nicht zufällig bei einem fehlschlägt und bei dem anderen funktioniert, mit angemessenem Testen und Verstehen, ob ifs verwendet werden können. Der Rat, andere Richtlinien zu verwenden, sofern verfügbar, gilt jedoch nach wie vor sehr.

9
ceejayoz
  1. Richten Sie Ihre AWS ELB-Zuordnung ELB: 80 zu Instanz: 80 und ELB: 443 zu Instanz: 1443 ein.
  2. Binden Sie Nginx, um Port 80 und 1443 abzuhören.
  3. Leiten Sie an Port 80 ankommende Anforderungen an Port 443 weiter.
  4. Der Gesundheitscheck sollte HTTP: 1443 sein. HTTP: 80 wird abgelehnt, da die 301-Umleitung erfolgt.

aws elb setup

NGINX-Setup

    server {
       listen         80;
       server_name    www.example.org;
       rewrite        ^ https://$server_name$request_uri? permanent;
    }

    server {
       listen         1443;
       server_name    www.example.org;
   } 
15
nu everest

Diese Lösung verwendet bedingte Logik, aber wie die akzeptierte Antwort nahelegt, denke ich auch, dass dies in Ordnung ist. Ref: https://stackoverflow.com/questions/4833238/nginx-conf-redirect-multiple-conditions

Außerdem müssen hierfür keine zusätzlichen Ports in den aws-Sicherheitseinstellungen für das Image geöffnet werden. Sie können ssl in der AWS LB beenden und den https-Verkehr an den http-Port 80 Ihrer Instanz weiterleiten.

In diesem Beispiel trifft der LB-Health-Check/Health auf Port 80, der an den App-Server weitergeleitet wird. Der Health-Check überprüft also, ob sowohl Nginx als auch Ihre App atmen.

server {
  listen 80 default deferred;

  set $redirect_to_https 0;
  if ($http_x_forwarded_proto != 'https') {
    set $redirect_to_https 1;
  }
  if ($request_uri = '/health') {
    set $redirect_to_https 0;
  }
  if ($redirect_to_https = 1) {
    rewrite ^ https://www.example.com$request_uri? permanent;
  }
  ...
}
9
Jonny Mac

Sie können jetzt in den AWS Load Balancer-Einstellungen einen neuen Listener erstellen, der HTTP-Port 80 zu HTTPS-Port 443 umleitet. Sie müssen also die nginx/Apache-Konfiguration nicht mehr berühren.

0
Kenny Greulich