Não é possível acessar uma rede externa com NAT

2

Rede

Estou configurando a seguinte rede, existem três sistemas e a VPN deve intermediar entre o Firewall e o Kali. Vamos supor que todos os sistemas estão usando o Ubuntu 16.04 (eventualmente eu instalarei as ferramentas Kali no Ubuntu):

  • MeuKaliécapazdeacessaroservidorVPN,masnãoécapazdeexecutarpingnofirewall.
  • EuviumasolicitaçãoARPparaoservidorVPNsolicitandooFirewall,masnãoháresposta.
  • EugostariadeusaroNATnoservidorVPN.
  • Editado:ParecequeoFirewallécapazdeestabelecerumanovasessãocomosistemaKali,masnãofuncionadeoutramaneira.Éestranho,jáquetodasaspolíticasdeIptablessãoACEITASporpadrão.

Pergunta

  • PorquenãohárespostadaVPNquandoperguntadosobreoendereçoARPdoFirewall?EuesperavaqueoFirewallrespondessecomseupróprioendereçoMAC.
  • OquemaisdevofazerparaativaroNATnoservidorVPN?

Rotas

Iptables

Iptables para o servidor VPN:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i enp0s3 -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE # Enmascarmiento IP

iptables -A FORWARD -i tap0 -o enp0s3 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i enp0s3 -o tap0 -j ACCEPT

Os iptables dos outros dois sistemas têm uma política de ACCEPT ALL.

Encaminhamento & Masquerade

O encaminhamento está habilitado para o servidor VPN. Eu já tenho as configurações em / proc / sys / net / ipv4 / ip_forward.

Além disso, o sistema tem o módulo para usar o masquerada (lsmod):

ipt_MASQUERADE         16384  1
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
nf_nat                 24576  2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack          106496  5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4
x_tables               36864  5 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter,iptable_mangle

Ifconfig

Fixo

Eu encontrei o bug:

12.5.0.0 * 255.255.255.0 U 0 0 0 tap0

O problema é que eu estava configurando um gateway padrão para essa rota no sistema Kali. Eu tive que especificar a saída de todo o tráfego através de 10.8.0.1, que na minha opinião é redundante, uma vez que era o único caminho possível para ir.

    
por Cod1ngFree 22.09.2016 / 14:37

1 resposta

3

Você não permite que novas conexões sejam encaminhadas ou aceitas em seu servidor VPN. Mudar

iptables -A FORWARD -i tap0 -o enp0s3 -m state --state RELATED,ESTABLISHED -j ACCEPT

para

iptables -A FORWARD -i tap0 -o enp0s3 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

e tente se funcionar. Em caso afirmativo, remova a instrução NEW da regra geral e crie uma nova regra somente encaminhar e aceitar para os protocolos / portas que você precisa encaminhar, e. g .:

iptables -A FORWARD -i tap0 -o enp0s3 -p tcp --dport 22 -m state --state NEW -j ACCEPT

Além disso, você precisa usar o NAT de destino se quiser encaminhar uma solicitação externa para sua LAN interna:

Exemplo: Encaminhe o SSH na porta 10022 para uma porta interna da máquina 22:

iptables -t nat -A PREROUTING -p tcp --dport 10022 -j DNAT --to-destination 192.168.1.100:22
iptables -t nat -A POSTROUTING -p tcp --dport 10022 -j MASQUERADE 

Além disso, você definiu a regra de encaminhamento permanentemente em /etc/sysctl.conf? Se você acabou de fazer echo 1 > /proc/sys/net/ipv4/ip_forward , ele estará ativo somente até a próxima reinicialização.

EDITAR: Acabei de descobrir que sou cego. É claro que o seu firewall não responde ao seu pedido ARP, ele está em outra rede. As solicitações ARP não são encaminhadas por definição. Se o seu Laptop quiser se comunicar com o firewall, ele não se comunicará diretamente, mas através do gateway (sua VPN). Em sua tabela de roteamento, a VPN está presente como gateway para comunicação com o firewall, portanto, não deve enviar uma solicitação ARP para o firewall. ARP não é IP, não é encaminhado.

Você deve testar se o NAT funciona com o SSH, tente o que eu postei antes e conecte-se ao seu roteador pela porta 10022, você deve ser encaminhado para o seu firewall.

    
por 22.09.2016 / 15:15