|
|
|||
Gallery
Inicio de sesión
Apadrinamientos
Help raising the green bars with your donations!
Navegación
Comentarios recientes
- Proxys en la ciudad de Castellón
hace 2 años 10 semanas - supernodo
hace 2 años 11 semanas - Conexión nodo Bartolo
hace 3 años 7 semanas - Conexión nodo Bartolo
hace 3 años 11 semanas - Connectar un node.
hace 3 años 47 semanas - Por lo que parece hay gente
hace 4 años 8 semanas - Montornes/las palmas
hace 4 años 9 semanas - Montornes
hace 4 años 9 semanas - Ayuda
hace 4 años 12 semanas - Sigues por ahí?
hace 4 años 13 semanas
Buscar
Events
| Lun | Mar | Mié | Jue | Vie | Sáb | Dom |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tuneles con Ubiquity
(13/02/2011 actualizado con el masquerading en el Nano remoto)
(25/03/2013 actualizado con problemas y soluciones de Rafael Vicent sobre problemas debido a MTU)
Hola,
hace unos días en la lista de correo Pau planteó:
Mi caso es el siguiente. Estoy conectado a Guifi.net desde un nodo de Borriol, ahora salgo a internet por la UJI, pero voy a instalarle una antena en Castellón a mi madre que tiene ONO 50Mb.
La idea es utilizar esa conexión a internet desde mi nodo de Borriol.
mi PC ---> [mi (Nanobridge m5) ---> .... -----> mi madre (nanostation loco m5)] ----> router ono -----> internet
El resumen es la necesidad de establecer un tunel entre ambos nodos. Se planteaba la necesidad de instalar routers tipo Mikrotik para ser los puntos finales del tunel. Pero encontré que AirOS de Ubiquity tiene soporte para tunnelling con lo que se simplifica el montaje tal como quería Pau. Hoy he podido montar varios equipos para simular los aparatos participantes. Esta es la conclusión:
Supongamos las subredes y equipos:
Subred1:
la LAN de la ubicación remota (la casa de Pau): 192.168.10.0/24
PC1: 192.168.10.2 gw: 192.168.10.1
NanoBridge M5 (o cualquier otro dispositivo con AirOS):
LAN: 192.168.10.1 sobre el gateway hablaré luego, pero debe ser la 192.168.30.1
WLAN 10.20.1.10 / 27 (255.255.255.224) siendo el gateway de su subred guifi.net 10.20.1.1
Esto se puede configurar a través del GUI Web de AirOS.
debe estar en modo router y con NAT activado.
La ruta por defecto no puede ser el siguiente salto en guifi.net porque cualquier dirección de internet no puede ser alcanzada desde él. Por lo tanto la ruta por defecto debe ser el extremo del tunel que crearemos. Si además de usarse para llegar a la pasarela a internet se desea llegar a otros nodos de guifi.net se debería instalar una ruta estática través de la pasarela 10.20.1.1. En el script se incluirá.
Subred2:
la de la ubicación con la salida a internet (la casa de la madre de Pau): 192.168.20.0/24
RouterInternet: 192.168.20.1 (el router de ono)
PC2: 192.168.20.100 un PC allí con salida a internet a través del gw a internet 192.168.20.1
NanoStation Loco M5 (o cualquier AirOS):
LAN: 192.168.20.2 con gateway 192.168.20.1 (el gw a internet, ono, vamos). El GW no se puede poner en el GUI web, se hará más adelante
WLAN 10.22.1.10 / 27 (255.255.255.224) siendo el gateway de su subred guifi.net 10.22.1.1
Esto se puede configurar a través del GUI Web de AirOS.
debe estar en modo router y con NAT desde lo que venga desde el túnel hacia la LAN (esto se hará más abajo)
La ruta por defecto no puede ser el de la subred guifi.net porque recibirá paquetes con destinos direcciones de internet que debe encaminar hacia el router de ono. Se incluirá una ruta estática para indicar que para llegar a nodos de guifi.net se hará a través de la pasarela 10.22.1.1
Subred3:
192.168.30.0/24 la asignada al tunel entre los dos Ubiquity. El tunel creará un enlace extremo a extremo sin importarnos el enrutamiento dentro de guifi.net.
NanoBridge (en casa de Pau): 192.168.30.2
NanoLoco (en casa de su madre): 192.168.30.1 (recordad que esta era la dirección de la pasarela predeterminada en casa de Pau)
Como alternativa podría establecerse un tunel entre las dos ubicaciones físicas extendiendo una única subred entre ellas, es decir, que se usará una única dirección de red privada tanto en casa de Pau como de su madre como en los extremos del túnel. Se han establecido varias para evitar el tráfico de broadcast a través del tunel. Pero tendría sentido si el canal sobre el que se establece el túnel es rápido y no se produce demasiado tráfico de este tipo en cada ubicación.
El quid de la cuestión está en crear un script que se ejecuta tras la inicialización del Nano y que establece el túnel y algunas rutas necesarias. La versión 3.5 que he visto en Nanos 2Ghz no M soporta túneles en modo ipip y gre. Pero los M con AirOs v5 sólo soportan túneles gre.
En el NanoBridge (casa de Pau).
Entrando por ssh:
vi /etc/persistent/rc.poststart
#creo el tunel entre la dirección pública guifi.net del nodo de Pau como local y el de su madre como remoto
ip tunnel add tunnel0 mode gre local 10.20.1.10 remote 10.22.1.10
#se activa el interface de red asociado al túnel
ip link set tunnel0 up
#se le da una dirección privada en la subred asociada al tunel.
ip addr add 192.168.30.2/24 dev tunnel0
# se añade una ruta para indicar que para llegar a la LAN remota (casa de la madre de Pau), donde está el gateway a internet de ono, debe pasarse por el túnel
ip route add 192.168.20.0/24 dev tunnel0
# como el gateway predeterminado no es la pasarela de guifi.net de la subred donde está el nodo, debe indicarse qué ruta seguir para llegar al nodo remoto de la madre de Pau en guifi.net. El siguiente salto es el gateway de la subred guifi.net donde está el nodo.
ip route add 10.22.1.0/ 27 via 10.20.1.1
# lo anterior es redundante con esta pero lo pongo por claridad. Esta es la ruta para llegar a cualquier nodo guifi.net (incluyendo el anterior)
ip route add 10.0.0.0/8 via 10.20.1.1
# por si acaso en el GUI Web de AirOS no se ha indicado correctamente, borro la ruta predeterminada
ip route del default
# la ruta predeterminada para llegar a cualquier dirección de internet es el extremo remoto del túnel.
ip route add default via 192.168.30.1
:wq
chmod +x /etc/persistent/rc.poststart
save
reboot
En el NanoBridge del otro extremo, tres cuartos de lo mismo:
Entrando por ssh:
vi /etc/persistent/rc.poststart
ip tunnel add tunnel0 mode gre local 10.22.1.10 remote 10.20.1.10
ip link set tunnel0 up
ip addr add 192.168.30.1/24 dev tunnel0
# ruta para poder volver a la LAN de la casa remota de Pau a través del túnel
ip route add 192.168.10.0/24 dev tunnel0
# pero como el gw predeterminado ya no es el gw guifi.net de su subred debe informarse de cómo llegar al nodo guifi.net remoto.
ip route add 10.20.1.0/ 27 via 10.22.1.1
#la anterior es redundante con esta. Ruta para llegar a cualquier nodo guifi.net a través del gw de la subred guifi.net en el que está el nodo
ip route add 10.0.0.0/8 via 10.22.1.1
# por si acaso borro la ruta predeterminada
ip route del default
# y la ruta predeterminada a cualquier dirección de internet pasa el por router de ono
ip route add default via 192.168.20.1
# en el router de ONO no podemos esperar poder añadir rutas por lo que necesitamos enmascarar la IP origen de lo que venga por el tunel hacia ONO y sustituirla por la de la parte LAN.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
:wq
chmod +x /etc/persistent/rc.poststart
save
reboot
Y ya está, eso es todo, parece mucho más rollo de lo que es. Lo he probado en una topología de ensayo y funciona muy bien. Espero no haber cometido errores al escribirlo. Ya me comentaréis
Salud,
Emilio
PD: Quique Molinero comenta que encontró un comportamiento muy extraño cuando hizo un montaje siguiendo este artículo. Si bien no tenía ningún problema en la salida a internet desde la ubicación donde se encuentra el router de internet, en la ubicación remota (Marjalería) tenía un ordenador con Ubuntu que se comportaba anomalamente en la navegación web: algunas páginas sin problemas (todas de Google) pero otras sin acceso. Ping sin problemas a varios dominios incluso a los que no podía acceder via web. Problema DNS descartado.
Lo solucionó configurando el interface ethernet de ese ordenador bajando la unidad de transmisión de 1500, por defecto, a 1400: sudo ifconfig eth0 mtu 1400
Queda pendiente que pruebe a navegar desde la ubicación remota con un Windows. Tampoco tengo claro si hay relación o no con el tunel.
25/03/2013
Rafael Vicent se puso en contacto conmigo sobre problemas que tenía al conectar un windows remoto siguiendo el esquema presentado aquí. Algo similar a los problemas de Quique Molinero. Pego el mail final de Rafael donde describe el problema y nos da la solución. Gracias a Rafael y a Quique.
Ya he conseguido que funcione el túnel correctamente.
Estuve comentando la experiencia previa que tuvo Quique y según me dijo, con exactamente los mismos problemas, el lo solucionó bajando el MTU a 1400 en su ordenador con linux.
Como yo estaba probando con un ordenador con windows7 busqué para hacer lo mismo y al final lo conseguí con:
netsh interface ipv4 set subinterface "conexión de área local" mtu=1400 store=persistent
Para comprobar las MTU de todas nuestras conexiones basta con:
netsh interface ipv4 show subinterfaces
Pues bien, con esto todo funciona a las mil maravillas. Pero como lo que yo quería era compartir mi adsl, y en la localización remota pretendía colocar un punto de acceso wifi doméstico para conectar teléfonos, tabletas, ordenadores, etc... no podía estar cambiando la MTU a cada dispositivo que se conectara a la red, por lo que había que buscar una solución que sólo afectara a la configuración de la red y no a los dispositivos que se conectaran. Después de algunas horas googleleando, probando con sniffers de red, etc.. he conseguido que todo funcione sin tocar nada en los dispositivos que se conectan. Te comento.
El problema está en que cuando dos dispositivos establecen una conexión TCP, en los paquetes de sincronismo (SYN) envían el parámetro MSS que corresponde a la cantidad de bytes que puede transportar un paquete TCP (que suele ser el MTU – 40, que es lo que ocupa la cabecera). Fruto de esta negociación los dispositivos acuerdan utilizar el menor MSS de los dos para que no haya problemas. Pues si ambos tienen el MTU a 1500 (que es lo habitual) se envían el MSS = 1460 y esto limita la carga útil de los paquetes. Cuando los paquetes llegan a un tunel, el enrutador encargado, mete el paquete dentro de otro con diferente IP para que pueda circular por esa subred sin problemas. Si los paquetes se habían construido apurando al máximo la capacidad de los dispositivos (MTU = 1500), lo más probable es que el nuevo paquete simplemente “no quepa por el tunel”. Para evitar este problema, es habitual en VPNs, túneles, etc.. reducir el tamaño de los paquetes deliberadamente, con el fin de que al ser envueltos para atravesar el túnel no haya problemas.
Pues la manera de hacer esto en nuestro enrutador es:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN SYN -j TCPMSS --set-mss 1360
Con esto lo que le estamos diciendo al enrutador es que a todos los paquetes TCP de sincronismo (los que negocian el tamaño de los paquetes posteriores) que lo atraviesen, les tiene que cambiar el parámetro MSS a un valor de 1360 ( he probado con 1400 y ya no funciona).
Si añadimos esto en ambos lados del túnel (por si acaso) y que cargue el módulo gre (que ya comentamos en su día) mis scripts han quedado así:
En la antena conectada al router ADSL:
insmod ip_gre
ip tunnel add mitunel mode gre local 10.228.140.235 10.228.X1.X2 remote 10.229.20.2 10.229.Y1.Y2
ip link set mitunel up
ip addr add 192.168.30.1/24 dev mitunel
ip route add 192.168.1.0/24 dev mitunel
ip route add 10.229.Y1.0/27 via 10.228.X1.X3 #el gw de la subred guifi
ip route add 10.0.0.0/8 via 10.228.X1.X3 #el gw de la subred guifi
ip route del default
ip route add default via 192.168.2.1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN SYN -j TCPMSS --set-mss 1360
Y en la antena remota;
insmod ip_gre
ip tunnel add mitunel mode gre local 10.229.20.2 10.229.Y1.Y2 remote 10.228.140.235 10.228.X1.X2
ip link set mitunel up
ip addr add 192.168.30.2/24 dev mitunel
ip route add 192.168.2.0/24 dev mitunel
ip route add 10.228.X1.0/27 via 10.229.Y1.Y3 #gw de la subred
ip route add 10.0.0.0/8 via 10.229.Y1.Y3 #gw de la subred
ip route del default
ip route add default via 192.168.30.1
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN SYN -j TCPMSS --set-mss 1360
Y con esto parece que todo funciona. Si Hubiera alguna novedad ya te lo comentaría.
- emilio's blog
- Inicie sesión para enviar comentarios
Pregunta del Millon
¿¿Que líneas añadiríamos al script de la antena conectada al router ADSL, para incorporar otra antena más ubicada en otra subred??
Os explico este caso, resulta que un vecino es el que quiere compartir su ADSL con sus dos hijos y cada uno esta ubicado en una zona diferente, así que necesitaría un ejemplo de muestra para saber que líneas tendría que añadirle a la antena del router ADSL para compartir con las dos ubicaciones su ADSL, porque entiendo que en las Antenas Clientes será lo mismo en las dos, cambiando por sus respectivas IP's, esto es asi verdad??
Gracias, por vuestra ayuda.
Más difícil, con una LAN dentro de la LAN
Buenas,
Ante todo gracias por el procedimiento. Tengo una duda (que es la que no me permite que funcione): por no poder conectar la antena NanoBridge directamente al router de ONO he tenido que crear una subred LAN que conecta el router de ono (192.168.4.1) con otro router (192.168.5.1) y la antena se conecta a éste router como (192.168.5.100).
Es ponerle "una piedra" más en el camino pero no puedo hacerlo de otra manera.
¿Tengo que añadir algún camino adicional? He revisado todas las notas varias veces y mapeado el diagrama a mi situación pero creo que me falta algo.
Cualquier comentario será de agradecer
Gracias
Saludos
JAB
Problemas para configurar los túneles
Hola,
He seguido las instrucciones pero no consigo que funcionen los túneles. Para entender lo que pasa, he ido ejecutando las lineas de los scripts una a una en busca de algún error. He visto entonces que al ejecutar la primera linea ( "ip tunnel add ....." ) la contestación que recivo es: "ioctl: No such device".
¿Que no estoy haciendo bien?
Gracias de antemano.
Hola, seguramente ya lo
Hola, seguramente ya lo tendrás resuelto pero por si acaso ... te funcionará ejecutando
/sbin/insmod /lib/modules/2.6.32.54/ip_gre.ko
antes de las instrucciones.
Saludos
No me funciona el tunel
Hola se que hace tiempo que esta puesto este post pero es el primero que encuentro que haga túneles entre ubiquitis. Estoy intentando hacer un tunel con 2 nanobridge entre mi casa y mi casita.
Mi configuracion
internet ------> router internet -----> Mi casa [(Nanobridge m5) ----> .... -----> (nanobridge m5)] ----> Mi casita ---> PC
Subred 1:Mi casa
Router internet: Con servidor Dhcp
Router Internet: 192.168.1.1
Lan de mi casa: 192.168.1.0/24
Puerta de enlace: 192.168.1.1
Nanobridge M5
LAN: 192.168.1.254
WLAN 10.229.10.198/27
Puerta de enlace:10.229.10.193
Subred 2: Micasita
Nanobridge M5 Con servidor Dhcp
LAN: 192.168.2.1
Lan de mi casita:192.168.2.0
WLAN 10.229.23.141/27
Puerta de enlace:10.229.23.129
Subred 3: Entre los nanobridge
Nanobridge mi casa: 192.168.3.1
Nanobridge mi casita: 192.168.3.2
Script nanobridge mi casa:
vi /etc/persistent/rc.poststart
ip tunnel add tunnel0 mode gre local 10.229.10.198 remote 10.229.23.141
ip link set tunnel0 up
ip addr add 192.168.3.1/24 dev tunnel0
ip route add 192.168.2.0/24 dev tunnel0
ip route add 10.229.23.0/27 via 10.229.10.193
ip route del default
ip route add default via 192.168.1.1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
:wq
chmod +x /etc/persistent/rc.poststart
save
reboot
Script nanobridge mi casita:
vi /etc/persistent/rc.poststart
ip tunnel add tunnel0 mode gre local 10.229.23.141 remote 10.229.10.198
ip link set tunnel0 up
ip addr add 192.168.3.2/24 dev tunnel0
ip route add 192.168.1.0/24 dev tunnel0
ip route add 10.229.10.0/27 via 10.229.23.129
ip route del default
ip route add default via 192.168.3.1
:wq
chmod +x /etc/persistent/rc.poststart
save
reboot
Tengo unas cuantas cosas que no me cuadran:
- Cuando pongo un pc en mi casa sin el tunel hecho con la puerta de enlace de la nanobridge (192.168.1.254) tengo ping con la antena de mi casita (10.229.23.141). pero si pongo la predeterminada que es la de el router de internet (192.168.1.1) no consigo ping.
- Si hago el tunel que antes he descrito no consigo ping ni nada. Aunque fuerza la puerta de enlace de la antena (192.168.1.254)
Hola ¿Has conseguido que te
Hola
¿Has conseguido que te funcione? Yo ... peleándome con los trastos.
Gracias
JAB
Funcionando
Hola a todos.
Muchas gracias por la info.
Tras algunas pruebas estoy escribiendo esto desde mi casa, saliendo por el router en casa de mi hermano a la otra punta de Castellón, con dos antenas nanoM5.
Parece que todo funciona correctamente.
Pruebas con resultado negativo
Hola a todos.
He implementado el túnel tal como lo indica Emilio y no funciona. Creo que el motivo es que el router de ONO por el que se accede a Internet no sabe devolver el tráfico al origen, no sabe cómo llegar a las redes 10.0.0.0/8 y 192,168.30.0/24, por lo tanto a la configuración anterior hay que añadir dos rutas estáticas en el router de ONO.
Una para que sepa como llegar a la red de guifi.net
ip route add 10.0.0.0/8 via 192.168.10.1
Otra para el tráfico que llegó por el túnel.
ip route add 192.168.30.0/24 via 192.168.10.1
Esto aún no lo he probado pero creo que es lo que falta.
Si hay algún error en mi razonamiento lo comentáis, que ya sabéis que no soy un crack en estas cosas.
Saludos.
Pau.
TODO FUNCIONANDO
Chateando con Pau hemos conseguido completar las instrucciones para que funcione. Creo que son aplicables generalmente.
Para no modificar (porque no se podía) el router de ONO hemos incluído masquerading en el Nano remoto (de su madre) desde el túnel a través de guifi.net hacia la LAN donde está el ONO.
El script completo está modificado en el artículo.
Salud,
Emilio
Buen trabajo Emilio
Buen trabajo Emilio, sólo comentar un par de cosas/pegas que le veo para que quien lo utilice lo tenga claro. Corregidme si me equivoco.
Los túneles que propones no cifran la información, con lo que la información viaja por guifi.net en claro. Bueno si no es confidencial la información o si accedemos a páginas https no es un problema.
Por otro lado como el tunel se crea en base a ips origen y destino sin ningún tipo de autenticación supongo que no sería demasiado complicado suplantar a alguno de los dos extremos (sobre todo si está apagado).
Es así
Hola,
como es obvio, no hay que corregirte. Es así.
Los túneles no son encriptados, sencillamente se encapsula un paquete IP (N3) completo en otro insertando una cabecera distinta donde se sustituyen las direcciones. Su objetivo no es la seguridad. Pero la información va igual de encriptada que la que enviemos sin túneles por guifi o por internet. Si se desea seguridad, puede utilizarse esos túneles y sobre ellos protocolos seguros como https y demás; es transparente para los servicios y aplicaciones de niveles superiores.
El objetivo era SOLO usar los Nanos en los dos extremos para salvar los problemas de enrutamiento a través de la red.
TODO-LIST:
* PPP porque lleva el demonio pppd y /etc/ppp y solventaría la autenticación
* PPPoE pero no tengo experiencia en esto
Salud,
Emilio
Eres un Crack
Muchas gracias Emilio. Seguro que le servirá a mucha gente.
Una cosilla, las dos antenas son M5, se pueden usar esos script en ellas. No me ha quedado muy claro, parece que dices que sólo soportan túneles gre.
La mía una nanobridge M5 y la de mi madre un nanostation Loco M5.
Saludos.
Pau,
Gre
No se merece.
Si no me equivoco todos los productos M5 llevan la versión de AirOS v5.x. Las versiones que yo he probado sólo soportan tuneles en modo gre, que ya nos va bien. Los aparatos que he probado "sin M" llevan AirOS v3.x y estos soportan tuneles ipip y gre. Por lo tanto el máximo común denominador es gre. Los scripts asumen tuneles gre.
Salud,
Emilio