# [net] LAN inservible (abierto)

## the incredible hurd

Hay muchos otros mensajes en el foro relacionados con este asunto, pero en ninguno se aportan soluciones.

Tengo dos máquinas, una es 192.168.0.1 y la otra es 192.168.0.2; en ambos casos es net.eth1; a la máquina que hará de router (192.168.0.1) net.eth0 es el proporcionado por mi ISP y lo hace via dhcp (uso dhcpcd). Ambas se ven la una a la otra y puedo hacer esto desde cada una:

```

$ ping -c5 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.06 ms

64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.255 ms

64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.333 ms

64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.255 ms

64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.341 ms

--- 192.168.0.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4001ms

rtt min/avg/max/mdev = 0.255/0.450/1.066/0.310 ms

$ ping -c5 192.168.0.2

PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.

64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.293 ms

64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.387 ms

64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.252 ms

64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=0.381 ms

64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=0.258 ms

--- 192.168.0.2 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4001ms

rtt min/avg/max/mdev = 0.252/0.314/0.387/0.059 ms

```

 */etc/conf.d/net wrote:*   

> 
> 
> # This blank configuration will automatically use DHCP for any net.*
> 
> # scripts in /etc/init.d.  To create a more complete configuration,
> ...

 

En el anfitrión, pero ni con lo comentado ni sin comentar funciona.

En la otra máquina tanto con

routes_eth1=( "default gw 192.168.0.1" )

como sin él no funciona. Por supuesto, sólo cambia que es la 192.168.0.2

Mis reglas iptables para la LAN

```

# LAN

/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

/sbin/iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

/sbin/iptables -A FORWARD -j BLOCK

```

La parte interesante de /etc/sysctl.conf en el anfitrión o la máquina que hace el NAT:

net.ipv4.ip_forward = 1

¿Qué más me queda por hacer?

¡Ah!, instalar un servidor dhcp no me parece ni razonable ni aconsejable en este caso.

----------

## Inodoro_Pereyra

A ver si puedo ayudar, no entiendo que parte es la que no funciona puntualmente, voy a suponer que lo que no funciona es internet en .0.2 así que vamos por partes:

- ping desde .0.2 a .0.1 funciona, entonces hay conectividad.

- Las reglas de iptables esas, aun que básicas deberían hacer su trabajo. Para saber si el ruteo funciona, ping a un número de IP conocido (google, por ej.): 74.125.45.100

- Si se puede hacer ping al número de IP de google, entonces falla la resolución de DNS y puede ser por diversas causas. Postea el resultado de esa prueba básica y de ahí en mas vemos como sigue la cosa.

Salud!

----------

## the incredible hurd

ping desde 0.2

```

$ ping -c5 74.125.45.100

PING 74.125.45.100 (74.125.45.100) 56(84) bytes of data.

From 192.168.0.2 icmp_seq=2 Destination Host Unreachable

From 192.168.0.2 icmp_seq=3 Destination Host Unreachable

From 192.168.0.2 icmp_seq=4 Destination Host Unreachable

From 192.168.0.2 icmp_seq=5 Destination Host Unreachable

--- 74.125.45.100 ping statistics ---

5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4002ms

, pipe 3

```

Ya que mencionas la resolución de DNS, eché un vistazo a /etc/resolv.conf:

 */etc/resolv.conf wrote:*   

> 
> 
> # Generated by dhcpcd
> 
> # /etc/resolv.conf.head can replace this line
> ...

 

Por lo que puse los mismos nameserver que en 0.1 y obtenía los mismos resultados con el ping a google. Para probar lo último que se me pasó por la cabeza puse como nameserver 192.168.0.1, pero tampoco.

Antes quería decir que no quería instalar un servidor DNS, supongo, y no DHCP, aunque no sé, tengo tal lío que empiezo a no ver nada con claridad; que una cosa tan sencilla me esté resultando tan complicado... debe ser por cualquier pequeña cosa que he pasado por alto seguramente, pero no soy capaz de imaginar cuál  :Confused: 

----------

## Condex

Hola!

En mi caso, las máquinas que usan la conexión a Internet del «servidor», están configuradas como las tuyas, o sea:

```
config_eth0=( "192.168.0.32 netmask 255.255.255.0 brd 192.168.0.255" )

routes_eth0=( "default via 192.168.0.1" )
```

Por lo que tienes una configuración de red similar a la mía, aunque yo uso Shorewall para configurar IPTables, me doy mejor con él  :Smile:  . Me había guiado por esta guía: Home Router Guide

Uno de los pasos de esa guía incluye la instalación de un pequeño servidor DHCP(servicio que no uso, tengo las IP a mano) y que además hace de servidor DNS: net-dns/dnsmasq y se pone en la máquina(.0.2) como nameserver el 192.168.0.1. O sea, lo que habías probado, pero al no haber un DNS en la 0.1 pues no funcionaba  :Wink: 

He probado en otro de los equipos de la red lo que habías probado, a meterle en el /etc/resolv.conf el nameserver que está ahora en el router y a desactivar mi dnsmasq y sí que me resuelve correctamente las IP, así que el fallo debe estar en otra parte  :Confused: 

A ver si echando un ojo a la guía de arriba consigues algo más  :Wink: 

Nos leemos,

Condex-  :Cool: 

----------

## Coghan

Tienes habilitado el forwarding en el kernel?

 */etc/sysctl.conf wrote:*   

> net.ipv4.ip_forward = 1

 

----------

## the incredible hurd

@Coghan: Si, lo mencioné en el primer mensaje. A propósito, es /etc/sysctl.conf

@Condex: Ya la había consultado, aunque la versión en español: Guía de enrutamiento doméstico. La única opción que creo que me queda es lo que dice en Imposible conectar dos máquinas directamente. Aunque ese cable me ha servido para conectar el portatil al servidor sin problemas, puede que la tarjeta de red del cliente no sea inteligente y necesite el cable cruzado. Compraré uno para probar, como última opción. No tengo ni idea de si mi cable es cruzado o no, vino de regalo con alguno de los equipos.

El servidor tiene una 

 *Quote:*   

> 
> 
> Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
> 
> Kernel driver in use: e1000e
> ...

 

El cliente tiene una

 *Quote:*   

> 
> 
> Bridge: nVidia Corporation MCP2A Ethernet Controller (rev a3)
> 
> Kernel driver in use: forcedeth
> ...

 

En el portatil también tengo una nVidia con forcedeth pero se trata de otro modelo. Aunque no lo tengo por aquí y no lo recuerdo exactamente. La tarjeta del cliente es 10/100, aunque no creo que eso suponga ningún problema, pero la del portatil también es de 1Gb.

Por si alguien ve algo raro, dejo algunos datos más:

En el servidor:

```

# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

89.141.68.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         89.141.68.1     0.0.0.0         UG    0      0        0 eth0

```

En el cliente:

```

# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth1

```

----------

## Coghan

 *Quote:*   

> @Coghan: Si, lo mencioné en el primer mensaje. A propósito, es /etc/sysctl.conf 

 

Perdón por no haber leído mejor el post.   :Embarassed: 

Por otro lado veo que enmascaras la salida del interface eth1

```
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE 
```

 cuando la salida hacia internet es eth0

```
0.0.0.0         89.141.68.1     0.0.0.0         UG    0      0        0 eth0 
```

----------

## the incredible hurd

Enmascaro la salida de eth1 para que mi ISP no note nada, ¿para qué querría enmascarar la salida a internet o eth0?

Esa fue mi lógica.

Cambiando el script a

```

# /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

/sbin/iptables -P FORWARD ACCEPT

/sbin/iptables -t nat -P PREROUTING ACCEPT

/sbin/iptables -t nat -P POSTROUTING ACCEPT

```

Tampoco funciona.

Espero obtener cables nuevos en un día, mañana cuento.

Por lo que leo por ahí, mi ISP hace todo lo posible para que nadie haga lo que yo pretendo sin router (y cobrar los servicios según el número de equipos que se conecten supongo), pero no quiero comprárselo, así de simple. Mi cable modem está funcionando al 50% de su capacidad real, todavía daría mucho más de sí...

¡Ah! Mi ISP es ONO, para más señas.

----------

## opotonil

 *Quote:*   

> 
> 
> Enmascaro la salida de eth1 para que mi ISP no note nada, ¿para qué querría enmascarar la salida a internet o eth0?
> 
> Esa fue mi lógica. 
> ...

 

Hombre yo entiendo que la que tienes que enmascarar es eth0 para que todas las peticiones que hagas a internet sepan a que IP tienen que enviar la contestacion.

Por asi decirlo, tu haces una peticion a google sin enmascarar asi que al servidor de google le llega una peticion desde 192.168.1.x que es un rango privado... no sabra a donde tiene que enviar la contestacion. En cambio al enmascarar la IP le llegara desde tu IP publica y a esa IP si que puede contestar.

Salud2.

PD: Creo que no pero si estoy equivocado corregirme.

--- EDITADO ---

Creo que ya entendi y que todo lo anterior sobraba.

Por lo que entiendo al hacer:

```

/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

```

estas pretendiendo que todo lo que salga por eth1 sea enmascarado aparentando que la IP de origen es 89.141.68.1 (tu IP publica) el problema es que lo anterior lo que hace es decir que todo lo que sale por eth1 sea enmascarado aparentando que la IP de origen es 192.168.0.1 (tu IP privada del equipo anfitrion)

Lo que hace el masquerade de iptables es que todo lo que salga por la interface enmascarada aparente tener como IP de origen la misma de la interface enmascarada. de forma que lo que necesitas es:

```

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

```

Por otra parte, en cuanto al cable modem de ONO ¿ha tenido conectada anteriormente alguna otra tarjeta de red, desde la ultima vez que se encendio? porque recuerda la mac... si no estas seguro apaga el cable modem unos 20 - 30 segundos y enciendelo.

Si es un Motorola SB5101E, con otros no se si vale, puedes comprobar la mac que tiene asociada accediendo a el por http a la IP 192.168.100.1 en la seccion addresses, el valor que te interesa es el "Learned" de la tabla "Known CPE MAC Address"

Salu2.

----------

## ZaPa

Hola a todos...

Veamos..¿Lo que intentas, es conectar Pc2 y Pc1 con un cable de red directo? ¿sin switch ni nada por enmedio,no?

Si es asi..posiblemente sea problema del cable como has dicho tu anteriormente,necesitazarás un cable cruzado si quieres hacer eso.

¿Has probado a colocar un switch entre pc1 y pc2?¿para descartar lo del cable?

A mi me pasó algo similar con un p4 que tengo haciendo de router tambien..y al final,era cosa del cable que al parecer, una tarjeta de red funcionaba a 100mbs y la otra hacia el auto-negotiation y se ponia a 10mbs automaticamente y al parecer una de las tarjetas no era full duplex..

Calculo que tambien podria ser tu problema.

Podrias cambiar las dns de tu pc2 (el archivo /etc/nameserver), puedes probar colocando estas dns:

```

nameserver 80.58.61.250

nameserver 80.58.61.254

```

Otro dato a tener en cuenta....

En el servidor que tengo funcionando en casita, tengo una tarjeta de red conectada al cablemodem (logico xD) pero esa tarjeta de red, coje la dirección ip y dns por dhcp del cablemodem, tu, si no me equivoco le estas fijando la ip (192.168.0.1),no? 

Seria...

eth0 ---> cable modem ono --OBTIENE DIRECCIÓN IP Y DNS POR DHCP--

eth1 ---> tarjeta de red que utilizaremos para nuestra red local (aqui ya definimos nuestros rangos de red)..

Ahora queria realizárte yo una consulta, si es posible... yo tambien tengo ono y tengo un p4 haciendo de servidor (como he dicho arriba), y tengo de ono un cablemodem (como tú), y con iptables, no tengo ninguna regla para ono...

```

/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE 

```

No entiendo mucho de iptables (por no decir casi nada), y por curiosidad..me gustaria saber que es lo que hace esa regla de cara al isp (en este caso ono) enmascarar el tráfico? ¿que significa eso?

Un saludo.

----------

## the incredible hurd

 *ZaPa wrote:*   

> En el servidor que tengo funcionando en casita, tengo una tarjeta de red conectada al cablemodem (logico xD) pero esa tarjeta de red, coje la dirección ip y dns por dhcp del cablemodem, tu, si no me equivoco le estas fijando la ip (192.168.0.1),no? 
> 
> Seria...
> 
> eth0 ---> cable modem ono --OBTIENE DIRECCIÓN IP Y DNS POR DHCP--
> ...

 

Hola:

Por partes y desde el principio, no tengo ninguna tarjeta de red conectada al cablemodem, el cablemodem es un interfaz de red en sí, en mi caso funciona con cdc_ether y, a pesar de tener interfaz para conectarlo a una tarjeta de red lo tengo via USB, desde el principio... La razón es que todas las tarjetas de red que tenía eran 100/10 y con USB2.0 tenía unos supuestos 400Mb/s (que nunca ha llegado a alcanzar, todo hay que decirlo). Así pues, nunca mejor dicho, eth0 es el cable modem ono como bien comentas.

Entonces estás sin firewall, bajo tu cuenta y riesgo, a no ser que también uses windows y hayas activado eso del pasaporte ono y del firewall y antivirus que te proporcionan ellos. Yo no lo he hecho y no tengo ni idea de como se hace.

Uso iptables, la guía verdaderamente rápida de Rusty para el filtrado de paquetes. Con ello cierras todos los puertos, sólo puedes establecer conexiones tú, pero nadie desde internet podrá establecer una conexión contigo (tal y como ahora podría hacer cualquiera libremente; hasta ahora, con iptables he tenido dos o tres dictionary attacks infructuosos, pero los he tenido e iptables les ha cerrado la puerta principal.

Después he ido añadiendo a esas reglas más y más, como la necesaria para abrir el puerto para bittorrent y compartir los torrents de debian y gentoo-2008-r1, hela aquí:

```

# bittorrent

/sbin/iptables -I BLOCK -p tcp --dport 6881 -j ACCEPT

```

La inserto (-I) en BLOCK que es la cadena que crea Rusty Russell para "bloquear" entradas y le digo que acepte (-j ACCEPT) que todo el mundo pueda entrar por ese puerto (--dport 6881) y con el protocolo TCP (-p tcp).

Con

```

/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE 

```

pretendo decirle que en la tabla (-t) de traducción de direcciones de red (nat o Network Address Translation), todo el enrutamiento posterior (-A POSTROUTING) que se haga saliendo por la interfaz eth1 (ahora sí, la tarjeta de red) debe quedar enmascarado, oculto. Mi ISP no debe enterarse de que hay dos (o más) máquinas pidiendo paquetes; el servidor les establece la ruta adecuada a esos paquetes. Y en ono sólo ven una máquina pidiendo y enviando montones de paquetes. Pero para eso les pagamos, ¿no?

Aunque hay quien piensa, como ya habrás visto un poco más arriba, que me equivoco; pero tengo esas reglas en otras máquinas de la empresa y te aseguro que funcionan perfectamente así y sigo sin verle ningún sentido a enmascarar el interfaz con el que te conectas a internet.

Espero haberme explicado bien, ni quiero ni pretendo entrar en detalles, porque terminaría escribiendo un libro... Hay muchos frontends para iptables, si al principio te asustan un poco, pero echa un vistazo a Documentation about the netfilter/iptables project, también disponible en castellano y poco a poco acabarás usándolas directamente sin ningún tipo de frontend o interfaz ya sea gráfico o no. Al menos, eso es lo que me ha pasado a mí.

Saludos.

----------

## Inodoro_Pereyra

Se ha vuelto un poco confuso el hilo, no termino de entender si ya has podido solucionar el problema o no, pero tanto optonil como txema tienen razón. Se hace NAT sobre la interface WAN que en su caso señor de verde es eth0 y no eth1. (-j MASQUERADE sobre eth0).

Tampoco puede ser problema de cables si ping va y viene sin problemas...

Se que vengo llegando tarde pero si todavía no has podido solucionarlo y puedo ayudar en algo, encantado.

Salud!

----------

## the incredible hurd

 *Inodoro_Pereyra wrote:*   

> Se ha vuelto un poco confuso el hilo, no termino de entender si ya has podido solucionar el problema o no, pero tanto optonil como txema tienen razón. Se hace NAT sobre la interface WAN que en su caso señor de verde es eth0 y no eth1. (-j MASQUERADE sobre eth0).

 

eth0, bien, ¿pero con -i o con -o?

¿Que script de iptables pondrías tú?

 *Inodoro_Pereyra wrote:*   

> Tampoco puede ser problema de cables si ping va y viene sin problemas...

 

Eso mismo pensé yo antes de comprar cables quizá innecesarios.

Ah, este es mi script de iptables por ahora:

```

#!/bin/bash

/sbin/iptables -N BLOCK

/sbin/iptables -A BLOCK -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A BLOCK -m state --state NEW ! -i eth0 -j ACCEPT

/sbin/iptables -A BLOCK -j DROP

/sbin/iptables -A INPUT -j BLOCK

# LAN

# /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

/sbin/iptables -P FORWARD ACCEPT

/sbin/iptables -t nat -P PREROUTING ACCEPT

/sbin/iptables -t nat -P POSTROUTING ACCEPT

/sbin/iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

/sbin/iptables -A FORWARD -j BLOCK

# bittorrent

/sbin/iptables -I BLOCK -p tcp --dport 6881 -j ACCEPT

```

A ver si es que estoy haciendo alguna chorrada sin darme cuenta...

Tranquilo, que el día que lo consiga añadiré un (cerrado) a la cabecera del hilo.

----------

## Inodoro_Pereyra

Si me preguntas que script de iptables usaría siendo que estamos diagnosticando, lo básico:

```
iptables -F

iptables -t nat -F

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP #<-- Este es importante, tu política de forward por defecto es accept, debería ser drop con lo que, como diría microsoft: "un usuario mal intencionado" podría malformar un paquete falsificando el número de saltos para traspasar tu firewall.

# Hasta ahí limpieza general, ahora, darle internet a tu/s otra/s pc:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward #<-- Este solo para recordarte, por las dudas.
```

Sólo con eso ya deberías poder rutear tráfico a internet desde la segunda pc.

Podés confirmarlo con ping a un número de IP conocido previo haber verificado conectividad entre las dos pc ping entre ellas de por medio.

```
ping 74.125.127.100 #<-- Google
```

Si hasta aquí viene todo bien, ping al nombre de dominio:

```
ping google.com
```

Además de estar haciendo NAT al revez no veo ninguna otra cosa mal en tu script (pero es temprano y todavía no tengo café en las venas como para pensar con claridad  :Very Happy: ).

Si de esa forma funciona, podrías o bien seguir de ahi en adelante segurizando el resto o probar de nuevo con tu script pero haciendo masquerade sobre eth0 (con -o sobre postrouting, es decir, cuando la tabla de ruteo indica que el paquete no pertenece a la misma subred en que se encuentra la interface LAN y se ha tomado ya la decisión de ruteado -leasé POSTROUTING- y dicha decisión implica que la interface de salida es eth0, tu WAN, entonces si -j MASQUERADE, para que se entienda).

Salud!

----------

