Não é possível conectar-se ao servidor ipsec em execução no Docker por trás do firewall

2

Eu tenho uma configuração que eu não acho que é muito difícil, mas não consigo fazê-lo funcionar.

Configuração de trabalho : Um servidor ipsec em execução em uma janela de encaixe conectado diretamente à internet. Os clientes podem se conectar.

Não está funcionando a configuração : Um servidor ipsec em execução em uma janela de encaixe conectada à internet por trás de um firewall. Eu tenho node1 em um servidor esxi que atua como internet gateway e node2 em execução no mesmo servidor esxi que possui ipsec server running in a docker .

Eu abri as portas 500 e 4500 no nó 1 (gateway da Internet) e as enviei para o nó 2 (executando o servidor ipsec em uma janela de encaixe). A questão que estou enfrentando é que os clientes não conseguem se conectar.

Abaixo está a regra de firewall do iptables

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

Não é possível identificar o que mais está faltando. Alguém pode me avisar se minha configuração está correta e porque não está funcionando?

    
por BTR Naidu 09.11.2018 / 12:30

1 resposta

3

Suas regras do iptables a partir dos comentários da pergunta:

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

Eu realmente não vejo por que você precisa da porta 53 encaminhada: fazer com que o servidor DNS de sua rede interna fique visível para todos na Internet está pedindo ataques de falsificação de DNS - não é uma boa ideia. Depois que a VPN se conectar, você poderá acessá-la com segurança através do pipe da VPN sem nenhuma regra de firewall no host do gateway da Internet. Eu recomendo que você remova a regra FORWARD para a porta UDP 53, a menos que você tenha uma boa razão para isso.

As regras de ACEITAR na tabela de filtros FORNECIMENTO do iptables só permitem que o sistema roteie o tráfego que já está endereçado corretamente ao destino. Como seu servidor IPsec parece ter um endereço 192.168. *. *, Seus clientes não podem usar esse endereço para acessá-lo pela Internet.

Em vez disso, você precisará configurar os clientes para usar o endereço IP público do servidor de gateway da Internet, e o servidor de gateway precisará de algumas regras DNAT para redirecionar o tráfego IPsec de entrada para o servidor IPsec.

Estas regras são necessárias no servidor de gateway da Internet, além das regras FORWARD que você já possui:

-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.37:500
-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.37:4500

Como parece não haver rastreamento de conexão automática para o IPsec, você também pode precisar das regras inversas para o tráfego de saída:

-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 500 -j SNAT --to-source <public IP>
-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 4500 -j SNAT --to-source <public IP> 

(Não tenho certeza sobre essa parte: primeiro tente sem essas regras e monitore as respostas de saída na interface da Internet do host do gateway da Internet. Se os pacotes IPsec de saída tiverem um 192.168.2.37 como seu IP de origem, adicione as duas regras SNAT acima. Se o IP de origem já estiver sendo alterado para o IP público do host do gateway da Internet, a regra DNAT rastreará a conexão com êxito e você não precisará das regras SNAT.)

Quando o tráfego da VPN do cliente chega ao host do gateway da Internet (inicialmente usando seu endereço IP como destino), o tráfego de entrada passa primeiro pela tabela PREROUTING. As regras do DNAT nelas substituirão o endereço de destino. Em seguida, o tráfego de entrada passa pela verificação de roteamento: como a regra DNAT acabou de substituir o IP de destino, o tráfego não é mais endereçado ao próprio host do gateway da Internet, passando pela tabela de roteamento e pela tabela de filtros FORWARD. Depois disso, a interface "interna" do host do gateway de Internet é direcionada para o host IPsec.

O host IPsec receberá pacotes com seu próprio endereço 192.168.2.37 nos cabeçalhos dos pacotes IP, mas, dentro do conteúdo criptografado, haverá o IP público original do servidor de gateway da Internet. O host IPsec deve estar ciente de NAT_TRAVERSAL para lidar com isso com êxito.

Quando o host IPsec responde, o host do gateway da Internet precisará substituir o IP de origem dos pacotes IPsec de saída por um IP público válido.

    
por 09.11.2018 / 14:17