OpenVPN encaminhamento continua me redirecionando para o próprio servidor (com openVZ)

1

Estou tentando configurar uma VPN em um novo servidor virtual, com o OpenVZ. Eu peguei a configuração da minha VPN atual, que está hospedada em um Xen VPS e colei no meu novo servidor. Depois de várias tentativas, analiso diferentes tópicos e vejo que o OpenVZ não suporta a opção MASQUERADE de iptables . Então eu tento criar um arquivo iptable.sh, seguindo este blog postar .

Quando estou conectado à VPN, todas as páginas são obtidas do meu servidor (na mesma máquina da VPN) ... Por exemplo, se eu tentar acessar link , vejo a página padrão "Funciona" do servidor Apache2 em execução. Eu realmente não entendo porque ... Aqui está minha configuração:

/etc/openvpn/server.conf

mode server
tls-server

port 10735
proto udp

dev tun0

# Certificates, blablah...

# Virtual addr conf
server 172.16.0.0 255.255.255.0

push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"

# Log, persitent connections, max clients, blabla..

Conf iptable antigo (no meu servidor anterior, com o trabalho de MASQUERADE)

iptables -A FORWARD -s 172.16.0.0/24 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE

Novo iptables conf (armazenado no arquivo .sh)

/sbin/iptables -F
/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -s 172.16.0.0/24 -j ACCEPT

#/sbin/iptables -A FORWARD -j REJECT

# Perform NATing on outgoing packets to change the IP address the packets come from
/sbin/iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -j SNAT --to-source 89.2xx.xxx.xxx  <- my public addr

/sbin/iptables -A INPUT -p udp --dport 10735 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -j ACCEPT
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -i tun0 -j ACCEPT
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Agradecemos antecipadamente:)

Informação adicional
  • Não há problema com a conexão VPS, eu posso pingar vários domínios / IP ...

    ~# ping serverfault.com
    PING serverfault.com (198.252.206.16) 56(84) bytes of data.
    64 bytes from stackoverflow.com (198.252.206.16): icmp_req=1 ttl=50 time=58.5 ms
    [...]
    
  • http://<public VPS IP> retorna para a página "Trabalha" que recebi com a VPN.

  • cat /proc/sys/net/ipv4/ip_forward retorna 1 (encaminhamento de IP ativado)
por Maxime Lorant 02.12.2013 / 18:26

3 respostas

1

Diferença entre SNAT e MASQUERADE: primeiro trabalhando mais rápido, mas segundo trabalhando com IP dinâmico da WAN (usando pesquisas na tabela de rotas).
Muitos dos serviços do Cloud VPS, como o Amazon, configuram a DMZ para você: assim, o endereço IP externo não é o seu IP na interface externa do servidor. Todas as conexões para qualquer encaminhamento de porta do seu 89.2xx.xxx.xxx (que é realmente usado pelo hardware de rede) para o seu iface da WAN.
Assim, o pedido do TCP em http: // 'IP do VPS público' será processado pelo provedor e redirecionado incondicionalmente para o seu eth0. É por isso que você vê "funciona".
Mas se você tentar definir o campo SOURCE IP de todo o pacote de saída como 89.2xx.xxx.xxx - a rede do provedor irá avaliá-lo como pacote falsificado e descartá-lo.
Então você deve usar o endereço IP atribuído ao seu eth0 iface para SNAT (acho que difere do externo).

Verifique se a sua subnet eth0 não está cruzando sua sub-rede VPN - 172.16.0.0

    
por 11.12.2013 / 12:16
0

Eu tenho minha configuração do servidor OpenVPN através de um VPS e tive que usar o seguinte comando para fazer o NATing funcionar, já que o MASQUERADE não funcionaria. Uma vez que eu coloquei e assegurei que eu permitisse o encaminhamento das regras e também ativasse o ip_forward no /etc/sysctl.conf, eu estava pronto.

/sbin/iptables -t nat -A POSTROUTING -j SNAT --to-source external_ip_of_the_server
    
por 03.12.2013 / 15:10
0

Bem, de acordo com os sintomas que você está descrevendo, seu firewall parece ter uma regra DNAT redirecionando o acesso de fora para o endereço IP interno: 80. Esta regra não considera a interface de entrada, portanto, todas as suas solicitações de saída também estão sendo DNAT. Você tem que usar exatamente esse tipo de interface externa de redirecionamento DNAT.

    
por 11.12.2013 / 12:23