Tráfego TCP na porta 1433 bloqueada pelas regras NAT

Question

Temos um servidor SQL hospedado na AWS, o servidor SQL não está diretamente acessível na Internet, ele depende de uma caixa NAT para rotear o tráfego para ele.

Estamos tentando configurar um servidor SQL vinculado desse servidor para outro fora da AWS. Isso exige que os dois servidores SQL conversem entre si na porta 1433 TCP.

As seções relevantes do iptable são assim:

target prot source destination

DNAT udp anywhere anywhere udp dpt:ms-sql-m to:172.10.10.10:1434

DNAT tcp anywhere anywhere tcp dpt:ms-sql-s to:172.10.10.10:1433

A partir de nossos próprios testes, sabemos que podemos vincular qualquer servidor ao da AWS, mas não o contrário.

Alguma coisa parece errada? O problema começou a ocorrer quando o nosso engenheiro da intfra removeu e adicionou as mesmas regras. Há alguma pista sobre isso? A ordem é válida?

Ao usar o tracetcp , encontramos o seguinte:

Fazendo este comando no servidor aws sql 'tracetcp.exe 183.23.53.22 1433' onde o ip é aquele do outro servidor hospedado externamente, ele chegaria ao destino em 1 salto, mas também faria o mesmo de qualquer endereço IP aleatório que tentamos.

Onde,comosefizéssemosomesmocomando,masemoutraportadiferentede1433,eleatingiaacaixaNATprimeiroedepoisfaziamuitossaltos

    

Answer 1

Verifique suas regras do iptables com iptables-save e publique-as novamente. Verifique se suas regras DNAT têm algum método de excluir tráfego originado de dentro da rede, por exemplo, -i <extif> , ! -i <intif> ou ! -s 172.10.10.10 . Eu suspeito strongmente que ele está reenviando seus pacotes de volta para o servidor de origem interno.

    

Answer 2

Pode ser que você tenha um proxy em execução na porta 1433, que pode causar um comportamento como o descrito. O proxy aceita a conexão com a máquina interna imediatamente e é por isso que você obtém uma resposta tão rápida de 2ms.

Além disso, um bom indicador de que seus pacotes não saíram da sua LAN é um tempo de resposta tão curto (1-4 ms). Tente verificar na sua caixa NAT se você acidentalmente iniciou qualquer processo de proxy e se não, tente desabilitar a regra DNAT para a porta 1433 (tcp) para ver se o problema persiste.

Além disso, esta declaração "não diretamente acessível na internet, depende de uma caixa NAT para encaminhar o tráfego para ela" é contraditória, já que a máquina está acessível na internet, mas em uma porta específica, através da qual a tradução NAT está sendo feito, certo?

Se você realmente quer proteger seu serviço do mundo externo, talvez seja uma boa idéia considerar algum tipo de VPN, talvez? Ou se você quiser uma solução mais simples (mas não tão segura quanto VPN), você pode permitir o acesso a essa porta NAT a partir do endereço IP remoto conhecido (o qual os invasores podem falsificar em alguns casos).