Forums:
Hola a todos
Tengo problemas al utilizar un linux como router de IPs publicas, no voy a utilizar NAT ya que las IPs si son ruteables.
El esquema es el siguiente
Internet <--> eth2 {router} eth0 <--> subnet ips publicas
la eth2 esta configura de la siguiente forma:
ip: x.y.206.126
netmask: 255.255.255.192
gateway: x.y.206.65
la eth0 con la siguiente informacion
ip: x.y.112.71
netmask: 255.255.255.240
el parametro ip_forward esta habilitado
root@router:~# cat /proc/sys/net/ipv4/ip_forward
1
lo extraño es que esas ips no responden cuando hago ping desde una eth que no este dentro de la propia red ... me explico con un ejemplo
root@centHost:~# ping -I eth0 x.y.206.126
PING x.y.206.126 (x.y.206.126) from x.y.112.71 eth0: 56(84) bytes of data.
From x.y.112.71 icmp_seq=1 Destination Host Unreachable
From x.y.112.71 icmp_seq=2 Destination Host Unreachable
From x.y.112.71 icmp_seq=3 Destination Host Unreachable
--- x.y.206.126 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4005ms, pipe 4
con el caso contrario pasa lo siguiente
root@centHost:~# ping -I eth2 x.y.112.71
PING x.y.112.71 (x.y.112.71) from x.y.206.126 eth2: 56(84) bytes of data.
From 10.0.134.1 icmp_seq=1 Time to live exceeded
From 10.0.134.1 icmp_seq=2 Time to live exceeded
From 10.0.134.1 icmp_seq=3 Time to live exceeded
--- x.y.112.71 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3006ms, pipe 2
no se si me halla comido un paso, si este es el caso quedaria muy agradecido con quien pueda ayudarme en este tema.
Gracias.
No entiendo uno de tus
No entiendo uno de tus ejemplos.
El primero especifica usar la interfaz eth0 para hacer ping a una máquina que está del lado de eth2. Como es de esperarse, te dan dedo porque no puede alcanzar al destino por esa interfaz.
El segundo no estoy seguro, pero según entiendo el paquete saldrá por eth2, llegará a tu gateway que te lo manda de vuelta, y luego debería coincidir con la entrada en tu tabla de ruteo para eth0 y salir por ahí. Alguno de estos pasos falla y el paquete está dando vueltas hasta que se termina su ttl. Según tu default gw, ¿quién es el siguiente salto para x.y.112.71? ¿Has visto con qué valor de ttl sale tu ping inicialmente?
hola, gracias por tu
hola, gracias por tu comentario. La eth0 y eth2 son tarjetas de red que estan conectadas a mi router linux. Lo que quiero lograr es que me responda un ping de una interface a otra. Deberia ser posible porque la tabla de ruteo del linux sabe como llegar a ambas redes
root@centHost:~# ip route
x.y.112.64/28 dev eth0 proto kernel scope link src x.y.112.71
x.y.206.64/26 dev eth2 proto kernel scope link src x.y.206.126
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.112
default via x.y.206.65 dev eth2 metric 100
segun mi logica, si se logra la comunicacion entre ambas interfaces, ya las otras maquinas que esten atras de la eth0 (rango x.y.112.64/28) podran navegar utilizando al x.y.112.71 como gateway. Pero supongo yo que algo mas debe faltar porque no me esta funcioando :D
gracias por tu ayuda.
Imagination is more important than Knowledge -- Albert Einstein
Errar es humano, pero para dañar las cosas realmente bien, pero bien de verdad, necesitas la contraseña de root.
Una mejor manera de hacer
Una mejor manera de hacer pruebas te puede ayudar. Como los pings de tus pruebas de arriba se les ha forzado a sacar los paquetes por una u otra interfaz vas a tener problemas. ¿Qué tal si haces pings desde una de las ips detrás de eth0 al gateway del ruteador y viceversa?
de la forma que tu indicas si
de la forma que tu indicas si hay ping entre la maquina con ip x.y.112.72 (una maquina que esta detras de la eth0 de mi router) y x.y.206.216, que vendria a ser la interface "externa" de mi router. Pero cuando trato de llegar al default gateway del router no responde nada
[root@elastix ~]# ping x.y.206.216
PING x.y.206.216 (x.y.206.216) 56(84) bytes of data.
64 bytes from x.y.206.216: icmp_seq=1 ttl=249 time=93.9 ms
64 bytes from x.y.206.216: icmp_seq=2 ttl=249 time=99.7 ms
--- x.y.206.216 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 93.981/96.847/99.714/2.883 ms
[root@elastix ~]# ping x.y.206.65
PING x.y.206.65 (x.y.206.65) 56(84) bytes of data.
--- x.y.206.65 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
pasa lo mismo cuando trato de llegar a cualquier ip publica ... podra ser problema en el router de mi proveedor.
gracias por la ayuda.
Imagination is more important than Knowledge -- Albert Einstein
Errar es humano, pero para dañar las cosas realmente bien, pero bien de verdad, necesitas la contraseña de root.
Es posible que el proveedor
Es posible que el proveedor esté bloqueando icmp en su red. ¿Puede tu router hacerle ping al gateway? ¿Puedes hacerle ping a www.google.com desde tu router? Otra forma de probar es haciendo una consulta dns o abriendo un puerto remoto con telnet.
Instala tcpdump en tu router y corre 'tcpdump -i eth2 -ln host x.y.112.72' haz los pings y ve si los paquetes salen.
desde mi router si puedo
desde mi router si puedo hacer ping a www.google.com y al x.y.206.65 (el gateway de mi router) pero desde la red x.y.112.64/28 solo se puede hacer ping a la ip x.y.206.126 ... de ahi para adelante no llega a ninguna parte
la informacion que tcpdump me bota es que el request icmp si pasa por el router, pero nunca regresa un icmp reply ... le hice ping a un servidor que yo administro aca en Ecuador y el ping si llega y obviamente responde, parece que el problema se da en la respuesta.
debo especificar que los equipos que estoy administrando son remotos, asi que he hecho un traceroute desde mi maquina hasta el router:
gabriel@malon:~$ traceroute -n x.y.206.126
traceroute to x.y.206.126 (x.y.206.126), 30 hops max, 60 byte packets
1 192.168.2.1 0.283 ms 0.259 ms 0.244 ms
2 172.27.21.1 1.957 ms 1.952 ms 2.270 ms
3 172.17.1.254 2.556 ms 2.544 ms 2.843 ms
4 172.17.1.28 4.687 ms 4.677 ms 4.664 ms
5 10.201.11.125 4.319 ms 4.311 ms 4.298 ms
6 10.201.11.182 5.852 ms 5.507 ms 5.491 ms
7 130.94.195.29 58.722 ms 57.306 ms 57.290 ms
8 129.250.2.161 57.929 ms 57.614 ms 57.598 ms
9 129.250.2.184 84.723 ms 84.826 ms 84.817 ms
10 129.250.2.89 85.173 ms 84.868 ms 84.854 ms
11 129.250.9.94 84.842 ms 84.027 ms 84.015 ms
12 84.16.15.121 188.479 ms 213.140.36.209 181.405 ms 84.16.15.121 183.203 ms
13 84.16.15.181 190.610 ms 213.140.36.73 197.933 ms 213.140.36.205 163.026 ms
14 84.16.8.118 196.685 ms 213.140.38.29 182.133 ms 84.16.8.114 199.589 ms
15 84.16.9.166 199.560 ms 84.16.8.118 190.919 ms 84.16.12.5 195.448 ms
16 84.16.9.166 205.812 ms 84.16.8.118 189.039 ms 81.46.44.70 207.063 ms
17 * 81.46.44.70 203.161 ms *
18 81.46.44.70 205.536 ms * *
19 x.y.206.126 245.617 ms 243.351 ms 238.682 ms
pero al hacer lo mismo con la ip x.y.112.71 no logra llegar.
gabriel@malon:~$ traceroute -n x.y.112.71
traceroute to x.y.112.71 (x.y.112.71), 30 hops max, 60 byte packets
1 192.168.2.1 0.269 ms 0.243 ms 0.226 ms
2 172.27.21.1 2.452 ms 2.446 ms 2.435 ms
3 172.17.1.254 3.023 ms 3.015 ms 3.003 ms
4 172.17.1.28 4.109 ms 4.382 ms 4.373 ms
5 10.201.11.125 4.362 ms 4.351 ms 4.296 ms
6 10.201.11.182 5.180 ms 5.078 ms 5.064 ms
7 130.94.195.29 58.419 ms 57.086 ms 57.065 ms
8 129.250.2.161 58.330 ms 57.785 ms 57.772 ms
9 129.250.2.184 86.067 ms 85.282 ms 86.087 ms
10 129.250.2.89 256.954 ms 256.949 ms 256.928 ms
11 129.250.9.94 86.038 ms 85.224 ms 85.209 ms
12 213.140.37.14 181.036 ms 213.140.36.209 173.370 ms 213.140.36.129 182.786 ms
13 213.140.36.73 203.620 ms 213.140.38.222 159.762 ms 213.140.36.73 202.278 ms
14 84.16.8.118 200.188 ms 84.16.8.114 193.153 ms 84.16.8.118 198.466 ms
15 80.58.87.42 201.595 ms 201.572 ms 206.022 ms
16 84.16.8.114 201.518 ms 81.46.44.70 203.548 ms 206.717 ms
17 * 80.58.87.42 205.568 ms *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
se ve que en la linea 11 toma una ruta diferente ... esto es normal? quisiera descartar o confirmar que se un problema de mi ISP.
gracias por su ayuda.
Imagination is more important than Knowledge -- Albert Einstein
Errar es humano, pero para dañar las cosas realmente bien, pero bien de verdad, necesitas la contraseña de root.
Para que todo tráfico
Para que todo tráfico funcione en dos vías tiene que haber 2 rutas (no necesariamente distintas): la de ide y la de vuelta. Si ves que los paquetes salen de tu router a internet entonces la ruta de ida está perfectamente bien.
Como ves que no llega respuesta, entonces es el regreso el que tiene problemas. Idealmente los paquetes deberían llegar mínimo al router de tu proveedor y llegarte e tí. Comunícate con ellos para que actualicen sus tablas de BGP y te declaren como gateway para esas redes. Eso va a tomar unas cuantas horas hasta que se transmita, pero con eso ya debería funcionar.
Hola Haber tu proveedor esta
Hola
Haber tu proveedor esta claro en lo que le pediste osea la ip publica declarada en tu eth0 es la puerta de enlace de tu sub red para el proveedor ej:
si tienes 200.200.200.0/24
digamos que esa sub red te dio xxxproveedor
y la ip de tu eth0 es 200.200.200.1 como gateway de las demas ips de esa sub red
entonces tu proveedor debe declarar que la sub red 200.200.200.0/24, el gateway es tu ip publica original osea la que tenías antes o la que tienes en eth2 que tu salida a internet.
Esto debes colocar en tu firewall:
# RED PUBLICA
$IPTABLES -A INPUT -p ALL -s 200.200.200.0/24 -j ACCEPT
$IPTABLES -A INPUT -p ALL -d 200.200.200.0/24 -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s 200.200.200.0/24 -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -d 200.200.200.0/24 -j ACCEPT
$IPTABLES -A FORWARD -p ALL -s 200.200.200.0/24 -j ACCEPT
$IPTABLES -A FORWARD -p ALL -d 200.200.200.0/24 -j ACCEPT
Vamos Ecuador, si se puede
Por defecto, los iptables
Por defecto, los iptables vienen en ACCEPT como política. No hace falta meterle mano a los iptables si lo que quieres es solo reenviar paquetes entre interfaces. Asumo que el dueño del post tiene sus iptables abiertas y vacías.
correcto yo no he puesto
correcto yo no he puesto ninguna regla en mi tabla de forwarding
Imagination is more important than Knowledge -- Albert Einstein
Errar es humano, pero para dañar las cosas realmente bien, pero bien de verdad, necesitas la contraseña de root.
Páginas