Lastausgleichs- und HTTPS-Strategien

7

Ich bin mit dem folgenden Problem konfrontiert: Server werden gesättigt, da die aktuelle Lastausgleichsstrategie auf der Client-IP basiert. Einige Unternehmensclients greifen hinter großen Proxys auf unsere Server zu, sodass alle Clients für unseren Load Balancer mit derselben IP-Adresse angezeigt werden. Ich denke, wir verwenden ein Hardware-Lastausgleichsgerät (kann bei Bedarf weitere Untersuchungen durchführen). Wir müssen die Sitzungsaffinität beibehalten (Site wird in ASP erstellt), damit alle Anforderungen mit derselben IP an denselben Knoten weitergeleitet werden.

Da die gesamte Kommunikation über das HTTPS erfolgt, stehen Balancer als Client-Diskriminator keine Anforderungsdaten (wie die Sitzungs-ID) zur Verfügung. Gibt es eine Möglichkeit, neben der IP-Adresse noch andere Daten zu verwenden, um zwischen Clients zu unterscheiden und die Clients weiterzuleiten, selbst wenn sie von derselben IP zu verschiedenen Knoten kommen?

Hinweis: Ich muss den Datenverkehr zwischen dem Balancer und den Knoten sicher (verschlüsselt) halten.

cluster https load-balancing

— Dan
quelle

6

Wenn Sie derzeit über einen Load Balancer verfügen, können Sie dies am einfachsten tun, indem Sie die Daten auf dem Load Balancer entschlüsseln und ein Cookie anzeigen. Zu diesem Zeitpunkt können Sie die Anforderung entweder unverschlüsselt an den Back-End-Server senden oder sie erneut verschlüsseln und weiterleiten.

Die meisten mir bekannten Setups betrachten die Netzwerkverbindung zwischen dem Load Balancer und dem Backend-Server als sicher und machen sich aus mehreren Gründen nicht die Mühe, den Datenverkehr neu zu verschlüsseln. Ein Grund dafür ist, dass hardwarebasierte Load Balancer auch als SSL-Beschleuniger fungieren. Dies ist ein weiterer Grund, warum der HTTPS-Verkehr an ihrer Tür endet. Zum anderen kann der Datenverkehr auf Angriffe überprüft werden .

— Carson
quelle

1

Verzeihen Sie meine Noobness, aber ist die Fähigkeit zum Ver- und Entschlüsseln von Daten ein Standardmerkmal von Hardware-Load-Balancern?

— Dan

Viele von ihnen scheinen es jetzt sofort zu haben, aber Ihr Kilometerstand kann variieren. Einige führen die Codierung / Decodierung in Software auf ihren Basismodellen möglicherweise mit einem Upgrade-Pfad zu einem dedizierten Hardwaremodul oder einer völlig anderen Appliance durch. Sie müssten den Anbieter bitten, dies sicher zu wissen.

— Carson

2

Hierfür gibt es drei gängige Methoden:

Zuerst können Sie Ihre Load-Balancer-Weiterleitungslogik ändern (entweder die Anzahl der Verbindungen zu jedem Host verfolgen und versuchen, die Last gleichmäßig zu verteilen, ein einfaches Round-Robin durchführen usw.). Jede der genannten Optionen beseitigt die deterministische Natur Ihres aktuellen Setups (Clients von IP X gehen nicht mehr zu Server Y), wodurch auch Ihr Problem beseitigt (oder verringert) wird.

Beachten Sie, dass Sie "Sticky Sessions" oder gleichwertige Sitzungen implementieren möchten, damit ein Client, sobald er zufällig einem Back-End-Server zugewiesen wurde, so lange zum selben Client wechselt, wie seine Verbindung aktiv ist.

Zweitens können Sie die Informationen entschlüsseln, eine Server-ID daraus lesen und sie dann weitergeben (entweder neu verschlüsseln oder im Klartext über Ihr Back-End-Netzwerk weitergeben). Beachten Sie, dass diese in großem Maßstab , es sei denn Ihr Load-Balancing - Hardware nicht wirklich praktisch ist , SSL-Beschleunigung (zB Cisco Content Switch mit SSL - Module) , da das Gerät Sie schleusen den gesamten Verkehr durch zu tun hat ALL die SSL - Arbeit.

Gemäß Anmerkung in der ursprünglichen Frage ist # 2 wahrscheinlich keine Option, da der Datenverkehr durchgehend verschlüsselt bleiben muss (klingt das Entschlüsseln auf dem Load Balancer als Richtlinienverstoß?).

Die dritte Methode, die ich nicht empfehle: Einrichten von Split-Horizon- oder Round-Robin-DNS für Ihren Zielserver (entweder direkt auf einen Back-End-Server oder auf separate IPs auf dem Load Balancer, die statisch an einen Back-End-Server gebunden sind) Ende haben unterschiedliche Ausgleichspools usw.) - Dies ist bei kleineren Vorgängen als "Ghetto-Lastausgleich" ziemlich häufig, aber in Ihrer Situation (in der Sie bereits über eine Lastausgleichsausrüstung verfügen) führt dies im Vergleich zu den anderen Lösungen zu unnötiger Komplexität .

— voretaq7
quelle

"(Clients von IP X gehen immer zu Server Y), wodurch auch Ihr Problem beseitigt (oder verringert) wird." Aber das ist genau mein Problem. Wir haben bereits ein Lastausgleichsschema eingerichtet, aber die IP-basierte Verteilung ist in unserem Fall nicht effizient. Außerdem habe ich bereits erwähnt, dass ich die Sitzungsaffinität aufrechterhalten muss ...

— Dan

Oben erläutert - Eine Last- oder Round-Robin-Verteilung bedeutet, dass Clients von IP X zu {einem Server im Pool, aber nicht immer demselben Server} wechseln.

— voretaq7

Betreff: Sitzungsaffinität, siehe Hinweis in Grau oben. Die meisten Load Balancer haben sogenannte "Sticky Sessions", die verfolgen, welche externe IP-Adresse zu welchem Back-End-Server geleitet wird, solange die Verbindung aktiv ist, und für "eine Weile" (normalerweise eine Stunde), nachdem sie inaktiv ist. Dies hält die Sitzungsaffinität ziemlich gut aufrecht.

— voretaq7

Entschuldigung, aber ich verstehe immer noch nicht, was Sie damit meinen: "Eine Last- oder Round-Robin-Verteilung bedeutet, dass Clients von IP X zu {einem Server im Pool, aber nicht immer demselben Server} gehen." Wenn ich nur IP verwende, um Clients zu identifizieren, und die Sitzungsaffinität beibehalten muss, landen alle meine Clients, die von einer bestimmten IP stammen, auf demselben Knoten ... Ich habe bereits Round-Robin eingerichtet, aber die Affinität basiert auf IP. ..

— Dan

Ich denke, openbsd.org/faq/pf/pools.html#incoming erklärt es besser als ich - Das hervorstechende Bit ist im unteren Absatz in diesem Abschnitt :)

— voretaq7

1

Die einzige Möglichkeit, das zu tun, was Sie möchten, besteht darin, SSL auf oder vor Ihrem Load Balancer zu beenden und dann den Load Balancing basierend auf der Sitzungs-ID durchzuführen. Open-Source-Lösungen für beide Schritte in einer Software sind Nginx, Haproxy, Lack und viele andere.

Einige Hardware-Load-Balancer wurden zum Ausgleich basierend auf der SSL-Sitzungs-ID verwendet, aber Browser verhandeln jetzt SSL-Sitzungen neu, sodass dies nicht mehr zuverlässig funktioniert.

— Rmalayter
quelle

Wie lange bleibt ein Browser an einer Sitzung hängen, nachdem er den ersten TLS-Austausch durchgeführt und den Sitzungsschlüssel erhalten hat?

— Pieter

Heute? Wer weiß. Fast alle Browser bevorzugen ECDHE Cipher Suites und TLS 1.2. Sie können die TLS-Sitzung jederzeit neu aushandeln. Die Client-Präferenz für Sitzungstickets macht den Lastausgleich basierend auf der SSL-Sitzungs-ID in der modernen Welt zu einem Nichtstarter. Die Sitzungs-ID kann leer sein. Siehe vincent.bernat.im/en/blog/…

— rmalayter

0

Hängt vom genauen Typ der Box ab, aber wenn Sie den Lastausgleichsdiskriminator ändern können, um ihn zu berücksichtigen, (src ip + src port)anstatt nur (src ip), wären Sie fertig. Ich weiß, dass Citrix Netscaler dies unterstützt, wahrscheinlich auch andere Geräte.

— Eric Sorenson
quelle

0

Ich weiß nicht, ob Ihr Problem behoben ist. In jedem Fall besteht eine gute Lösung darin, die Sitzungsaffinität basierend auf der SSL-ID zu verwenden.

In diesem Fall merkt sich Ihr Gerät die SSL-ID in der Speichertabelle, um Benutzeranforderungen mit derselben SSL-ID an denselben Serverknoten weiterzuleiten.

Sie müssen also weiter untersuchen, ob Ihr Lastausgleichsgerät kompatibel ist.

— user186150
quelle