[GTER] OpenVPN "IP nateado"

Guilherme Domingues guilherme.domingues.oliveira at gmail.com
Tue Dec 4 00:12:38 -02 2012


Danilo boa noite,

Vamos supor que a saída para internet de sua filial é pela eth3. Logo terei
que fazer masquerade apenas por esta interface. E as demais interfaces vpn,
não entram para o nat de rede interna.

iptables -t nat -A POSTROUTING -s rede_interna -o eth3 -j MASQUERADE

Att.
Guilherme Domingues


LPI 102
LPI000161013
https://cs.lpi.org/caf/Xamman/certification/process_verify
code verification:  v8bwxqzja7
Linux ID #425752
---
"A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
original."  Albert Einstein



2012/12/3 Danilo Neves <danilorpneves at bsd.com.br>

> Acredito que devo usar minha VPN em modo bridge...vou fazer essa
> configuração e testar.
>
> Em 3 de dezembro de 2012 16:08, Danilo Neves <danilorpneves at bsd.com.br
> >escreveu:
>
> > O problema não é esse porque desativei todas as regras de NAT e mesmo
> > assim não deu certo.
> > Alguem pode enviar suas confs para fazer um comparação.
> >
> > Em 2 de dezembro de 2012 15:49, Diego Cananéa <diegocananea at gmail.com
> >escreveu:
> >
> > Creio que seja o que o Guilherme falou. No meu trabalho também temos umas
> >> VPNs e deixamos no cliente sem regras no firewall, apenas adicionamos a
> >> rota default pela VPN e deixamos o ip_forward habilitado.
> >>
> >>
> >> Em 30 de novembro de 2012 16:21, Guilherme Domingues <
> >> guilherme.domingues.oliveira at gmail.com> escreveu:
> >>
> >> > Pela forma que explicou, acredito que na filial esteja com alguma
> regra
> >> de
> >> > nat "geral" para rede interna.
> >> >
> >> > Retirando todas as regras de nat, e aplicando uma específica para
> natear
> >> > apenas para a interface de internet, já deverá resolver o problema
> >> > apontando.
> >> >
> >> > Att.
> >> > Guilherme Domingues
> >> >
> >> > LPI 102
> >> > LPI000161013
> >> > https://cs.lpi.org/caf/Xamman/certification/process_verify
> >> > code verification:  v8bwxqzja7
> >> > Linux ID #425752
> >> > ---
> >> > "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
> >> > original."  Albert Einstein
> >> >
> >> >
> >> >
> >> > 2012/11/30 Danilo Neves <danilorpneves at bsd.com.br>
> >> >
> >> > > Bom dia caro colegas.
> >> > > Tenho uma configuração de VPN com OpenVPN funcionando corretamente.
> >> > > Acontece que as conexões vindas das filiais (clientes vpn)  para
> meus
> >> > > servidores na matriz chegam com o IP do tunel e não com
> >> > > IP de origem.
> >> > > Exemplo:
> >> > >
> >> > > Tenho um servidor proxy na matriz com ip 192.168.1.30 e tenho minhas
> >> > > unidades com faixas de ip 192.168.2.0/24192.168.3.0/24 ... através
> de
> >> > VPN.
> >> > > Monitorando os logs do proxy e tcpdump, os clientes chegam com o IP
> do
> >> > > tunel, como se fosse nateado, ou seja assim eu não consigo saber o
> IP
> >> de
> >> > > origem de fato
> >> > > da filial.
> >> > > Agora se eu pingar  da matriz na filial eu chego com o IP correto de
> >> > > origem.
> >> > >
> >> > >
> >> > > Alguém pode me ajudar a resolver isso, quero que as requisições de
> IP
> >> das
> >> > > unidades não cheguem "nateado".
> >> > >
> >> > >
> >> -----------------------------------------------------------------------
> >> > > #Configuração na matriz onde é o server VPN.
> >> > >
> >> > >
> >> > > proto udp
> >> > > dev tun
> >> > > server 10.69.0.0 255.255.0.0
> >> > > push "route 192.168.1.0 255.255.255.0"
> >> > > push "route 192.168.3.0 255.255.255.0"
> >> > > push "route 192.168.5.0 255.255.255.0"
> >> > > push "route 192.168.6.0 255.255.255.0"
> >> > > push "route 192.168.7.0 255.255.255.0"
> >> > > #push "route 192.168.20.0 255.255.255.0"
> >> > >
> >> > > comp-lzo
> >> > > keepalive 10 120
> >> > > #ifconfig-pool-persist /usr/local/etc/openvpn/ipp.txt
> >> > > max-clients 5
> >> > > client-config-dir ccd
> >> > >
> >> > > #mode server
> >> > > client-to-client
> >> > >
> >> > > route 192.168.6.0 255.255.255.0
> >> > > route 192.168.5.0 255.255.255.0
> >> > > route 192.168.7.0 255.255.255.0
> >> > > route 192.168.3.0 255.255.255.0
> >> > > route 192.168.20.0 255.255.255.0
> >> > >
> >> > > #Chaves
> >> > > dh /usr/local/etc/openvpn/keys/dh1024.pem
> >> > > ca /usr/local/etc/openvpn/keys/ca.crt
> >> > > cert /usr/local/etc/openvpn/keys/servidor.crt
> >> > > key /usr/local/etc/openvpn/keys/servidor.key
> >> > > persist-key
> >> > > persist-tun
> >> > >
> >> > > #Logs
> >> > > status      /var/log/openvpn/openvpn-status.log
> >> > > log         /var/log/openvpn/openvpn.log
> >> > > log-append  /var/log/openvpn/openvpn.log
> >> > > verb 3
> >> > >
> >> > >
> >> > >
> >> >
> >>
>  ---------------------------------------------------------------------------------------------
> >> > > #Configuração do cliente VPN das filiais
> >> > >
> >> > > remote 187.90.230.21 #IP de exemplo
> >> > > remote 200.124.89.78 #IP de exemplo
> >> > >
> >> > > proto udp
> >> > > dev tun
> >> > > client
> >> > > pull
> >> > > comp-lzo
> >> > >
> >> > > route 192.168.10.0 255.255.255.0
> >> > > route 192.168.69.0 255.255.255.0
> >> > >
> >> > > #Chaves
> >> > > dh /etc/openvpn/keys/dh1024.pem
> >> > > ca /etc/openvpn/keys/ca.crt
> >> > > cert /etc/openvpn/keys/eldorado.crt
> >> > > key /etc/openvpn/keys/eldorado.key
> >> > > persist-key
> >> > > persist-tun
> >> > >
> >> > > #Logs
> >> > > status      /var/log/openvpn/openvpn-status.log
> >> > > log         /var/log/openvpn/openvpn.log
> >> > > log-append  /var/log/openvpn/openvpn.log
> >> > > verb 6
> >> > > --
> >> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> >> > >
> >> > --
> >> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >> >
> >>
> >>
> >>
> >> --
> >> Diego Cananéa Nóbrega de Azevedo
> >> http://diegocananea@wordpress.com
> >> www.twitter.com/diegocananea
> >> www.facebook.com/diegocananea
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list