Nicht-SNI-Clients aktivieren

In diesem Thema wird erläutert, wie Sie Nicht-SNI-Clients für die Verwendung mit Apigee Hybrid aktivieren.

So konfigurieren Sie einen Nicht-SNI-Client

In diesem Abschnitt wird erläutert, wie Sie die Unterstützung für Nicht-SNI-Clients (Server Name Indication) in Apigee Hybrid aktivieren.

SNI definiert, wie ein TLS-Peer (Client) den Hostnamen angibt, mit dem er während des ersten TLS-Handshake eine Verbindung herstellen möchte. SNI ist seit 2003 Teil von TLS. Vor SNI antwortete der empfangende Peer immer mit denselben Anmeldedaten, wenn ein TLS-Peer ein HELLO zum Starten des Handshake sendete. SNI wurde eingeführt, damit ein einzelner Load Balancer mehrere unterschiedliche Hostnamen und Anmeldedatensätze für die Verwaltung von TLS-Verbindungen unterstützen kann. SNI wird inzwischen von den meisten TLS-Clients verwendet.

Es gibt jedoch Ausnahmen. Der Google Cloud Load Balancer verwendet beispielsweise einen Nicht-SNI-Handshake, um eine Verbindung zu Backends herzustellen.

Wenn Sie Apigee Hybrid so konfigurieren möchten, dass TLS-Handshakes ohne SNI verarbeitet werden können, weil Ihr Apigee Hybrid ein Backend für einen Google Cloud Load Balancer ist oder weil Ihr Apigee Hybrid einen anderen Nicht-SNI-Client unterstützen muss, sollten Sie die unten beschriebenen Schritte ausführen. Die Nicht-SNI-Aushandlung dient als Fallback. Apigee Hybrid verwendet sie für alle Clients, die kein SNI verwenden.

  1. ApigeeRoute-Ressource erstellen Achten Sie darauf, dass enableNonSniClient auf true gesetzt ist: 
    apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: ROUTE_NAME
  namespace: APIGEE_NAMESPACE
spec:
  hostnames:
  - "*"
  ports:
  - number: 443
    protocol: HTTPS
    tls:
      credentialName: CREDENTIAL_NAME
      mode: SIMPLE
      #optional
      minProtocolVersion: TLS_AUTO
  selector:
    app: apigee-ingressgateway
  enableNonSniClient: true

    Dabei gilt:

    • ROUTE_NAME ist der Name, den Sie der benutzerdefinierten Ressource zuweisen.
    • CREDENTIAL_NAME ist der Name eines Kubernetes-Secrets, das auf dem Cluster bereitgestellt wird und TLS-Anmeldedaten für Ihren virtuellen Host enthält. Sie finden den Namen der Anmeldedaten mit dem folgenden kubectl-Befehl: 
      kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName
    • hostnames muss auf den Platzhalter „*“ gesetzt werden.
  2. Öffnen Sie die Überschreibungsdatei und nehmen Sie die im nächsten Schritt beschriebene Änderung vor.
  3. Fügen Sie für jede Umgebungsgruppe den Namen ApigeeRoute in das Attribut additionalGateways ein. Beispiel: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["ROUTE_NAME"]
  4. Speichern Sie die CRD-Datei. Beispiel: ApigeeRoute.yaml
  5. Wenden Sie die CRD auf den Cluster an:
    kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE
  6. Wenden Sie die Änderung auf virtualhosts an. Wenn Sie die Umgebungsvariable $ENV_GROUP in Ihrer Shell festgelegt haben, können Sie sie in den folgenden Befehlen verwenden: 
    helm upgrade $ENV_GROUP apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=$ENV_GROUP \
  -f OVERRIDES_FILE.yaml

Verwendungshinweise

  • Was passiert, wenn der Cluster mehr als eine Organisation hat?

    Da sich das Ingress auf der Clusterebene für einen bestimmten Port (443) befindet und es nur ein Schlüssel-/Zertifikatpaar für den ApigeeRoute-CRD gibt, müssen alle Organisationen dasselbe Schlüssel-/Zertifikatpaar haben.

  • Was geschieht, wenn der Cluster mehr als eine Umgebungsgruppe hat? Funktioniert die VM, wenn die virtuellen Hosts dasselbe Schlüssel-/Zertifikatpaar verwenden?

    Alle Hostnamen in allen Umgebungsgruppen müssen dasselbe Schlüssel-/Zertifikatpaar verwenden.

  • Warum erstellen wir statt eines Gateways eine ApigeeRoute?

    ApigeeRoutes können von Apigee validiert werden; das Gateway (Istio-CRD) jedoch nicht. Technisch funktioniert sogar ein Gateway, aber mögliche Konfigurationsfehler können (durch einen Validierungs-Webhook) vermieden werden.

  • Wie kann ich Nicht-SNI-Clients für Apigee konfigurieren?

    Wenn Ihre Apigee-Instanz über einen Google Load Balancer bereitgestellt wird, unterstützt der Load Balancer Nicht-SNI-Clients, wie in der Load-Balancing-Dokumentation beschrieben. Wenn Sie eine Apigee-Instanz über einen internen PSC-Endpunkt oder ein VPC-Netzwerk bereitgestellt haben, unterstützt die Apigee-Instanz standardmäßig Nicht-SNI-Clients.