Problemas con IP's en VPN
Juan Pablo San Martín
coyotedemon en gmail.com
Mar Ago 23 15:19:42 CLST 2011
Tracepath de A a B:
10.6.0.1
10.6.0.1
10.6.0.14
192.168.101.10
Tracepath de B a A:
10.6.0.14
10.6.0.1
10.6.0.1
192.168.100.10
En ambos casos van por el tunel.
Una sola de las centrales está basada en asterisk (pero es producto
cerrado), y por las licencias ese es el protocolo para comunicarlas.
JPS
El día 23 de agosto de 2011 13:43, Alvaro Patricio Avello Mendez
<aavello en servinco.cl> escribió:
> ----- "Juan Pablo San Martín" <coyotedemon en gmail.com> escribió:
>
>> Le he dado varias vueltas al asunto, he buscado ene google, pero no
>> hay vueltas. Detallo más mi caso.
>> En la Oficina A tengo un server con openvpn. Este equipo a su vez
>> hace
>> de gateway de una Central Telefónica.
>> En la oficina B tengo otro server con openvpn (que hace el tunes con
>> A), que también es gateway para la salida a internet de una red local
>> y de una central telefónica. Ambas centrales (con SIP) deberían
>> conectarse, y poder llamar entre anexos, pero eso solo funciona desde
>> un lado a otro (desde un anexo de la oficina A a otro de la oficina
>> B). Al revés no solo no hay audio, sino que no se puede realizar la
>> llamada. Al mismo tiempo, la central telefónica de B dice que no
>> puede
>> conectarse con la central telefónica de A, pero al revés si está
>> conectada.
>>
>> Aquí más datos:
>>
>> OFICINA A:
>> Central telefónica: 192.168.100.10/24
>> Servidor: 192.168.100.1/24
>> 172.16.1.4/21 (Para acceso a red local de datos).
>> 10.6.0.1/24 (Tunel)
>> X.X.X.X/X (IP Publica)
>>
>> OFICINA B:
>> Central telefonica: 192.168.101.10/24
>> Servidor: 192.168.101.1/24
>> 10.6.0.14/24 (tunel)
>> YYY.YYY.YYY.YYY/Y (Ip Publica).
>>
>> Cualquier indicio de ayuda me puede servir.
>>
>> JPS
>>
>
> Desde el Host 192.168.101.10 haz un tracepath hacia la 192.168.100.10 y ve que ruta toman los paquetes (analiza si van hacia internet o por el túnel). Las PABX son asterisk ? Si lo son, te recomiendo hacer un trunk con IAX en vez de SIP. En la practica he observado que no se comporta muy bien SIP detrás de un NAT.
>
> Ojala te ayude.
>
> Saludos,
>
>
>
>>
>> El día 15 de agosto de 2011 20:58, Miguel Oyarzo
>> <miguelaustro en gmail.com> escribió:
>> >
>> > On 16/08/2011 10:32 AM, Juan Pablo San Martín wrote:
>> >>
>> >> El día 15 de agosto de 2011 20:24, Miguel Oyarzo
>> >> <miguelaustro en gmail.com> escribió:
>> >>>
>> >>> On 16/08/2011 10:04 AM, Juan Pablo San Martín wrote:
>> >>>>
>> >>>> El día 9 de agosto de 2011 19:51, Miguel Oyarzo
>> >>>> <miguelaustro en gmail.com> escribió:
>> >>>>>
>> >>>>> Lo unico que se me ocurre es una programacion
>> incompleta/incorrecta de
>> >>>>> los
>> >>>>> script a cada lado.
>> >>>>> Estan omitiendo parametros por lo visto.
>> >>>>>
>> >>>>> Quizas deberias pegar tu sciript.
>> >>>>> Estas usando VPN tipo Bridge (br0) en cada lado?
>> >>>>>
>> >>>>> Atte,
>> >>>>>
>> >>>>> =====================================
>> >>>>> Miguel Oyarzo O.
>> >>>>> =====================================
>> >>>>>
>> >>>>>
>> >>>>> On 10/08/2011 3:42 AM, Juan Pablo San Martín wrote:
>> >>>>>>
>> >>>>>> Estimados:
>> >>>>>>
>> >>>>>> Siguiendo sus consejos, finalmente monté una VPN entre las
>> dos
>> >>>>>> oficinas con OPENVPN: El elnace funciona bien, los pings entre
>> las dos
>> >>>>>> redes andan impecables, pero, se me presenta un problema. Desde
>> la lan
>> >>>>>> del servidor, al acceder a la red remota no realiza nateo de
>> las IP
>> >>>>>> (cada equipo se presenta con su propia IP), lo cual es bueno,
>> pero del
>> >>>>>> lado contrario, si realiza nateo, lo cual me trae varios
>> problemas.
>> >>>>>> Ambos IPtables están configurados de la misma manera. ¿Alguna
>> idea?
>> >>>>>>
>> >>>>>> JPS
>> >>>>
>> >>>> Script en la sucursal:
>> >>>>
>> >>>> client
>> >>>> dev tun
>> >>>> proto udp
>> >>>> remote xxx.yyy.zzz.aaa 8080
>> >>>> resolv-retry infinite
>> >>>> nobind
>> >>>> persist-key
>> >>>> persist-tun
>> >>>> ca ca.crt
>> >>>> key conce.key
>> >>>> cert conce.crt
>> >>>> tun-mtu 1500
>> >>>> keepalive 10 120
>> >>>> verb 4
>> >>>>
>> >>>> Script en el servidor:
>> >>>>
>> >>>> dev tun
>> >>>> proto udp
>> >>>> port 8080
>> >>>> ca /etc/openvpn/keys/ca.crt
>> >>>> cert /etc/openvpn/keys/server.crt
>> >>>> key /etc/openvpn/keys/server.key
>> >>>> dh /etc/openvpn/keys/dh1024.pem
>> >>>> user nobody
>> >>>> group nogroup
>> >>>> server 10.6.0.0 255.255.255.0
>> >>>> client-config-dir ccd
>> >>>> ifconfig-pool-persist /etc/openvpn/clients.txt
>> >>>> status /etc/openvpn/status.txt
>> >>>> persist-key
>> >>>> persist-tun
>> >>>> push "route 172.16.0.0 255.255.248.0"
>> >>>> push "route 192.168.100.0 255.255.255.0"
>> >>>> route 192.168.101.0 255.255.255.0
>> >>>> keepalive 10 120
>> >>>> verb 3
>> >>>> max-clients 25
>> >>>> client-to-client
>> >>>>
>> >>>> Si necesitas algo más, favor avisar.
>> >>>>
>> >>>> JPS
>> >>>>
>> >>> pega tu POSTROUTING del lado del cliente (a ver como se ve)
>> >>>
>> >>> =====================================
>> >>> Miguel Oyarzo O.
>> >>> ICT Network Engineer
>> >>> Melbourne, Australia
>> >>> miguelaustro en gmail.com
>> >>> http://linkedin.com/in/mikeaustralia
>> >>> Linux User: # 483188 - counter.li.org
>> >>> =====================================
>> >>>
>> >>>
>> >>>
>> >>>
>> >> iptables -t nat -A POSTROUTING -s 192.168.101.0/24 -o eth0 -j
>> MASQUERADE
>> >>
>> >> He probado también con y sin esta línea, pero pasa lo mismo
>> >>
>> >> iptables -t nat -A POSTROUTING -s 10.6.0.0/24 -o eth1 -j
>> MASQUERADE
>> >> (esta línea aparecía en los ejemplos de configuración de OPENVPN).
>> >>
>> >
>> > este comando client-to-client definitivamente tiene que ver con la
>> > visibilidad de los equipos detras de cada extremo, deberias darle un
>> vistaso
>> > a la documentacion.
>> >
>> > No obstante estas corriendo la VPN cliente destras de NAT y ademas
>> quieres
>> > crear un routed OpenVPN.. busca asi en gooogle:" OpenVPN behind
>> nat"
>> >
>> > Podras ver que algunos agregan FORWARD -j accept -i tunX
>> > y otros agrerarian mananualmente una ruta a 10.6.0.0 255.255.255.0
>> (segun tu
>> > ejemplo), del lado de tu cliente.
>> >
>> > Lo que te pasa es un problema mas o menos habitual y hay mas de una
>> forma de
>> > resolverlo.
>> >
>> > regards!
>> >
>> > =====================================
>> > Miguel Oyarzo O.
>> > ICT Network Engineer
>> > Melbourne, Australia
>> > miguelaustro en gmail.com
>> > http://linkedin.com/in/mikeaustralia
>> > Linux User: # 483188 - counter.li.org
>> > =====================================
>> >
>> >
>> >
>> >
>
Más información sobre la lista de distribución Linux