Desculpe se o título e as tags são um pouco vagos, não consegui descobrir os termos corretos para isso, ainda. Por favor avise, e eu vou mudar isso.
Estou implementando um servidor STUN, encaixado em um contêiner do Docker, hospedado no Kubernetes do Google Container Engine. O projeto utiliza balanceadores de carga (regras de encaminhamento no GCE) para enviar solicitações externas para as portas apropriadas no pod / container,
Eu roteei todo o tráfego entrando em eth0 para 2 interfaces virtuais (eth0: 1, eth0: 2) por meio de:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 61214 -j DNAT --to-destination 172.26.0.6
(por completo, o segundo destino é 172.26.0.7)
Um aplicativo cliente alcança muito bem, e assim a determinação NAT continua. Isso, no entanto, é interrompido quando o servidor STUN precisa criar um soquete e vinculá-lo ao aplicativo cliente, pois o IP de origem é o IP interno da instância da VM no Kubernetes (por exemplo, 10.128.0.4). Como nenhuma conexão foi feita, os soquetes do cliente e do servidor atingem o tempo limite.
Existe alguma maneira de preservar o endereço de origem real até chegar ao meu aplicativo de servidor? Estou aberto a desmantelar a configuração atual, desde que minha solicitação atinja o servidor e o servidor consiga estabelecer a conexão de retorno com o cliente.
Obrigado.
Fico feliz em descobrir que esse é um daqueles casos incomuns em nossa linha de trabalho em que a solução existe , e foi fornecida em tempo hábil (ou seja, apenas virou beta).
Infelizmente, isso é específico do nosso contexto, ou seja, do Kubernetes sobre o GCE / GKE. Usuários de outras plataformas (por exemplo, AWS) precisarão empregar outras soluções, a partir do momento em que escrevo.