HAproxy как прокси сервер к LDAP

тут ldaps на порту 4343 сидит? И работает?

• При запросе напрямую, с приложения, работает. Да, на 4343

Коннект к ldap - я проверял на другом сервере. Меня интересовала именно работоспособность прокси

Сам HAproxy обитает в кубере. И оттуда, должны летель запросы

Коннект к ldap - я проверял на другом сервере.

Шютник

А нет необходимости, дополнительно настраивать ssl/tls?

Нет. При работе на транспортном уровне (l4) haproxy тупо поднимает новое соединение к бекенду и пересылает все данные в него. Ничего в них не меняя

Кстати. ldap может работать как с tcp, так и с udp. udp по понятным причинам не будет работать через haproxy. И тем более не будет нормально работать с кубером

Убедись, что ldap клиент использует именно tcp

как ты умудряешь говорить и запутывать одновременно?

ldap и ldaps это разные вещи! Последнему нужно подкгружать сертификат и ключ. Тебя сотый раз спрашивают, у тебя ldaps где-то уже работает или нет? Потому что в haproxy никаких следов сертификатов не видно.

Другими словами у тебя сертификаты на haproxy должны быть или в самом сервере ldap?

haproxy:636 -> ldap:389

или

haproxy:535 -> ldaps:636

?

В первом случае погружай сертификаты в haproxy, а во втором, настраивай сам openldap на работу через ldaps

Сейчас это работает так: application –> ldaps://ldap-host:4343

Необходимо сделать, чтобы было следующее: application –> haproxy-host:4343 -> ldaps://ldap-host:4343

Судя по всему, у меня первый вариант. Мне нужны сертификаты

Сможете подсказать или дать ссылку на эту настройку? У меня нет доступа к самому LDAP серверу

да нет, вариант номер 2.

Сертификаты уже загружены в ldap-host и все там работает.

application –> ldaps://ldap-host:4343

на текущий момент должен работать ldapsearch ldaps://ldap-host:4343

Сертификаты только переделать и перезалить, добавив в cn haproxy-host и все с ними.

вместо haproxy можно просто добавить dnat c haproxy-host на ldap-host

ну или на haproxy минимальный tcp proxy настроить.

Проблема в том, что haproxy работает в kubernetes. Какой же тогда cn haproxy-host надо добавлять в сертификаты?

TCP прокси настроен так:

frontend front
bind *:4343
option tcplog
mode tcp
default_backend web

backend web
mode tcp
server ldap host:4343 check

mochkass88 (07.02.2023 16:48:15 +02:00)

В сертификате прописан cn, это хост, по которому отвечает сервер.

Посмотри наверх, там написано https://www.linux.org.ru а в сертификате прописано грубо говоря CN=linux.org.ru и CN=www.linux.org.ru

Вот по этим именам он валидный. Вот и у тебя там должен быть хост ldap и хост haproxy

Чот вы все куда-то не туда полезли. Ошибка приложения «Unsupported or unrecognized SSL message», это никак не ругань на сертификат.
Я продолжаю верить в то, что указан неправильный бэкенд, потому что читать ответы ТСа довольно тяжело, на телепатию расходуется слишком много маны.
Нужно хмуро смотреть, что летит с порта haproxy. Сниффером, openssl s_client'ом, как угодно.

Сорри, за невнятные ответы. Сам плаваю в этой теме. Сейчас я заменил образ haproxy на официальный и получил ошибку «Connection refused»

Кто ругается, приложение? Ну перепроверяй конфик прокси и фаерволл.

Теперь имею такую проблему(

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.ldap.CommunicationException: simple bind failed: haproxy.test:6363] with root cause java.security.cert.CertificateException: No subject alternative DNS name matching haproxy.test found.

No subject alternative DNS name matching haproxy.test found.
Ты подключаешься к хосту haproxy.test, а он предъявляет сертификат, в котором нет этого имени. Конечно, заругается.

Тоесть, он стягивает сертификат с ЛДАП сервера, в котором отсутствует это имя? Я правильно понял?

освой куб и вытащи ldap наружу через servicetype=LoadBalancer

HAProxy находится в кубере. LDAP - сервешенно сторонняя VM. Находится в другой сети и другом ДЦ. С LDAP никаких манипуляций проводить не смогу

а, понял. тогда отключай проверку сертов клиентам, которые подключаются к ldaps

Тоесть, эта проблема генерится на самом LDAP? Ибо, если Java ходит напрямую - всё отрабатывает красиво

Да, поле subjectAltName.