Как поддерживать HTTP, а затем TCP в том же сокете с http-туннелем в прокси-сервере HA - PullRequest
Новая
       142

Как поддерживать HTTP, а затем TCP в том же сокете с http-туннелем в прокси-сервере HA

2 голосов
/ 11 июля 2020

У меня очень специфическая c бизнес-потребность, которая требует, чтобы встроенное устройство выполняло начальный HTTP-запрос и получало HTTP-ответ через HA Proxy перед набором настраиваемых внутренних серверов. Затем на том же сокете, который он установил через прокси-сервер HA, обменивайтесь данными по пользовательскому протоколу TCP до конца срока службы сокета (который обычно длится несколько дней).

Сначала я подумал, что Параметр -tunnel на прокси-сервере HA идеально подходит для этого, хотя он устарел. В частности, в нем говорится: 

Option "http-tunnel" disables any HTTP processing past the first request and
the first response. This is the mode which was used by default in versions
1.0 to 1.5-dev21. It is the mode with the lowest processing overhead, which
is normally not needed anymore unless in very specific cases such as when
using an in-house protocol that looks like HTTP but is not compatible, or
just to log one request per client in order to reduce log size. Note that
everything which works at the HTTP level, including header parsing/addition,
cookie processing or content switching will only work for the first request
and will be ignored after the first response.

Итак, я попытался настроить свой прокси-сервер высокой доступности для использования режима http-туннеля. Вот упрощенная конфигурация, которую я пробовал: 

frontend _front_http
    mode http
    bind :80
    option httplog
    option http-tunnel
    use_backend default_sleep-server_8080
    default_backend _error404

backend default_sleep-server_8080
    mode http
    option forwardfor
    option http-tunnel
    http-response set-header Strict-Transport-Security "max-age=15768000"
    server srv001 10.244.0.80:8080 weight 1 check inter 2s
    server srv002 10.244.0.81:8080 weight 1 check inter 2s
    server srv003 10.244.0.82:8080 weight 1 check inter 2s

defaults
    log global
    maxconn 2000
    option redispatch
    option dontlognull
    option http-server-close
    option http-keep-alive
    timeout client          50s
    timeout client-fin      50s
    timeout connect         5s
    timeout http-keep-alive 1m
    timeout http-request    5s
    timeout queue           5s
    timeout server          50s
    timeout server-fin      50s
    timeout tunnel          1h
    no option http-server-close

Я также играл с включенным только http-tunnel для интерфейса или для серверной части.

Любой метод, который я пробовал, я встречал та же проблема. Первоначальный HTTP-запрос / ответ работает так, как задумано (т. Е. Попадает в интерфейс HA Proxy, перенаправляется на бэкэнд, бэкэнд формирует ответ, который отправляется клиенту, сокет остается открытым). Но для последующих пакетов, которые мой клиент отправляет через существующий сокет, эти пакеты go непосредственно на HTTP-сервер, но никогда не пересылаются на внутренний сервер. Я проверил это с помощью TCP Dump - все, что я вижу, - это TCP-пакеты, попадающие на внешний порт, никогда не было никакого ответа, отправленного обратно клиенту, или пересылки этих пакетов в другое место.

Что-то не так с моим http установка туннеля? Или я здесь совершенно не то использую? Я знаю, что, вероятно, есть другие инструменты, которые могут достичь этого лучше, но для целей, связанных с доменом c, было бы здорово иметь возможность использовать прокси HA.

1 Ответ

0 голосов
/ 19 июля 2020

Из ссылки на документацию 

Warning : Because it cannot work in HTTP/2, this option is deprecated and it
is only supported on legacy HTTP frontends. In HTX, it is ignored and a
warning is emitted during HAProxy startup.

Я бы попытался установить no option http-use-htx во внешнем интерфейсе.

Как указано в тексте выше, эта опция устарела, что означает с 2.1 и выше не существует этой опции, AFAIK.

...