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 <[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 >> > ===================================== >> > >> > >> > >> > >
