tcp-check ожидает двоичный ответ во втором пакете подряд - PullRequest
0 голосов
/ 02 января 2019

Я пытаюсь создать проверку TCP на моих внутренних серверах, используя HAProxy версии 1.5.8.

Поведение должно быть следующим:

  1. Отправка двоичных данных на сервер
  2. Получите ACK как первый пакет
  3. Получение данных подтверждения во втором пакете

Так что мне нужно проверить, что после отправки двоичных данных я получил ACK и после этого другие двоичные данные во втором пакете подряд.

Возможно ли это сделать с помощью HAProxy.

Я пытаюсь найти его в документации, а также пытаюсь создать различные конфигурации, но безуспешно:

option tcp-check
tcp-check connect
tcp-check send-binary 303030303030
tcp-check expect binary 303030303030

Каждый раз, когда я получал ответ от ACK сервера, соединение прерывается HAProxy, в результате чего внутренний сервер не работает.

EDIT:

Я получу следующее:

Первый пакет после отправки данных

0000   a0 66 10 09 2e 46 9c af ca bb aa 47 08 00 45 00    f...F.¯Ê»ªG..E.
0010   00 28 40 58 40 00 3e 06 d7 04 0a 1e 0b 34 0a 02   .(@X@.>.×....4..
0020   06 20 25 1c d5 80 91 0a f8 87 db 03 25 8f 50 10   . %.Õ...ø.Û.%.P.
0030   01 c9 03 d6 00 00 00 00 00 00 00 00               .É.Ö........

Второй пакет сразу после вышеперечисленного

0000   a0 66 10 09 2e 46 9c af ca bb aa 47 08 00 45 00    f...F.¯Ê»ªG..E.
0010   00 39 40 59 40 00 3e 06 d6 f2 0a 1e 0b 34 0a 02   .9@Y@.>.Öò...4..
0020   06 20 25 1c d5 80 91 0a f8 87 db 03 25 8f 50 18   . %.Õ...ø.Û.%.P.
0030   01 c9 2d 2e 00 00 00 0f 30 30 30 30 30 30 42 33   .É-.....000000B3
0040   30 30 43 48 45 43 4b                              00CHECK

Первый без каких-либо данных, и мне нужно проверить, что второй содержит 000000.

EDIT2:

PCAP предоставляется:

Нормальное поведение, когда связь идет напрямую с клиента на сервер без HAProxy Нормальное поведение - клиент-сервер

Использование HAProxy в качестве балансировщика нагрузки, подключение к тому же серверу и проверка с помощью одной и той же команды, при этом проверка не выполняется: ошибка проверки - HAProxy для сервера

Конфигурация сервера:

backend nodes
        mode tcp
        balance roundrobin
        default-server inter 10s fall 3 rise 2
        option tcp-check
        tcp-check connect
        tcp-check send-binary 303030303030423230303035434845434b
        tcp-check expect binary 000f30303030303042333030434845434b
        server server1 10.30.11.52:9500 check
        server server2 10.30.11.52:9501 check
        server server3 10.30.11.52:9502 check

1 Ответ

0 голосов
/ 02 января 2019
  1. Получить ACK как первый пакет

HA-прокси не работает на уровне необработанных пакетов, но на уровне TCP. На этом уровне нет такого понятия, как ACK как отдельный пакет. На этом уровне нет даже концепции пакета. Вместо этого существует только концепция потока данных, состоящего из принятых байтов.

Каждый раз, когда я получал ответ от ACK сервера, соединение прерывается HAProxy, в результате чего внутренний сервер не работает.

Учитывая, что прокси-сервер HA не заботится о пакетах с нулевой полезной нагрузкой, во-первых, вполне вероятно, что ваш «ACK как первый пакет» на самом деле является пакетом, который содержит ACK (как почти все пакеты TCP), но также содержит некоторые полезная нагрузка, но не та, которую вы ожидаете со «следующим пакетом». Поскольку полезная нагрузка не соответствует полезной нагрузке, которую вы указали, как и ожидалось, проверка не пройдена.

Обратите внимание, что это только предположение, основанное на неполной информации о вашем "ACK как первом пакете". Чтобы доказать это предположение, на самом деле нужно увидеть, что на самом деле происходит в сети, например, с помощью захвата пакета.

EDIT # 1:
после того, как OP предоставил некоторый (недокументированный) дамп пакетов, а некоторые выяснили, где начинается фактический заголовок IP в этих пакетах (смещение 14, то есть с префиксом заголовка Ethernet 2-го уровня), это Понятно, что первый пакет не имеет полезной нагрузки, что означает, что он полностью игнорируется проверкой. Второй пакет тогда имеет следующую полезную нагрузку 17 байтов:

0030                     00 0f 30 30 30 30 30 30 42 33         ..000000B3
0040   30 30 43 48 45 43 4b                              00CHECK

Учитывая, что OP проверяет binary 303030303030, но фактическая полезная нагрузка равна 00 0f 30 30 30 30 30 30 ...., данная tcp-check expect ... не соответствует фактической полезной нагрузке, и, следовательно, проверка не проходит.

EDIT # 2:
После того, как OP предоставил pcap соединения без и с haproxy, можно увидеть разницу в поведении клиента / haproxy и сервера:

  1. без haproxy:

    • клиент отправляет на сервер 2 байта \x00\x11, за которыми следуют 17 байтов \x30\x30....
    • сервер отвечает сразу 17 байтами \x00\x0f\x30\x30....
  2. с haproxy:

    • haproxy отправляет на сервер 17 байтов \x30\x30....
      Он не отправляет первые 2 байта \x00\x11, как это было сделано исходным сервером !!!
    • Сервер не отвечает (кроме ACK без полезной нагрузки). После 6 секунд бездействия haproxy закрывает соединение с сервером и, вероятно, считает проверку неудачной.

В итоге: я думаю, что проверка haproxy не может отправить правильный запрос на сервер, т.е. отсутствуют первые 2 байта. Вот почему сервер не будет отвечать вообще, и через некоторое время проверка не будет выполнена.

...