Как направить HTTPS-трафик через ELB в контейнер EC2, на котором работает Java JHipster webApp - PullRequest
Новая
       29

Как направить HTTPS-трафик через ELB в контейнер EC2, на котором работает Java JHipster webApp

0 голосов
/ 01 февраля 2019

У меня есть монолитное приложение JHipster (Angular + Java SpringBoot + контейнер Tomcat, все вместе), успешно развернутое в EC2.Я мог бы установить группы безопасности, чтобы разрешить 8443 входящих запросов к общедоступной DNS, и я могу получить к нему доступ из любого браузера.

После этого я запросил публичный сертификат от Amazon для домена, который яуже приобрел с Route53.

Таким образом, идея состояла в том, чтобы использовать 443 вместо 8443 и реальный домен (вместо публичного DNS, предоставленного AWS), поэтому я фактически создал ELB (все в одном VPC, группе безопасности иразмещенная зона).Этот ELB прослушивает в 443 и перенаправляет на 8443. Действие по умолчанию.

Но .. ERR_CONNECTION_REFUSED - это то, что показывает браузер ..

Важно отметить, что, поскольку AWS не позволяетчтобы загрузить сертификат (по крайней мере, я не вижу никакой опции для этого в консоли) в JDK EC2, где запускается приложение, я установил специальный сертификат (сгенерированный с помощью keytools), чтобы применить его в Tomcatдля прослушивания уже упомянутого порта 8443.

Я также попытался запустить 8080 вместо 8443 (и, конечно, обновить группы безопасности), но без изменений ..

Не могли бы вы дать мне подсказку о том, что мне не хватает?Пока что я вижу единственный способ создать новый EC2 с NGINX, который будет действовать в качестве обратного прокси-сервера (возможно, с политикой перезаписи) за ELB, но я предпочитаю избегать дополнительной сложности, если в этом нет крайней необходимости.Дополнительные данные:

  • Конфигурация сервера Tomcat: 
    server:
        port: 8443
        server.ssl.key-store: keystore.p12
        server.ssl.key-store-password: thePassword
        server.ssl.keyStoreType: PKCS12
        server.ssl.keyAlias: theKeyAlias
  • Правила входящей группы безопасности: 
    Custom TCP 8443 with 172.31.0.0/16 (the same range of the ELB)
    HTTPS TCP 443 with 0.0.0.0/0 and ::/0
  • Также сертификат AWS включен и уже выдан (набор записей CNAME создан в Route53)

** ОБНОВЛЕНИЕ 1 - 04 февраля 2019 22:21 (GMT-3) **

Ребята, я наконец решил иметь NGINX за ELB.Также я понял, что связь между NGINX и сервером приложений может быть HTTP, поэтому мое приложение будет прослушивать порт 8080, что немного упростит схему.Я также понял, что мне нужен только один сертификат для того, чтобы иметь «замок браузера» и зашифровать весь трафик между клиентами и ELB, поэтому независимо от того, если его невозможно загрузить (его также не нужно устанавливать в NGINXни сервер приложений).

Ответы [ 2 ]

0 голосов
/ 05 февраля 2019

Наконец, выпуск RESOLVED. Я мог нормально работать с NGINX, а также мне пришлось изменить другое:

Я перешел от Application Load Balancer к Classic Load Balancer.Окончательная схема, как я объяснил в ОБНОВЛЕНИИ этой темы, я имею в виду:

Пользователь подключается через HTTP или HTTPS через Classic LB, а затем переходит к прослушиванию EC2 NGINX через порт 80.

Затем из NGINX в WebApp я использовал proxy_pass следующим образом: 

    location / {
        proxy_pass  http://172.x.y.z:8080;
    }

И, наконец, HTTP-пересылка в NGINX для использования исключительно HTTPS: 

    proxy_set_header X-Forwarded-Proto $scheme;
    if ( $http_x_forwarded_proto != 'https' ) 
    {
       return 301 https://$host$request_uri;
    }

Лихо Абрахам,Ваш ответ помог мне получить четкое указание, и в этом посте показано, какое именно решение было применено (вот почему я отмечу зеленым галочкой этот пост).

Большое спасибо и всего наилучшего.

** ОБНОВЛЕНИЕ 1 -10 февраля 2019 17:21 (GMT-3) ** Наконец, я снова все переделал, используя на этот раз Application ELB вместо Classic ELB (последний устарел), и все работает как положено, не знаю, почему в начале ELB Classicне работает (возможно, ошибка в настройке правил групп безопасности или что-то в этом роде).

0 голосов
/ 04 февраля 2019

На уровне Apache вы должны добавить прослушиватель на порт 443, который бы прокси передавал запросы на порт 8443. Это гарантирует, что все входящие запросы на порт 443 домена будут переданы приложению, работающему на порту 8443сервер 

listen 443;
location /{
proxy_pass  http://127.0.0.1:8443;

}

...