Contêiner do Docker HAProxy que faz o balanceamento de carga L4 não sendo transparente

Question

Usando o contêiner mais recente do HAProxy Docker oficial e o seguinte arquivo de configuração:

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

Estou recebendo logs (enviados via nxlog para 1514 sobre TCP) que não armazenam o IP do cliente real, mas sim o IP do gateway do Docker. Por exemplo:

2017-03-02T15:57:41.585Z 172.18.0.1 {"EventTime":"2017-03-01 15:25:02","Hostname":"server.mycompany.net","Keywords":58096435992,"EventType":"ERROR","SeverityValue":4,"Severity":"ERROR","EventID":551,"SourceName":"Microsoft-Windows-SMBServer","ProviderGuid":"{D48CE617-33A2-4BC3-A5C7-11AA4F29619E}","Version":1,"Task":551,"OpcodeValue":0,"RecordNumber":5267740,"ProcessID":4,"ThreadID":5732,"Channel":"Microsoft-Windows-SMBServer/Security","Domain":"NT AUTHORITY","AccountName":"SYSTEM","UserID":"S-1-5-184","AccountType":"User","Message":"SMB Session Authentication Failure\r\n\r\nClient Name: \10.1.1.43\r\nClient Address: 10.1.1.43:54118\r\nUser Name: \r\nSession ID: 0xAF9FC8000015\r\nStatus: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xC000006D)\r\n\r\nGuidance:\r\n\r\nYou should expect this error when attempting to connect to shares using incorrect credentials.\r\n\r\nThis error does not always indicate a problem with authorization, but mainly authentication. It is more common with non-Windows clients.\r\n\r\nThis error can occur when using incorrect usernames and passwords with NTLM, mismatched LmCompatibility settings between client and server, duplicate Kerberos service principal names, incorrect Kerberos ticket-granting service tickets, or Guest accounts without Guest access enabled","Opcode":"Info","EventReceivedTime":1488470262,"SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}

Observe que o servidor de relatórios é 10.2.3.95, o host do Docker é 10.1.38.223 e a interface de ponte do Docker (e sub-rede do contêiner local) é 172.18.0.0/16 (com 172.18.0.1, registrada no log, sendo o gateway).

De um tcpdump (modificado para mostrar interfaces):

1. A interface externa, eno16777728, obtém um pacote PUSH (contendo dados de log) de 10.2.3.95 para o IP do host 10.1.38.223
2. Isso leva o DNAT'd do Docker a ir de 10.2.3.95 para o contêiner HAProxy (172.18.0.6)
3. O HAProxy reconhece o PUSH (o último pacote de captura de tela mostra a resposta SNAT na interface externa usando IPs 10.x.x.x)
4. (fora de ordem na imagem - verificar registros de data e hora) HAProxy decide sobre o contêiner de backend 172.18.0.3 para o destino de balanceamento de carga
5. (Fora de ordem na imagem - verificar registros de data e hora) O gateway de interface do Docker SNATs o pacote em sua interface de ethernet virtual (POR QUÊ?)
6. ACK do servidor de back-end para o gateway do Docker
7. ACK do servidor de back-end para o HAProxy (?)
8. ACK do servidor de back-end para o HAProxy (?)

Quando tento fazer com que o HAProxy passe o IP do cliente de forma transparente usando source 0.0.0.0 usesrc clientip na sub-rotina backend , nada é registrado em log.

Para mim, esta questão tem dois caminhos para o sucesso; ou:

• Como o comportamento de registrar o IP do gateway do Docker pode ser explicado?

ou mais importante:

• Como posso obter o IP do cliente original nesses registros, preferencialmente como o campo IP do cliente (no início do registro de data e hora do registro)?