CloudFront, балансировщик нагрузки приложений, EC2 получает перенаправление 301

#amazon-web-services #nginx #amazon-ec2 #amazon-cloudfront #aws-application-load-balancer

#amazon-веб-сервисы #nginx #amazon-ec2 #amazon-cloudfront #aws-application-load-balancer

Вопрос:

У меня возникла проблема с CloudFront, который я пытаюсь добавить в существующую структуру не для получения преимуществ кэширования, а исключительно для защиты. Серверная часть имеет php-файлы, которые обращаются к базе данных и передают ответы json вызывающим абонентам. Таким образом, серверная часть обеспечивает 100% динамическое содержимое. (нет статического содержимого)

Что работает прямо сейчас, так это

Application Load Balancer (HTTP:80 redirect -> HTTPS:443, HTTPS:443) with its own ACM public cert -> EC2 (nginx, HTTP:80)

Я сопоставил DNS-имя балансировщика нагрузки с пользовательским именем и зарегистрировался на маршруте 53. И я могу получить доступ к своим файлам php без каких-либо проблем.

Что не работает, так это

CloudFront (HTTP:80 -> HTTPS:443) -> Application Load Balancer(same config) -> EC2(same config)

Настройки CloudFront

 Custom DNS.
AWS public SSL in (N. Virginia) Region.
HTTP -> HTTPS redirect.
Cache Policy is set to Managed-CachingDisabled.
Origin Request Policy is set to Manager-AllViewer.
 

Настройки балансировщика нагрузки приложений

 Located in us-west-2 region.
Availability Zone us-west-2b, us-west-2d
Redirect HTTP -> HTTPS
HTTPS -> Forward to Target group (HTTP:80)
ELBSecurityPolicy-TLS-1-2-2017-01
 

Настройки экземпляра EC2

 Located in us-west-2 region.
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com;
    server_tokens off;
    root /home/forge/example.com/public;

    # FORGE SSL (DO NOT REMOVE!)
    # ssl_certificate;
    # ssl_certificate_key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS_AES_256_GCM_SHA384:TLS-AES-256-GCM-SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparams.pem;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    # FORGE CONFIG (DO NOT REMOVE!)
    include forge-conf/example.com/server/*;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
        proxy_pass         http://localhost:8000;
        proxy_set_header   Host                 $host;
        proxy_set_header   X-Forwarded-HTTPS    on;
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
        proxy_redirect off;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/example.com-error.log error;

    error_page 404 /index.php;

    location ~ .php$ {
        fastcgi_split_path_info ^(. .php)(/. )$;
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /.(?!well-known).* {
        deny all;
    }
}
 

Результатом является код ответа 301.

 * Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0xe20900)
} [5 bytes data]
> GET /index.php HTTP/2
> user-agent: curl/7.67.0
> accept: */*
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
} [5 bytes data]
< HTTP/2 301
< content-type: application/xml
< content-length: 0
< date: Sat, 09 Jan 2021 10:34:01 GMT
< server: AmazonS3
< location: /index.php/
< x-cache: Miss from cloudfront
< via: 1.1 e61b74b41588d9216f1bb35848394554.cloudfront.net (CloudFront)
< x-amz-cf-pop: SFO20-C1
< x-amz-cf-id: krUsSzIvjDtNANyPun9uipkHOhRQ70HfUgo4yXDqgzwK953hkcJO_g==
<
{ [0 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host example.com left intact
 

В приведенном выше выводе curl я вижу server: AmazonS3 , но я не использую сегменты S3. Не уверен, что это просто имя сервера.

Любые советы будут оценены.

Комментарии:

1. Какие домены (достаточно примера) и ssl-сертификаты установлены для ALB и CF. Используете ли вы один и тот же домен и ssl как для ALB, так и для CF?

2. Я использую другой домен и SSL. ALB: alb.myserver.com (Сертификат SSL: alb.myserver.com ) CF: api.myserver.com (Сертификат SSL: api.myserver.com )

Ответ №1:

Оказалось, что у меня было приложение amplify, созданное по ошибке в регионе Огайо некоторое время назад с использованием того же доменного имени. Я понятия не имел, что такое приложение работает за сценой в разных регионах, пока не связался со службой поддержки. Изменил регион в правом верхнем углу, и он, наконец, появился. Я бы хотел, чтобы у них была панель мониторинга, которая показывает все приложения и экземпляры, работающие под одной учетной записью, чтобы упростить обнаружение и управление. Пройдя по каждому региону один за другим, я заметил, что у меня также запущены некоторые неиспользуемые ресурсы, которые я, должно быть, создал, пытаясь изучить AWS некоторое время назад.

Итак, не зная, что это приложение Amplify зарезервировало доменное имя, которое я пытался использовать, поле CNAMEs в настройках CloudFront вызывало исключение, когда я вводил домен. Пытаясь обойти проблему, я добавил CNAME маршрута 53 для принудительного использования доменного имени, которое вызвало перенаправление.

Удалил приложение, удалил запись CNAME маршрута 53, добавил домен в поле CNAMEs в CloudFront, после этого все прошло гладко.