Назад | Перейти на главную страницу

Glassfish JK SSL Listener 502 Плохой шлюз

Я настроил очень простую конфигурацию кластера Apache + Glassfish.

Он отлично работает, если я создаю и использую прослушиватель, который использует http-listener-1 по умолчанию.

Однако, если я переключаюсь на безопасный прослушиватель, который использует http-listener-2, то соединение устанавливается, но затем оно сбрасывается, и пользователь получает ошибку 502 Bad Gateway, и у меня есть это сообщение в mod_jk.log

[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (674): socket TCP_NODELAY set to On
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (711): socket SO_KEEPALIVE set to On
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (763): timeout 300 set for socket=16
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (798): trying to connect socket 16 to 10.0.10.4:28010
[Wed Dec 04 16:17:55.906 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (824): socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010] connected

other log entries in between....

[Wed Dec 04 16:17:55.907 2019] [6957:139970911750336] [debug] ajp_send_request::jk_ajp_common.c (1779): (worker1) request body to send 0 - request body to resend 0
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [debug] jk_shutdown_socket::jk_connect.c (931): About to shutdown socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010]
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [debug] jk_is_input_event::jk_connect.c (1410): error event during poll on socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010] (event=16)
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [debug] jk_shutdown_socket::jk_connect.c (1015): Shutdown socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010] and read 0 lingering bytes in 0 sec.
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [info] ajp_connection_tcp_get_message::jk_ajp_common.c (1339): (worker1) can't receive the response header message from tomcat, tomcat (10.0.10.4:28010) has forced a connection close for socket 16

Конфигурация вполне стандартная, с той лишь разницей, что я использую личный сертификат, созданный моим внутренним центром сертификации. Сертификат был успешно добавлен в хранилище ключей, и если я обращаюсь к веб-приложению напрямую через порт 8181, оно работает (с некоторым предупреждением), и я могу проверить свой сертификат.

Вот часть https.conf

  # Sample app
  JkMount /sample loadbalancer
  JkMount /sample/* loadbalancer

the worker.properties

worker.list=worker1,loadbalancer

# default properties for workers
worker.template.type=ajp13
worker.template.port=28010
worker.template.lbfactor=50
worker.template.connection_pool_timeout=600
worker.template.socket_keepalive=1
worker.template.socket_timeout=300

# properties for worker1
worker.worker1.reference=worker.template
worker.worker1.host=myhost.com

# properties for loadbalancer
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1

Здесь разъем jk на Glassfish, как вы видите, он подключен к порту 28010, который я убедился, что он открыт.

Потратив некоторое время на изучение этой проблемы и чтение документов, я пришел к выводу, что JK не работает с TLS. Флаг безопасности применяется только к прослушивателю http.

Один из возможных вариантов работы, который я экспериментировал, - открыть туннель между HTTPD и экземплярами Glassfish. Это легко, но может иметь и обратную сторону. Самое главное, что SSH-соединение может оборваться. В этом случае можно также создать службу, перезапускающую туннель, но это было вне моих знаний (и времени).

Поскольку сеть, в которой находятся экземпляры, уже хорошо защищена, я закончил тем, что общался с JK через небезопасное соединение.