Назад | Перейти на главную страницу

Контейнер HAProxy Docker выполняет непрозрачную балансировку нагрузки L4

Используя последний официальный контейнер Docker HAProxy и следующий файл конфигурации:

frontend logging_frontend
    bind *:1514
    mode tcp
    timeout client 1m
    default_backend logging_backend

backend logging_backend
    mode tcp
    balance roundrobin
    timeout connect 10s
    timeout server 1m
    server logstash-collector-01 logstash-collector-01:1514 check
    server logstash-collector-02 logstash-collector-02:1514 check
    server logstash-collector-03 logstash-collector-03:1514 check

Я получаю журналы (отправленные через nxlog на 1514 по TCP), в которых хранится не фактический IP-адрес клиента, а IP-адрес шлюза Docker. Например:

2017-03-02T15: 57: 41.585Z 172.18.0.1 {"EventTime": "2017-03-01 15:25:02", "Имя хоста": "server.mycompany.net", "Ключевые слова": 58096435992, " EventType »:« ERROR »,« SeverityValue »: 4,« Severity »:« ERROR »,« EventID »: 551,« SourceName »:« Microsoft-Windows-SMBServer »,« ProviderGuid »:« {D48CE617-33A2-4BC3 -A5C7-11AA4F29619E} "," Версия ": 1," Задача ": 551," OpcodeValue ": 0," RecordNumber ": 5267740," ProcessID ": 4," ThreadID ": 5732," Channel ":" Microsoft- Windows-SMBServer / Security »,« Домен »:« NT AUTHORITY »,« AccountName »:« SYSTEM »,« UserID »:« S-1-5-184 »,« AccountType »:« Пользователь »,« Сообщение »: "Ошибка аутентификации сеанса SMB \ r \ n \ r \ nИмя клиента: \\ 10.1.1.43 \ r \ nАдрес клиента: 10.1.1.43:54118\r\nИмя пользователя: \ r \ nИдентификатор сеанса: 0xAF9FC8000015 \ r \ nСтатус: попытка входа в систему недействительна. Это связано либо с неверным именем пользователя, либо из-за неверной информации для аутентификации. (0xC000006D) \ r \ n \ r \ nРуководство: \ r \ n \ r \ nЭту ошибку следует ожидать при попытке подключиться к общим ресурсам с использованием неверных учетных данных . \ r \ n \ r \ nЭта ошибка не всегда указывает на проблему с авторизацией , но в основном аутентификация. Это чаще встречается с клиентами, отличными от Windows. \ R \ n \ r \ nЭта ошибка может возникать при использовании неправильных имен пользователей и паролей с NTLM, несоответствующих настройках LmCompatibility между клиентом и сервером, повторяющихся имен участников службы Kerberos, неправильной службы выдачи билетов Kerberos билеты или гостевые учетные записи без гостевого доступа »,« Opcode »:« Info »,« EventReceivedTime »: 1488470262,« SourceModuleName »:« eventlog »,« SourceModuleType »:« im_msvistalog »}

Обратите внимание, что сервер отчетов - 10.2.3.95, хост Docker - 10.1.38.223, а интерфейс моста Docker (и локальная подсеть контейнера) - 172.18.0.0/16 (с 172.18.0.1, зарегистрированным в журнале, являющимся шлюзом) .

Из tcpdump (измененного для отображения интерфейсов):

  1. Внешний интерфейс eno16777728 получает пакет PUSH (содержащий данные журнала) от 10.2.3.95 на IP-адрес хоста 10.1.38.223.
  2. Это заставляет DNAT от Docker перейти с 10.2.3.95 на контейнер HAProxy (172.18.0.6)
  3. HAProxy подтверждает PUSH (последний пакет снимка экрана показывает, что SNAT ответил на внешний интерфейс с использованием IP-адресов 10.x.x.x)
  4. (Не в порядке на изображении - проверьте отметки времени) HAProxy выбирает внутренний контейнер 172.18.0.3 для назначения балансировки нагрузки
  5. (Не в порядке на изображении - проверьте отметки времени) Шлюз интерфейса Docker SNAT отправляет пакет на свой виртуальный интерфейс Ethernet. (ЗАЧЕМ?)
  6. ACK от внутреннего сервера к шлюзу Docker
  7. ACK от внутреннего сервера к HAProxy (?)
  8. ACK от внутреннего сервера к HAProxy (?)

Когда я пытаюсь сделать так, чтобы HAProxy прозрачно передавал IP-адрес клиента, используя source 0.0.0.0 usesrc clientip в backend строфа, вообще ничего не регистрируется.

Для меня этот вопрос имеет два пути к успеху; либо:

или что более важно: