☰

Nginx SSL Preread recibe esporádicamente solicitudes de las que no se extrae ningún nombre de servidor

tag-icon • tag-icon nginx amazon-s3
Nginx SSL Preread recibe esporádicamente solicitudes de las que no se extrae ningún nombre de servidor

estoy usando elmódulo de flujo nginxpara aprovechar nginx como proxy inverso tcp frente a s3. Recientemente, necesitaba agregar lógica para dar cabida a un flujo ascendente adicional. Para hacer esto, elegí usar lógica condicional a través de la variable de mapa $ssl_preread_server_name.ssl_prereadpermite a nginx extraer el nombre del servidor del mensaje ClientHello sin terminar SSL. Puedes ver la lógica a continuación:

map $ssl_preread_server_name $https_cname {
    s3.amazonaws.com https_s3_backend;
    aws-service-2.amazonaws.com aws-service-2-backend;
}
upstream https_s3_backend {
    server s3.amazonaws.com:443;
}
upstream aws_service_2_backend {
    server aws-service-2.amazonaws.com:443;
}

server {
    listen       443;
    proxy_pass $https_cname;
    ssl_preread on;
}

Cuando llega una solicitud que tiene el nombre de servidor s3.amazonaws.com, la solicitud se envía a s3. Cuando llega una solicitud que tiene el nombre de servidor aws-service-2.amazonaws.com, la solicitud se envía a aws-service-2.

Esto funciona la mayor parte del tiempo. Pero a veces hay errores en el registro de errores que indican que de alguna manera las solicitudes llegan a los servidores nginx en el puerto 443 sin ningún nombre de servidor.

[error] ... no host in upstream "", client: x.x.x.x, server: 0.0.0.0:443

Cuando agrego una declaración predeterminada en la lógica del mapa, estos errores desaparecen. ¿Cuáles son las posibles explicaciones para algunas solicitudes s3 que llegan sin que se haya extraído el nombre del servidor? La única forma en que las solicitudes podrían llegar a estos cuadros de nginx actualmente es si alguien realiza una operación s3.

Respuesta1

No estoy familiarizado con Amazon S3 como tal, pero creo que el problema es que las solicitudes se generan sin configurar el nombre del servidor (verIndicación del nombre del servidor).

Experimenté el mismo problema en una configuración similar y pude reproducirlo, por ejemplo, en OpenSSL v1.0.2p conectándome sin configurar explícitamente el parámetro servername:

openssl s_client -connect <mydomain>:<some_port> -showcerts

Esta solicitud solo me proporcionaría el certificado del servidor predeterminado y no respetaría el nombre de dominio que proporcioné en la URL. Por otro lado, al especificar el parámetro nombre del servidor:

openssl s_client -connect <mydomain>:<some_port> -showcerts -servername <mydomain>

.. la solicitud se envía al dominio correcto y se devuelve el certificado correcto.

Al acceder al mismo servidor web con curl o mediante navegadores web, no observo este problema, sospecho que la implementación en el navegador web y curl están configurando el nombre del servidor extrayéndolo de la URL en segundo plano, mientras que algunas aplicaciones del lado del cliente, como ya que openssl lo trata como un parámetro opcional.

Entonces, en tu caso, supongo que tienes que:

  • averiguar dónde se generan las solicitudes
  • ver si hay una opción para configurar el nombre del servidor

información relacionada