Amigos... les cuento... tengo un centos con internet vía eth0 el cual hace NAT sin problemas.. pero necesito que un cliente de mi lan (192.168.7.11) salga por una VPN (ppp0) ... entonces aplique :
(en el Server) - echo 10 vpn >> /etc/iproute2/rt_tables - ip rule add from 192.168.7.11 table vpn - ip route add default via X.Y.Z.W dev ppp0 table vpn - ip route flush cache
y el cliente tiene acceso a la Lan pero no a Internet...
Alguien me podría dar una mano para ver por donde esta el problema ??
Muchas Gracias a todos...
Me parece que debes aplciar una regla en tu firewall algo así
$IPTABLES -A FORWARD -m state --state NEW -p tcp --dport 53 -j ACCEPT $IPTABLES -A FORWARD -m state --state NEW -p tcp --dport 80 -j ACCEPT
gracias... aplique lo que me indicas y sigo en las mismas...
Slds.
2014-05-28 12:07 GMT-04:00 César Martinez cmartinez@servicomecuador.com:
Me parece que debes aplciar una regla en tu firewall algo así
$IPTABLES -A FORWARD -m state --state NEW -p tcp --dport 53 -j ACCEPT $IPTABLES -A FORWARD -m state --state NEW -p tcp --dport 80 -j ACCEPT
-- Saludos Cordiales
|César Martínez | Ingeniero de Sistemas | SERVICOM |Tel: (593-2)554-271 2221-386 | Ext 4501 |Celular: 0999374317 |Skype servicomecuador |Web www.servicomecuador.com Síguenos en: Twitter: @servicomecuador |Facebook: servicomec Zona Clientes: www.servicomecuador.com/billing Blog: http://servicomecuador.com/blog Dir. Av. 10 de Agosto N29-140 Entre Acuña y Cuero y Caicedo Quito - Ecuador - Sudamérica
On 28/05/14 10:22, James Dean wrote:
Amigos... les cuento... tengo un centos con internet vía eth0 el cual hace NAT sin problemas.. pero necesito que un cliente de mi lan (192.168.7.11) salga por una VPN (ppp0) ... entonces aplique :
(en el Server)
- echo 10 vpn >> /etc/iproute2/rt_tables
- ip rule add from 192.168.7.11 table vpn
- ip route add default via X.Y.Z.W dev ppp0 table vpn
- ip route flush cache
y el cliente tiene acceso a la Lan pero no a Internet...
Alguien me podría dar una mano para ver por donde esta el problema ??
Muchas Gracias a todos... _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Esas reglas estan aplicadas a mi firewall debes verificar si la variable $IPTABLES es la misma en tu iptables, tube un problema similar al que mencionas con un equipo que tenia windowsXP y no se porque aquí no funcionaba el internet, por suerte se cambio este equipo a windows7 y con eso se solucionó, aplicando la regla que te envié y el cambio de sistema operativo
El 28/05/2014 17:22, James Dean escribió:
Amigos... les cuento... tengo un centos con internet vía eth0 el cual hace NAT sin problemas.. pero necesito que un cliente de mi lan (192.168.7.11) salga por una VPN (ppp0) ... entonces aplique :
(en el Server)
- echo 10 vpn >> /etc/iproute2/rt_tables
- ip rule add from 192.168.7.11 table vpn
- ip route add default via X.Y.Z.W dev ppp0 table vpn
- ip route flush cache
y el cliente tiene acceso a la Lan pero no a Internet...
Cuando dices que el 192.168.7.11 tiene acceso a la LAN, ¿te refieres al otro extremo de la VPN?
Alguien me podría dar una mano para ver por donde esta el problema ??
Más preguntas para entender tu entorno.
¿Quién levanta la VPN el servidor o PC con la 192.168.7.11? He supuesto que el servidor. ¿Por donde quieres que 192.168.7.11 salga a Internet? ¿Por tu gateway o por el gateway del otro extremo de la VPN?
Con las lineas "ip rule" y ip "route add default" estas forzando que el 192.162.7.11 salga siempre, absolutamente siempre, por la VPN. Así que:
1. Asegúrate que la VPN está levantada y tienes acceso al otro extremo desde el servidor.
2. Si quieres que el 192.168.7.11 salga a Internet a través de la red que hay en el otro extremo de la VPN, comprueba que la gateway por defecto que has añadido (X.Y.Z.W) puede salir a Internet. Si no puede salir añádele las rutas pertinentes. Si sí puede seguramente deberás activar en enrutado en X.Y.Z.W
Muchas Gracias a todos...
Bueno hay muchas alternativas y muchas posibles causas dependiendo de lo que estés intentando, así que mejor que antes lo aclares un poco más.
Saludos,
Francesc :
Gracias por tu respuesta, te respondo...
el cliente 192.168.7.11 (radxa) tiene acceso a la red Local (192.168.7.0), pero no al otro extremo de la VPN El responsable de levantar la VPN es el Server Centos Mi intención es que radxa salga a internet por la VPN (ppp0) [es decir, salir por el Gateway del otro extremo de la VPN]
NEW!!!
Acabo de reconfigurar todo el escenario... he creado en eth4 la subnet 192.168.4.1/28.
- Tengo configurado dhcpd, dns y firewall - radxa (que esta dentro de esta nueva subnet tiene la IP 192.168.4.2) sale a internet (no por la VPN) y red local sin problemas...
- Problema : Lo que necesito, con este nuevo escenario, es que todos los clientes de la subnet 192.168.4.1/28 (con Gateway 192.168.7.1 en eth4) salgan a internet por la VPN (ppp0) que levanta Centos.-
Mas Datos: - radxa levanta bien el cliente e incluso puedo navegar por internet y el `curl ifconfig.me me` devuelve la IP entregada por la VPN.-
Ahora voy a crear la ruta, regla y hacer las pruebas (todo en centos)... creo que mi problema esta por el lado del nat e iptables... la verdad es que esta es la primera vez que veo estos temas en centos... pero esta interesante (todo sea por el Amazon Fire TV :)
Gracias !!!
2014-05-29 3:33 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 28/05/2014 17:22, James Dean escribió:
Amigos... les cuento... tengo un centos con internet vía eth0 el cual hace NAT sin problemas.. pero necesito que un cliente de mi lan (192.168.7.11) salga por una VPN (ppp0) ... entonces aplique :
(en el Server)
- echo 10 vpn >> /etc/iproute2/rt_tables
- ip rule add from 192.168.7.11 table vpn
- ip route add default via X.Y.Z.W dev ppp0 table vpn
- ip route flush cache
y el cliente tiene acceso a la Lan pero no a Internet...
Cuando dices que el 192.168.7.11 tiene acceso a la LAN, ¿te refieres al otro extremo de la VPN?
Alguien me podría dar una mano para ver por donde esta el problema ??
Más preguntas para entender tu entorno.
¿Quién levanta la VPN el servidor o PC con la 192.168.7.11? He supuesto que el servidor. ¿Por donde quieres que 192.168.7.11 salga a Internet? ¿Por tu gateway o por el gateway del otro extremo de la VPN?
Con las lineas "ip rule" y ip "route add default" estas forzando que el 192.162.7.11 salga siempre, absolutamente siempre, por la VPN. Así que:
- Asegúrate que la VPN está levantada y tienes acceso al otro extremo
desde el servidor.
- Si quieres que el 192.168.7.11 salga a Internet a través de la red
que hay en el otro extremo de la VPN, comprueba que la gateway por defecto que has añadido (X.Y.Z.W) puede salir a Internet. Si no puede salir añádele las rutas pertinentes. Si sí puede seguramente deberás activar en enrutado en X.Y.Z.W
Muchas Gracias a todos...
Bueno hay muchas alternativas y muchas posibles causas dependiendo de lo que estés intentando, así que mejor que antes lo aclares un poco más.
Saludos,
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
El 29/05/2014 17:55, James Dean escribió:
Francesc :
Gracias por tu respuesta, te respondo...
el cliente 192.168.7.11 (radxa) tiene acceso a la red Local (192.168.7.0), pero no al otro extremo de la VPN El responsable de levantar la VPN es el Server Centos Mi intención es que radxa salga a internet por la VPN (ppp0) [es decir, salir por el Gateway del otro extremo de la VPN]
NEW!!!
Acabo de reconfigurar todo el escenario... he creado en eth4 la subnet 192.168.4.1/28.
- Tengo configurado dhcpd, dns y firewall
- radxa (que esta dentro de esta nueva subnet tiene la IP 192.168.4.2) sale
a internet (no por la VPN) y red local sin problemas...
- Problema :
Lo que necesito, con este nuevo escenario, es que todos los clientes de la subnet 192.168.4.1/28 (con Gateway 192.168.7.1 en eth4) salgan a internet por la VPN (ppp0) que levanta Centos.-
Los PCs de la red 192.168.4.1/28 deben usar como gateway la 192.168.4.1
Mas Datos:
- radxa levanta bien el cliente e incluso puedo navegar por internet y el
`curl ifconfig.me me` devuelve la IP entregada por la VPN.-
¿Radxa levanta bien el cliente? ¿No habías dicho que el encargado de levantar la VPN era el servidor?
Ahora voy a crear la ruta, regla y hacer las pruebas (todo en centos)... creo que mi problema esta por el lado del nat e iptables... la verdad es que esta es la primera vez que veo estos temas en centos... pero esta interesante (todo sea por el Amazon Fire TV :)
Tienes que crear una ruta que diga que todo lo que viene de la red 192.168.4.0/28 sea reenviado a través de la VPN. Adapta las rutas y las reglas que habías creado anteriormente
No me lo he mirado mucho pero según lo que habías propuesto anteriormente sería algo como:
(en el Server) - echo 10 vpn >> /etc/iproute2/rt_tables - ip rule add from 192.168.4.0/28 table vpn - ip route add default via X.Y.Z.W dev ppp0 table vpn - ip route flush cache
X.Y.Z.W debería ser la IP del interface ppp0 o quizás la del terminador la VPN (el otro extremo de VPN)
Usa tracepath o traceroute para verificar que ruta toman los paquetes.
Gracias !!!
De nada!
2014-05-29 12:25 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 17:55, James Dean escribió:
Francesc :
Gracias por tu respuesta, te respondo...
el cliente 192.168.7.11 (radxa) tiene acceso a la red Local
(192.168.7.0),
pero no al otro extremo de la VPN El responsable de levantar la VPN es el Server Centos Mi intención es que radxa salga a internet por la VPN (ppp0) [es decir, salir por el Gateway del otro extremo de la VPN]
NEW!!!
Acabo de reconfigurar todo el escenario... he creado en eth4 la subnet 192.168.4.1/28.
- Tengo configurado dhcpd, dns y firewall
- radxa (que esta dentro de esta nueva subnet tiene la IP 192.168.4.2)
sale
a internet (no por la VPN) y red local sin problemas...
- Problema :
Lo que necesito, con este nuevo escenario, es que todos los clientes de
la
subnet 192.168.4.1/28 (con Gateway 192.168.7.1 en eth4) salgan a
internet
por la VPN (ppp0) que levanta Centos.-
Los PCs de la red 192.168.4.1/28 deben usar como gateway la 192.168.4.1
Ok
Mas Datos:
- radxa levanta bien el cliente e incluso puedo navegar por internet y el
`curl ifconfig.me me` devuelve la IP entregada por la VPN.-
¿Radxa levanta bien el cliente? ¿No habías dicho que el encargado de levantar la VPN era el servidor?
Fue un test levantar la vpn desde radxa... quería verificar que todo estaba ok ... pero Centos es el responsable de levantar la VPN (pptp)
Ahora voy a crear la ruta, regla y hacer las pruebas (todo en centos)... creo que mi problema esta por el lado del nat e iptables... la verdad es que esta es la primera vez que veo estos temas en centos... pero esta interesante (todo sea por el Amazon Fire TV :)
Tienes que crear una ruta que diga que todo lo que viene de la red 192.168.4.0/28 sea reenviado a través de la VPN. Adapta las rutas y las reglas que habías creado anteriormente
No me lo he mirado mucho pero según lo que habías propuesto anteriormente sería algo como:
(en el Server)
- echo 10 vpn >> /etc/iproute2/rt_tables
- ip rule add from 192.168.4.0/28 table vpn
- ip route add default via X.Y.Z.W dev ppp0 table vpn
- ip route flush cache
X.Y.Z.W debería ser la IP del interface ppp0 o quizás la del terminador la VPN (el otro extremo de VPN)
Usa tracepath o traceroute para verificar que ruta toman los paquetes.
Correcto, adaptaré mi configuración inicial al nuevo escenario... Gracias por tu tiempo... te comentaré como me va en un posterior mail...
Posdata: lo curioso es que requiero saber con antelación el GW de la VPN, pero esto no lo sabré hasta despúes de : `pon vpn debug dump logfd 2 nodetach`
Gracias !!!
De nada!
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer las pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder al cliente. desde radxa no pude acceder a internet, al ejecutar en radxa 'lynx www.google.com' se queda pegado... y en el server centos se ve :
tcpdump -i eth4 not port 22
15:23:39.372159 IP 192.168.4.2.44039 > 192.168.4.1.domain: 49003+ A? www.google.com. (32) 15:23:39.372189 IP 192.168.4.2.44039 > 192.168.4.1.domain: 48077+ AAAA? www.google.com. (32) 15:23:39.398117 IP 192.168.4.1.domain > 192.168.4.2.44039: 49003 5/0/0 A 173.194.42.211, A 173.194.42.210, A 173.194.42.208, A 173.194.42.209, A 173.194.42.212 (112) 15:23:39.398172 IP 192.168.4.1.domain > 192.168.4.2.44039: 48077 1/0/0 AAAA 2800:3f0:4003:800::1012 (60) 15:23:39.426042 IP 192.168.4.2.60032 > 192.168.4.1.domain: 51490+ A? www.google.com. (32) 15:23:39.426064 IP 192.168.4.2.60032 > 192.168.4.1.domain: 55927+ AAAA? www.google.com. (32) 15:23:39.426157 IP 192.168.4.1.domain > 192.168.4.2.60032: 51490 5/0/0 A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210, A 173.194.42.211 (112) 15:23:39.426221 IP 192.168.4.1.domain > 192.168.4.2.60032: 55927 1/0/0 AAAA 2800:3f0:4003:800::1012 (60) 15:23:39.429146 IP 192.168.4.2.45624 > 192.168.4.1.domain: 46806+ A? www.google.com. (32) 15:23:39.429177 IP 192.168.4.2.45624 > 192.168.4.1.domain: 41269+ AAAA? www.google.com. (32) 15:23:39.429237 IP 192.168.4.1.domain > 192.168.4.2.45624: 46806 5/0/0 A 173.194.42.211, A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210 (112) 15:23:39.429278 IP 192.168.4.1.domain > 192.168.4.2.45624: 41269 1/0/0 AAAA 2800:3f0:4003:800::1012 (60) 15:23:39.430923 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788592 ecr 0,nop,wscale 4], length 0 15:23:42.433559 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788893 ecr 0,nop,wscale 4], length 0 15:23:48.443398 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2789494 ecr 0,nop,wscale 4], length 0
Seguiré revisando ...
Gracias !!!
2014-05-29 12:45 GMT-04:00 James Dean bondmac@gmail.com:
2014-05-29 12:25 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 17:55, James Dean escribió:
Francesc :
Gracias por tu respuesta, te respondo...
el cliente 192.168.7.11 (radxa) tiene acceso a la red Local
(192.168.7.0),
pero no al otro extremo de la VPN El responsable de levantar la VPN es el Server Centos Mi intención es que radxa salga a internet por la VPN (ppp0) [es decir, salir por el Gateway del otro extremo de la VPN]
NEW!!!
Acabo de reconfigurar todo el escenario... he creado en eth4 la subnet 192.168.4.1/28.
- Tengo configurado dhcpd, dns y firewall
- radxa (que esta dentro de esta nueva subnet tiene la IP 192.168.4.2)
sale
a internet (no por la VPN) y red local sin problemas...
- Problema :
Lo que necesito, con este nuevo escenario, es que todos los clientes de
la
subnet 192.168.4.1/28 (con Gateway 192.168.7.1 en eth4) salgan a
internet
por la VPN (ppp0) que levanta Centos.-
Los PCs de la red 192.168.4.1/28 deben usar como gateway la 192.168.4.1
Ok
Mas Datos:
- radxa levanta bien el cliente e incluso puedo navegar por internet y
el
`curl ifconfig.me me` devuelve la IP entregada por la VPN.-
¿Radxa levanta bien el cliente? ¿No habías dicho que el encargado de levantar la VPN era el servidor?
Fue un test levantar la vpn desde radxa... quería verificar que todo estaba ok ... pero Centos es el responsable de levantar la VPN (pptp)
Ahora voy a crear la ruta, regla y hacer las pruebas (todo en centos)... creo que mi problema esta por el lado del nat e iptables... la verdad es que esta es la primera vez que veo estos temas en centos... pero esta interesante (todo sea por el Amazon Fire TV :)
Tienes que crear una ruta que diga que todo lo que viene de la red 192.168.4.0/28 sea reenviado a través de la VPN. Adapta las rutas y las reglas que habías creado anteriormente
No me lo he mirado mucho pero según lo que habías propuesto anteriormente sería algo como:
(en el Server)
- echo 10 vpn >> /etc/iproute2/rt_tables
- ip rule add from 192.168.4.0/28 table vpn
- ip route add default via X.Y.Z.W dev ppp0 table vpn
- ip route flush cache
X.Y.Z.W debería ser la IP del interface ppp0 o quizás la del terminador la VPN (el otro extremo de VPN)
Usa tracepath o traceroute para verificar que ruta toman los paquetes.
Correcto, adaptaré mi configuración inicial al nuevo escenario... Gracias por tu tiempo... te comentaré como me va en un posterior mail...
Posdata: lo curioso es que requiero saber con antelación el GW de la VPN, pero esto no lo sabré hasta despúes de : `pon vpn debug dump logfd 2 nodetach`
Gracias !!!
De nada!
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
El 29/05/2014 21:27, James Dean escribió:
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer las pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder al cliente.
¿Desde donde accedes a radxa? Si accedes desde la red 192.168.7.X es normal que te suceda con las reglas que habíamos aplicado. Todo el trafico saliente de la red 192.168.4.0 es enviado a la gateway X.Y.Z.W. Si quieres que estas dos redes se comuniquen añade una regla que lo permita en la tabla vpn. Sería algo como:
ip route add 192.168.7.0/24 via 192.168.7.1 dev eth0 table vpn
desde radxa no pude acceder a internet, al ejecutar en radxa 'lynx www.google.com' se queda pegado... y en el server centos se ve :
tcpdump -i eth4 not port 22
15:23:39.372159 IP 192.168.4.2.44039 > 192.168.4.1.domain: 49003+ A? www.google.com. (32) 15:23:39.372189 IP 192.168.4.2.44039 > 192.168.4.1.domain: 48077+ AAAA? www.google.com. (32) 15:23:39.398117 IP 192.168.4.1.domain > 192.168.4.2.44039: 49003 5/0/0 A 173.194.42.211, A 173.194.42.210, A 173.194.42.208, A 173.194.42.209, A 173.194.42.212 (112) 15:23:39.398172 IP 192.168.4.1.domain > 192.168.4.2.44039: 48077 1/0/0 AAAA 2800:3f0:4003:800::1012 (60) 15:23:39.426042 IP 192.168.4.2.60032 > 192.168.4.1.domain: 51490+ A? www.google.com. (32) 15:23:39.426064 IP 192.168.4.2.60032 > 192.168.4.1.domain: 55927+ AAAA? www.google.com. (32) 15:23:39.426157 IP 192.168.4.1.domain > 192.168.4.2.60032: 51490 5/0/0 A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210, A 173.194.42.211 (112) 15:23:39.426221 IP 192.168.4.1.domain > 192.168.4.2.60032: 55927 1/0/0 AAAA 2800:3f0:4003:800::1012 (60) 15:23:39.429146 IP 192.168.4.2.45624 > 192.168.4.1.domain: 46806+ A? www.google.com. (32) 15:23:39.429177 IP 192.168.4.2.45624 > 192.168.4.1.domain: 41269+ AAAA? www.google.com. (32) 15:23:39.429237 IP 192.168.4.1.domain > 192.168.4.2.45624: 46806 5/0/0 A 173.194.42.211, A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210 (112) 15:23:39.429278 IP 192.168.4.1.domain > 192.168.4.2.45624: 41269 1/0/0 AAAA 2800:3f0:4003:800::1012 (60) 15:23:39.430923 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788592 ecr 0,nop,wscale 4], length 0 15:23:42.433559 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788893 ecr 0,nop,wscale 4], length 0 15:23:48.443398 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2789494 ecr 0,nop,wscale 4], length 0
Seguiré revisando ...
Parece claro que los paquetes no pasan del servidor.
Manda la salida de "ip addr", "ip route show", "ip route show table vpn" y "ip rule show".
En cuanto a la gateway X.Y.Z.W, y teniendo en cuenta que dijiste que no sabes la IP del otro extremo de la VPN hasta que te conectas, usa la IP de la interfaz ppp0.
Gracias !!!
De nada.
2014-05-30 4:46 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 21:27, James Dean escribió:
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer las pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder al cliente.
¿Desde donde accedes a radxa? Si accedes desde la red 192.168.7.X es normal que te suceda con las reglas que habíamos aplicado. Todo el trafico saliente de la red 192.168.4.0 es enviado a la gateway X.Y.Z.W. Si quieres que estas dos redes se comuniquen añade una regla que lo permita en la tabla vpn. Sería algo como:
Al radxa accedo desde la red 192.168.7.X
ip route add 192.168.7.0/24 via 192.168.7.1 dev eth0 table vpn
Ok, sin embargo ahora únicamente el cliente radxa (192.168.4.2) es el que esta en la ruta vpn, y puedo acceder a el desde 192.168.7.X sin problemas ni con la necesidad de agregar ninguna ruta adicional...
desde radxa no pude acceder a internet, al ejecutar en radxa 'lynx www.google.com' se queda pegado... y en el server centos se ve :
tcpdump -i eth4 not port 22
15:23:39.372159 IP 192.168.4.2.44039 > 192.168.4.1.domain: 49003+ A? www.google.com. (32) 15:23:39.372189 IP 192.168.4.2.44039 > 192.168.4.1.domain: 48077+ AAAA? www.google.com. (32) 15:23:39.398117 IP 192.168.4.1.domain > 192.168.4.2.44039: 49003 5/0/0 A 173.194.42.211, A 173.194.42.210, A 173.194.42.208, A 173.194.42.209, A 173.194.42.212 (112) 15:23:39.398172 IP 192.168.4.1.domain > 192.168.4.2.44039: 48077 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.426042 IP 192.168.4.2.60032 > 192.168.4.1.domain: 51490+ A? www.google.com. (32) 15:23:39.426064 IP 192.168.4.2.60032 > 192.168.4.1.domain: 55927+ AAAA? www.google.com. (32) 15:23:39.426157 IP 192.168.4.1.domain > 192.168.4.2.60032: 51490 5/0/0 A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210, A 173.194.42.211 (112) 15:23:39.426221 IP 192.168.4.1.domain > 192.168.4.2.60032: 55927 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.429146 IP 192.168.4.2.45624 > 192.168.4.1.domain: 46806+ A? www.google.com. (32) 15:23:39.429177 IP 192.168.4.2.45624 > 192.168.4.1.domain: 41269+ AAAA? www.google.com. (32) 15:23:39.429237 IP 192.168.4.1.domain > 192.168.4.2.45624: 46806 5/0/0 A 173.194.42.211, A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210 (112) 15:23:39.429278 IP 192.168.4.1.domain > 192.168.4.2.45624: 41269 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.430923 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788592 ecr 0,nop,wscale 4], length 0 15:23:42.433559 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788893 ecr 0,nop,wscale 4], length 0 15:23:48.443398 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2789494 ecr 0,nop,wscale 4], length 0
Seguiré revisando ...
Parece claro que los paquetes no pasan del servidor.
Manda la salida de "ip addr", "ip route show", "ip route show table vpn" y "ip rule show".
ip addr :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.4.1/28 brd 192.168.4.15 scope global eth4 inet6 fe80::6ef0:49ff:fe0f:b795/64 scope link valid_lft forever preferred_lft forever 7: eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.7.1/28 brd 192.168.7.15 scope global eth5 inet6 fe80::208:54ff:fe36:c9f9/64 scope link valid_lft forever preferred_lft forever 9: eth7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1444 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.0.12/24 brd 192.168.0.255 scope global eth7 inet6 fe80::200:24ff:fec9:ceda/64 scope link valid_lft forever preferred_lft forever 24: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1396 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet 192.161.173.24 peer 192.161.173.3/32 scope global ppp0
ip route show:
192.161.173.3 dev ppp0 proto kernel scope link src 192.161.173.24 192.161.173.2 via 192.168.0.1 dev eth7 src 192.168.0.12 192.168.7.0/28 dev eth5 proto kernel scope link src 192.168.7.1 192.168.4.0/28 dev eth4 proto kernel scope link src 192.168.4.1 192.168.0.0/24 dev eth7 proto kernel scope link src 192.168.0.12 169.254.0.0/16 dev eth4 scope link metric 1006 169.254.0.0/16 dev eth5 scope link metric 1007 169.254.0.0/16 dev eth7 scope link metric 1009 default via 192.168.0.1 dev eth7
ip route show table vpn:
default via 192.161.173.3 dev ppp0
ip rule show: 0: from all lookup local 32765: from 192.168.4.2 lookup vpn 32766: from all lookup main 32767: from all lookup default
En cuanto a la gateway X.Y.Z.W, y teniendo en cuenta que dijiste que no
sabes la IP del otro extremo de la VPN hasta que te conectas, usa la IP de la interfaz ppp0.
mmm... respecto de este tema, estaba pensando en un script que "extrae" ese ip, pero, según mi caso, tendré que aplicar una regla dinámica, a mi ruta vpn, por cada conexión o reconexión.... la idea es que la red 192.168.4.X siempre salga a internet por la interfaz ppp0 ...
Slds.
Posdata: acote el problema a solamente un cliente, a radxa.-
Reitero mis agradecimientos por tu tiempo y disposición.... Muchas Gracias !!!
Gracias !!!
De nada.
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
El 30/05/2014 15:49, James Dean escribió:
2014-05-30 4:46 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 21:27, James Dean escribió:
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer las pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder al cliente.
¿Desde donde accedes a radxa? Si accedes desde la red 192.168.7.X es normal que te suceda con las reglas que habíamos aplicado. Todo el trafico saliente de la red 192.168.4.0 es enviado a la gateway X.Y.Z.W. Si quieres que estas dos redes se comuniquen añade una regla que lo permita en la tabla vpn. Sería algo como:
Al radxa accedo desde la red 192.168.7.X
ip route add 192.168.7.0/24 via 192.168.7.1 dev eth0 table vpn
Ok, sin embargo ahora únicamente el cliente radxa (192.168.4.2) es el que esta en la ruta vpn, y puedo acceder a el desde 192.168.7.X sin problemas ni con la necesidad de agregar ninguna ruta adicional...
Raro. Creo que podrías tener ese comportamiento si haces NAT de salida en la eth4 del server (192.168.4.1). Si no sabría decirte. Habría que investigar más.
Olvidé pedirte también la salida de "ip route show table local"
desde radxa no pude acceder a internet, al ejecutar en radxa 'lynx www.google.com' se queda pegado... y en el server centos se ve :
tcpdump -i eth4 not port 22
15:23:39.372159 IP 192.168.4.2.44039 > 192.168.4.1.domain: 49003+ A? www.google.com. (32) 15:23:39.372189 IP 192.168.4.2.44039 > 192.168.4.1.domain: 48077+ AAAA? www.google.com. (32) 15:23:39.398117 IP 192.168.4.1.domain > 192.168.4.2.44039: 49003 5/0/0 A 173.194.42.211, A 173.194.42.210, A 173.194.42.208, A 173.194.42.209, A 173.194.42.212 (112) 15:23:39.398172 IP 192.168.4.1.domain > 192.168.4.2.44039: 48077 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.426042 IP 192.168.4.2.60032 > 192.168.4.1.domain: 51490+ A? www.google.com. (32) 15:23:39.426064 IP 192.168.4.2.60032 > 192.168.4.1.domain: 55927+ AAAA? www.google.com. (32) 15:23:39.426157 IP 192.168.4.1.domain > 192.168.4.2.60032: 51490 5/0/0 A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210, A 173.194.42.211 (112) 15:23:39.426221 IP 192.168.4.1.domain > 192.168.4.2.60032: 55927 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.429146 IP 192.168.4.2.45624 > 192.168.4.1.domain: 46806+ A? www.google.com. (32) 15:23:39.429177 IP 192.168.4.2.45624 > 192.168.4.1.domain: 41269+ AAAA? www.google.com. (32) 15:23:39.429237 IP 192.168.4.1.domain > 192.168.4.2.45624: 46806 5/0/0 A 173.194.42.211, A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210 (112) 15:23:39.429278 IP 192.168.4.1.domain > 192.168.4.2.45624: 41269 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.430923 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788592 ecr 0,nop,wscale 4], length 0 15:23:42.433559 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788893 ecr 0,nop,wscale 4], length 0 15:23:48.443398 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2789494 ecr 0,nop,wscale 4], length 0
Seguiré revisando ...
Parece claro que los paquetes no pasan del servidor.
Manda la salida de "ip addr", "ip route show", "ip route show table vpn" y "ip rule show".
ip addr :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.4.1/28 brd 192.168.4.15 scope global eth4 inet6 fe80::6ef0:49ff:fe0f:b795/64 scope link valid_lft forever preferred_lft forever 7: eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.7.1/28 brd 192.168.7.15 scope global eth5 inet6 fe80::208:54ff:fe36:c9f9/64 scope link valid_lft forever preferred_lft forever 9: eth7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1444 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.0.12/24 brd 192.168.0.255 scope global eth7 inet6 fe80::200:24ff:fec9:ceda/64 scope link valid_lft forever preferred_lft forever 24: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1396 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet 192.161.173.24 peer 192.161.173.3/32 scope global ppp0
ip route show:
192.161.173.3 dev ppp0 proto kernel scope link src 192.161.173.24 192.161.173.2 via 192.168.0.1 dev eth7 src 192.168.0.12 192.168.7.0/28 dev eth5 proto kernel scope link src 192.168.7.1 192.168.4.0/28 dev eth4 proto kernel scope link src 192.168.4.1 192.168.0.0/24 dev eth7 proto kernel scope link src 192.168.0.12 169.254.0.0/16 dev eth4 scope link metric 1006 169.254.0.0/16 dev eth5 scope link metric 1007 169.254.0.0/16 dev eth7 scope link metric 1009 default via 192.168.0.1 dev eth7
ip route show table vpn:
default via 192.161.173.3 dev ppp0
ip rule show: 0: from all lookup local 32765: from 192.168.4.2 lookup vpn 32766: from all lookup main 32767: from all lookup default
En cuanto a la gateway X.Y.Z.W, y teniendo en cuenta que dijiste que no
sabes la IP del otro extremo de la VPN hasta que te conectas, usa la IP de la interfaz ppp0.
mmm... respecto de este tema, estaba pensando en un script que "extrae" ese ip, pero, según mi caso, tendré que aplicar una regla dinámica, a mi ruta vpn, por cada conexión o reconexión.... la idea es que la red 192.168.4.X siempre salga a internet por la interfaz ppp0 ...
Slds.
Posdata: acote el problema a solamente un cliente, a radxa.-
Reitero mis agradecimientos por tu tiempo y disposición.... Muchas Gracias !!!
Gracias !!!
De nada.
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
2014-05-30 11:34 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 30/05/2014 15:49, James Dean escribió:
2014-05-30 4:46 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 21:27, James Dean escribió:
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer
las
pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder
al
cliente.
¿Desde donde accedes a radxa? Si accedes desde la red 192.168.7.X es normal que te suceda con las reglas que habíamos aplicado. Todo el trafico saliente de la red 192.168.4.0 es enviado a la gateway X.Y.Z.W. Si quieres que estas dos redes se comuniquen añade una regla que lo permita en la tabla vpn. Sería algo como:
Al radxa accedo desde la red 192.168.7.X
ip route add 192.168.7.0/24 via 192.168.7.1 dev eth0 table vpn
Ok, sin embargo ahora únicamente el cliente radxa (192.168.4.2) es el que esta en la ruta vpn, y puedo acceder a el desde 192.168.7.X sin problemas ni con la necesidad de agregar ninguna ruta adicional...
Raro. Creo que podrías tener ese comportamiento si haces NAT de salida en la eth4 del server (192.168.4.1). Si no sabría decirte. Habría que investigar más.
Olvidé pedirte también la salida de "ip route show table local"
aquí esta :
broadcast 192.168.7.0 dev eth5 proto kernel scope link src 192.168.7.1 local 192.161.173.24 dev ppp0 proto kernel scope host src 192.161.173.24 broadcast 192.168.0.255 dev eth7 proto kernel scope link src 192.168.0.12 local 192.168.7.1 dev eth5 proto kernel scope host src 192.168.7.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 local 192.168.0.12 dev eth7 proto kernel scope host src 192.168.0.12 broadcast 192.168.4.15 dev eth4 proto kernel scope link src 192.168.4.1 broadcast 192.168.4.0 dev eth4 proto kernel scope link src 192.168.4.1 local 192.168.4.1 dev eth4 proto kernel scope host src 192.168.4.1 broadcast 192.168.0.0 dev eth7 proto kernel scope link src 192.168.0.12 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 192.168.7.15 dev eth5 proto kernel scope link src 192.168.7.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Gracias !!!
desde radxa no pude acceder a internet, al ejecutar en radxa 'lynx www.google.com' se queda pegado... y en el server centos se ve :
tcpdump -i eth4 not port 22
15:23:39.372159 IP 192.168.4.2.44039 > 192.168.4.1.domain: 49003+ A? www.google.com. (32) 15:23:39.372189 IP 192.168.4.2.44039 > 192.168.4.1.domain: 48077+ AAAA? www.google.com. (32) 15:23:39.398117 IP 192.168.4.1.domain > 192.168.4.2.44039: 49003 5/0/0
A
173.194.42.211, A 173.194.42.210, A 173.194.42.208, A 173.194.42.209, A 173.194.42.212 (112) 15:23:39.398172 IP 192.168.4.1.domain > 192.168.4.2.44039: 48077 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.426042 IP 192.168.4.2.60032 > 192.168.4.1.domain: 51490+ A? www.google.com. (32) 15:23:39.426064 IP 192.168.4.2.60032 > 192.168.4.1.domain: 55927+ AAAA? www.google.com. (32) 15:23:39.426157 IP 192.168.4.1.domain > 192.168.4.2.60032: 51490 5/0/0
A
173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210, A 173.194.42.211 (112) 15:23:39.426221 IP 192.168.4.1.domain > 192.168.4.2.60032: 55927 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.429146 IP 192.168.4.2.45624 > 192.168.4.1.domain: 46806+ A? www.google.com. (32) 15:23:39.429177 IP 192.168.4.2.45624 > 192.168.4.1.domain: 41269+ AAAA? www.google.com. (32) 15:23:39.429237 IP 192.168.4.1.domain > 192.168.4.2.45624: 46806 5/0/0
A
173.194.42.211, A 173.194.42.212, A 173.194.42.209, A 173.194.42.208, A 173.194.42.210 (112) 15:23:39.429278 IP 192.168.4.1.domain > 192.168.4.2.45624: 41269 1/0/0
AAAA
2800:3f0:4003:800::1012 (60) 15:23:39.430923 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788592 ecr 0,nop,wscale 4], length 0 15:23:42.433559 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2788893 ecr 0,nop,wscale 4], length 0 15:23:48.443398 IP 192.168.4.2.56098 > scl03s05-in-f19.1e100.net.http: Flags [S], seq 3747597655, win 14600, options [mss 1460,sackOK,TS val 2789494 ecr 0,nop,wscale 4], length 0
Seguiré revisando ...
Parece claro que los paquetes no pasan del servidor.
Manda la salida de "ip addr", "ip route show", "ip route show table vpn" y "ip rule show".
ip addr :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state
UP qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.4.1/28 brd 192.168.4.15 scope global eth4 inet6 fe80::6ef0:49ff:fe0f:b795/64 scope link valid_lft forever preferred_lft forever 7: eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state
UP qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.7.1/28 brd 192.168.7.15 scope global eth5 inet6 fe80::208:54ff:fe36:c9f9/64 scope link valid_lft forever preferred_lft forever 9: eth7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1444 qdisc pfifo_fast
state
UNKNOWN qlen 1000 link/ether brd ff:ff:ff:ff:ff:ff inet 192.168.0.12/24 brd 192.168.0.255 scope global eth7 inet6 fe80::200:24ff:fec9:ceda/64 scope link valid_lft forever preferred_lft forever 24: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1396 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet 192.161.173.24 peer 192.161.173.3/32 scope global ppp0
ip route show:
192.161.173.3 dev ppp0 proto kernel scope link src 192.161.173.24 192.161.173.2 via 192.168.0.1 dev eth7 src 192.168.0.12 192.168.7.0/28 dev eth5 proto kernel scope link src 192.168.7.1 192.168.4.0/28 dev eth4 proto kernel scope link src 192.168.4.1 192.168.0.0/24 dev eth7 proto kernel scope link src 192.168.0.12 169.254.0.0/16 dev eth4 scope link metric 1006 169.254.0.0/16 dev eth5 scope link metric 1007 169.254.0.0/16 dev eth7 scope link metric 1009 default via 192.168.0.1 dev eth7
ip route show table vpn:
default via 192.161.173.3 dev ppp0
ip rule show: 0: from all lookup local 32765: from 192.168.4.2 lookup vpn 32766: from all lookup main 32767: from all lookup default
En cuanto a la gateway X.Y.Z.W, y teniendo en cuenta que dijiste que no
sabes la IP del otro extremo de la VPN hasta que te conectas, usa la IP de la interfaz ppp0.
mmm... respecto de este tema, estaba pensando en un script que "extrae"
ese
ip, pero, según mi caso, tendré que aplicar una regla dinámica, a mi ruta vpn, por cada conexión o reconexión.... la idea es que la red 192.168.4.X siempre salga a internet por la interfaz ppp0 ...
Slds.
Posdata: acote el problema a solamente un cliente, a radxa.-
Reitero mis agradecimientos por tu tiempo y disposición.... Muchas
Gracias
!!!
Gracias !!!
De nada.
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Francesc Guitart _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
El 30/05/2014 17:38, James Dean escribió:
2014-05-30 11:34 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 30/05/2014 15:49, James Dean escribió:
2014-05-30 4:46 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 21:27, James Dean escribió:
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer
las
pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder
al
cliente.
¿Desde donde accedes a radxa? Si accedes desde la red 192.168.7.X es normal que te suceda con las reglas que habíamos aplicado. Todo el trafico saliente de la red 192.168.4.0 es enviado a la gateway X.Y.Z.W. Si quieres que estas dos redes se comuniquen añade una regla que lo permita en la tabla vpn. Sería algo como:
Al radxa accedo desde la red 192.168.7.X
ip route add 192.168.7.0/24 via 192.168.7.1 dev eth0 table vpn
Ok, sin embargo ahora únicamente el cliente radxa (192.168.4.2) es el que esta en la ruta vpn, y puedo acceder a el desde 192.168.7.X sin problemas ni con la necesidad de agregar ninguna ruta adicional...
Raro. Creo que podrías tener ese comportamiento si haces NAT de salida en la eth4 del server (192.168.4.1). Si no sabría decirte. Habría que investigar más.
Olvidé pedirte también la salida de "ip route show table local"
aquí esta :
broadcast 192.168.7.0 dev eth5 proto kernel scope link src 192.168.7.1 local 192.161.173.24 dev ppp0 proto kernel scope host src 192.161.173.24 broadcast 192.168.0.255 dev eth7 proto kernel scope link src 192.168.0.12 local 192.168.7.1 dev eth5 proto kernel scope host src 192.168.7.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 local 192.168.0.12 dev eth7 proto kernel scope host src 192.168.0.12 broadcast 192.168.4.15 dev eth4 proto kernel scope link src 192.168.4.1 broadcast 192.168.4.0 dev eth4 proto kernel scope link src 192.168.4.1 local 192.168.4.1 dev eth4 proto kernel scope host src 192.168.4.1 broadcast 192.168.0.0 dev eth7 proto kernel scope link src 192.168.0.12 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 192.168.7.15 dev eth5 proto kernel scope link src 192.168.7.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Gracias !!!
Pues las tablas parecen estar bien. ¿Como tienes iptables configurado?
Pasa la salida de "iptables -L -n"
El 30/05/2014 18:48, Francesc Guitart escribió:
El 30/05/2014 17:38, James Dean escribió:
2014-05-30 11:34 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 30/05/2014 15:49, James Dean escribió:
2014-05-30 4:46 GMT-04:00 Francesc Guitart fguitart@gmx.com:
El 29/05/2014 21:27, James Dean escribió:
ufff... hice todo y no pude ingresar al cliente 192.168.4.2 para poder hacer
las
pruebas... luego aplique 'ip rule del from 192.168.4.0/28 table vpn' y posteriormente 'ip rule add from 192.168.4.2 table vpn' y pude acceder
al
cliente.
¿Desde donde accedes a radxa? Si accedes desde la red 192.168.7.X es normal que te suceda con las reglas que habíamos aplicado. Todo el trafico saliente de la red 192.168.4.0 es enviado a la gateway X.Y.Z.W. Si quieres que estas dos redes se comuniquen añade una regla que lo permita en la tabla vpn. Sería algo como:
Al radxa accedo desde la red 192.168.7.X
ip route add 192.168.7.0/24 via 192.168.7.1 dev eth0 table vpn
Ok, sin embargo ahora únicamente el cliente radxa (192.168.4.2) es el que esta en la ruta vpn, y puedo acceder a el desde 192.168.7.X sin problemas ni con la necesidad de agregar ninguna ruta adicional...
Raro. Creo que podrías tener ese comportamiento si haces NAT de salida en la eth4 del server (192.168.4.1). Si no sabría decirte. Habría que investigar más.
Olvidé pedirte también la salida de "ip route show table local"
aquí esta :
broadcast 192.168.7.0 dev eth5 proto kernel scope link src 192.168.7.1 local 192.161.173.24 dev ppp0 proto kernel scope host src 192.161.173.24 broadcast 192.168.0.255 dev eth7 proto kernel scope link src 192.168.0.12 local 192.168.7.1 dev eth5 proto kernel scope host src 192.168.7.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 local 192.168.0.12 dev eth7 proto kernel scope host src 192.168.0.12 broadcast 192.168.4.15 dev eth4 proto kernel scope link src 192.168.4.1 broadcast 192.168.4.0 dev eth4 proto kernel scope link src 192.168.4.1 local 192.168.4.1 dev eth4 proto kernel scope host src 192.168.4.1 broadcast 192.168.0.0 dev eth7 proto kernel scope link src 192.168.0.12 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 192.168.7.15 dev eth5 proto kernel scope link src 192.168.7.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Gracias !!!
Pues las tablas parecen estar bien. ¿Como tienes iptables configurado?
Pasa la salida de "iptables -L -n"
Otra sugerencia: usa ip route get para debugar que ruta toman los paquetes.
ip route get to 8.8.8.8 from 192.168.4.2 iif eth4
ip route get to ip_destino from ip_origen iif eth_donde_se_recibe_la_petición
-
César Martinez -
Francesc Guitart -
James Dean