[CentOS-es] Problemas con Rutas

Francesc Guitart fguitart en gmx.com
Vie Mayo 30 15:34:04 UTC 2014


El 30/05/2014 15:49, James Dean escribió:
> 2014-05-30 4:46 GMT-04:00 Francesc Guitart <fguitart en 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 en centos.org
>> http://lists.centos.org/mailman/listinfo/centos-es
>>
> _______________________________________________
> CentOS-es mailing list
> CentOS-es en centos.org
> http://lists.centos.org/mailman/listinfo/centos-es
>




-- 
Francesc Guitart


Más información sobre la lista de distribución CentOS-es