haproxy отправка 400 неверных запросов по ssh connect [внешний интерфейс / бэкэнд TCP] - PullRequest
0 голосов
/ 05 января 2019

Я настроил SSH-сервер за haproxy.

haproxy настроен на обслуживание портов 80/443 в качестве балансировщика нагрузки L7. Я добавил интерфейс TCP для привязки к порту 22 для обработки и маршрутизации соединений SSH.

frontend ssh
    bind *:22
    mode tcp
    option tcplog
    use_backend back_ssh

backend back_ssh
    option tcp-check
    tcp-check expect string SSH-2.0-
    server ssh_server 172.16.2.5:1222 check

результат как ниже (400 неправильных запросов)

ssh -vvv  foo.bar.com
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/arash/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to foo.bar.com port 22.
debug1: Connection established.
debug1: identity file /Users/arash/.ssh/id_rsa type 0
debug1: identity file /Users/arash/.ssh/id_rsa-cert type -1
debug1: identity file /Users/arash/.ssh/id_dsa type -1
debug1: identity file /Users/arash/.ssh/id_dsa-cert type -1
debug1: identity file /Users/arash/.ssh/id_ecdsa type -1
debug1: identity file /Users/arash/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/arash/.ssh/id_ed25519 type -1
debug1: identity file /Users/arash/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/arash/.ssh/id_xmss type -1
debug1: identity file /Users/arash/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: ssh_exchange_identification: HTTP/1.0 400 Bad request


debug1: ssh_exchange_identification: Cache-Control: no-cache


debug1: ssh_exchange_identification: Connection: close


debug1: ssh_exchange_identification: Content-Type: text/html


debug1: ssh_exchange_identification: 


debug1: ssh_exchange_identification: <html><body><h1>400 Bad request</h1>

debug1: ssh_exchange_identification: Your browser sent an invalid request.

debug1: ssh_exchange_identification: </body></html>

ssh_exchange_identification: Connection closed by remote host

и когда я изменю конфигурацию на прослушивание вместо внешнего и внутреннего, как показано ниже, она будет работать.

listen ssh *:22
    mode tcp
    option tcplog
    option tcp-check
    tcp-check expect string SSH-2.0-
    server ssh_server 172.16.2.5:1222 check

Вопрос в том, что я что-то упустил в своей первой конфигурации и как она сломалась? Я предпочитаю, чтобы моя конфигурация была в формате внешнего интерфейса / бэкэнда в соответствии с моим соглашением.

1 Ответ

0 голосов
/ 06 января 2019

A listen foo объявление прокси по сути является сокращением для объявления frontend foo и backend foo с тем же именем (foo) и неявным default_backend foo.

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

Здесь ваша конфигурация расходится - у вас нет mode tcp - директивы, применимой как к веб-интерфейсам, так и к бэкэндам - ​​в вашей декларации прокси-сервера бэкенда. Так как TCP (балансировка уровня 4) является режимом по умолчанию, HTTP, появляющийся в вашем потоке протокола, подразумевает, что у вас также должен быть раздел defaults (не показан), который устанавливает mode http и переводит бэкэнд в режим http.

...