Доброго дня,
Имеется следующая схемка и её реализация:
GOST-proxy-tunnel.png
(79kb) загружен 46 раз(а).В сети 1 расположено веб-приложение с nginx и КриптоПРО собранный по инструкции на сайте, между сетями создан аппаратный тоннель IPSec, в сети 2 находится приложение-клиент, которое не умеет в ГОСТ, поэтому там же расположен реверс-прокси на кастомной сборке nginx 1.16.1 + openssl 1.1.0k + референс gost (https://github.com/gost-engine/), предполагается работа с односторонней аутентификацией TLS (Одно из требований - шифрование данных при передаче через протокол ГОСТ).
Конфигурация реверс прокси:
Цитата:user root;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 8088;
location / {
proxy_pass
https://172.16.0.95:444;
proxy_ssl_verify off;
proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH;
proxy_ssl_protocols TLSv1.2;
# Если предполагается двухсторонний TLS, то нужно указать клиентский сертификат и приватный ключ параметрами proxy_ssl_certificate и proxy_ssl_certificate_key соответственно
# proxy_ssl_certificate /etc/nginx/_CERT_.pem;
# proxy_ssl_certificate_key engine:gostengy:_CERT_;
}
}
}
При обращении от клиента к серверу в сети 2 через реверс прокси - регулярно проскакивает 502 ошибка:
bash# for i in {1..5}; do echo $(curl
http://nginx-gost-service.ahml:8088 -sI | grep HTTP); sleep 1; done
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 502 Bad Gateway
HTTP/1.1 502 Bad Gateway
HTTP/1.1 502 Bad Gateway
bash# for i in {1..5}; do echo $(curl
http://nginx-gost-service.ahml:8088 -sI | grep HTTP); sleep 1; done
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 502 Bad Gateway
, где nginx-gost-service.ahml:8088 ведет в реверс прокси
В это время в логах nginx (реверс прокси):
172.30.43.1 - - [27/Aug/2019:13:51:53 +0300] "HEAD / HTTP/1.1" 502 0 "-" "curl/7.29.0"
172.30.43.1 - - [27/Aug/2019:13:51:59 +0300] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0"
172.30.43.1 - - [27/Aug/2019:13:52:00 +0300] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0"
172.30.43.1 - - [27/Aug/2019:13:52:01 +0300] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0"
2019/08/27 13:52:02 [error] 7#7: *157 peer closed connection in SSL handshake while SSL handshaking to upstream, client: 172.30.43.1, server: , request: "HEAD / HTTP/1.1", upstream: "https://172.16.0.95:444/", host: "nginx-gost-service.ahml:8088"
172.30.43.1 - - [27/Aug/2019:13:52:02 +0300] "HEAD / HTTP/1.1" 502 0 "-" "curl/7.29.0"
2019/08/27 13:52:03 [error] 7#7: *159 peer closed connection in SSL handshake while SSL handshaking to upstream, client: 172.30.43.1, server: , request: "HEAD / HTTP/1.1", upstream: "https://172.16.0.95:444/", host: "nginx-gost-service.ahml:8088"
172.30.43.1 - - [27/Aug/2019:13:52:03 +0300] "HEAD / HTTP/1.1" 502 0 "-" "curl/7.29.0"
В логах целевого сервера:
[info] 14762#14762: *1667418 peer closed connection in SSL handshake while SSL handshaking, client: 10.3.50.219, server: 0.0.0.0:10443
[info] 14764#14764: *1667430 peer closed connection in SSL handshake while SSL handshaking, client: 10.3.50.219, server: 0.0.0.0:10443
Неудачно обвинив в данной проблемы HTTPS-inspection на внутрисетевых файрволах пришлость заняться снятием дампов пакетов, где и обнаружилось что на пакет клиента с ClientHello
целевой сервер не отвечает, а разрывает соединение:
Capture.PNG
(125kb) загружен 17 раз(а).Protocol TLSv1 указанный на картинке в ClientHello - "глюк" Wireshark, заголовки в Hello пакетах идентичны с TLSv1.2,за исключением таймстампов, просто нет поддтверждения о выбранном ТЛС от сервера
Вариант с реверс прокси рабочий, по крайней мере при запросах на сайт
https://www.cryptopro.ru по ГОСТ2012 проблем не возникает
Собственно вопросы:
Что делать?
Кто нибудь сталкивался с подобным поведением/проблемой?
Как-нибудь можно отдебажить проблему со стороны КриптоПРО CSP ?
Буду признателен за любую помощь с этой проблемой
UPD:
Проблема появилась после перехода на ГОСТ2012 в сети 1,
на ГОСТ2001 проблемы не наблюдалось.
Отредактировано пользователем 28 августа 2019 г. 12:35:51(UTC)
| Причина: Не указана