[GTER] OpenVPN "IP nateado"

Danilo Neves danilorpneves at bsd.com.br
Tue Dec 4 11:21:32 -02 2012 

Pois é, até imaginei isso e inclusive desabilitei as regras mas ainda
continua chegando nateado com o IP do tunel.
Se eu pingo de uma máquina (192.168.1.67) interna da matriz para filial
(192.168.5.25), chego com o ip correto no destino, sem ser nateado ou seja
chego com ip 192.168.1.67.
Agora se eu pingar de uma máquina (192.168.5.25) da rede da filial na
matriz (192.168.1.37) eu chego com IP do tunel que no meu caso é 10.69.0.6 e
não com o IP 192..168.5.25.

Só falta resolver isso e tudo lindo :D.





Servidor Matriz (FreeBSD)
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::215:17ff:fe2e:9f25%tun0 prefixlen 64 scopeid 0xe
        inet 10.69.0.1 --> 10.69.0.2 netmask 0xffffffff
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 2288


Servidor Filial (cliente) (Linux)
tun0      Link encap:Não Especificado  Endereço de HW
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet end.: 10.69.0.6  P-a-P:10.69.0.5  Masc:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Métrica:1
          RX packets:190811 errors:0 dropped:0 overruns:0 frame:0
          TX packets:222418 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:100
          RX bytes:134745423 (128.5 MiB)  TX bytes:51393261 (49.0 MiB)



Rota na matriz
192.168.5.0/24     10.69.0.2          UGS         0    32730   tun0


Rota na filial
192.168.1.0     10.69.0.5       255.255.255.0   UG        0 0          0
tun0



Em 4 de dezembro de 2012 00:12, Guilherme Domingues <
guilherme.domingues.oliveira at gmail.com> escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list