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