----- "Juan Pablo San Martín" <[email protected]> escribió:
> 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 > y el trafico RTP de los teléfonos tiene el mismo comportamiento ? usan el túnel ? > El día 23 de agosto de 2011 13:43, Alvaro Patricio Avello Mendez > <[email protected]> escribió: > > ----- "Juan Pablo San Martín" <[email protected]> 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 > >> <[email protected]> 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 > >> >> <[email protected]> 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 > >> >>>> <[email protected]> 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 > >> >>> [email protected] > >> >>> 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 > >> > [email protected] > >> > http://linkedin.com/in/mikeaustralia > >> > Linux User: # 483188 - counter.li.org > >> > ===================================== > >> > > >> > > >> > > >> > > >
