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 <bond...@gmail.com>: > > 2014-05-29 12:25 GMT-04:00 Francesc Guitart <fguit...@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 >> > > _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
