La fibra de Movistar: routers y ONTs

Friday, 9 de September de 2016

Hace unos días recibí dos routers Mikrotik hAP ac, pedidos con la esperanza de poder sustituir el nefasto Comtrend de Movistar —en modo monopuesto, por Imagenio— y mi fiel Asus RT-N66U que ya empezaba a fallar a nivel físico, además de no llevarse demasiado bien con un TP-Link WA801ND, que generaba problemas de ARP que no conseguí resolver. Y además carecía de PoE Gigabit…

Primero, tomar alguna que otra decisión ejecutiva. Por ejemplo, acabar con el deco nefasto de Movistar en favor del app de Yomvi para Smart TV. Imagenio funciona a través de su propia VLAN, con una configuración propia (que ha de exportarse del router Comtrend) y otras cosas más. Como en casa apenas usamos la tele y aún menos el deco, y el app de Yomvi funciona perfectamente en la tele (sólo faltan unos pocos canales — y ninguno importante para nosotros), parece que el beneficio es más grande que la pérdida.

Manos a la obra. Primer paso, trastear con el ONT. Traté de configurar el ONT (Huawei HG8240) como router monopuesto.

Al hacer eso, y porque soy un manazas, la lié muy parda y borré sin querer mi contraseña del ONT (en la configuración de comunicación con el OLT. Esta contraseña es única para cada cliente de fibra, y también se llama IdONT en jerga de Movistar. Después de intentar conseguir ayuda por parte de Movistar (y aún estoy esperando a que me llamen…) encontré, de paso, una forma de recuperar el IdONT bastante tonta.

Primero, hay que entender que el IdONT (AKA "ONT Authentication") es una cadena hexadecimal de 10 carácteres que a menudo (pero parece que no siempre) comienza por la letra f. Resulta algo confuso porque además la interfaz de configuración la muestra por defecto como una cadena ASCII, así que es un texto más corto con a veces espacios, letras y quizás tildes (no tiene mucho sentido leerlo puesto que es hexadecimal convertido a ASCII).

Pues bien, ese mismo IdONT se usa como usuario para la VoIP, y pese a haberme cargado el IdONT en la configuración, seguía en su lugar la configuración de la VoIP. Sencillamente, yendo a Status > VoIP information aparece en la tabla el campo "User Name", con el formato "IdONT_n". En mi caso, algo parecido a "f2013000919191_1". Volviendo a la configuración de contraseña del OLT, hay que seleccionar el modo hexadecimal, poner la cadena (en el ejemplo, f2013000919191), introducir el SN (número de serie — fácilmente accesible como "SN" en la caja del dispositivo) y guardar. ¡Y hay sincronía!

Para la próxima vez, más vale hacer una copia de seguridad de toda la configuración, apuntar todos los campos que se modifican, tomar capturas de todo y mirar bien qué es cada cosa. Dos veces.

Todo esto para al final descubrir que el PPPoE gestionado directamente por el ONT (lo que buscaba conseguir para convertir al Mikrotik en completamente agnóstico de todo y que únicamente recibiese asignación por DHCP en la WAN), no llega ni de lejos a aprovechar los 300/300. Así que dejo la configuración como estaba antes y busco otra vía.

Segundo intento: configurando el cliente de PPPoE directamente en el router Mikrotik. En pocas palabras, esto supone configurar la interfaz WAN (ether1) con una VLAN (en este caso, ID 6), y sobre esa VLAN, ejecutar un cliente PPPoE con la configuración estándar de Movistar FTTH. Todo esto se puede hacer a través de WebFig, sin necesidad de descargar Winbox. Sería:

  1. Interfaces > VLAN (tab) > Add. Poner VLAN ID a 6, Interface a ether1 (puerto WAN que va al ONT) y guardar.
  2. PPP > Add New (PPPoE client). Interfaz vlan1 (o la que acabamos de crear), usuario adslppp@telefonicanetpa y contraseña adslppp.

Y ya está.

Queda margen para optimización y mejoras. Por ejemplo, montar una red de invitados usando un bridge específico, Virtual AP en Wireless, un nuevo servidor DHCP en esa interfaz, quitando el Default Forward y configurando reglas en el firewall. También tengo pendiente explorar Fasttrack/Fastpath aunque existen limitaciones por el uso de PPPoE (maldita sea, Movistar).

Para terminar sólo queda configurar el segundo AP, conectado mediante ethernet gigabit y alimentado por PoE (power over ethernet), en modo punto de acceso / bridge completo (desactivando el servidor DHCP, configurando el AP con una IP estática en la red del router principal, e incluyendo todas las interfaces existentes en un único bridge).

La guinda en el pastel es el WiFi, 802.11ac en 5 GHz. Se puede configurar (no viene por defecto) con ancho de banda 20/40/80Mhz, y supera los 700 Mbps observados (de unos teóricos, en papel, de 867 Mbps). En la práctica, suele estar por encima de los 500 Mbps. Esto, junto con una configuración de punto de acceso idéntico en el router principal y en el AP, hace que en la práctica sea posible alcanzar bastante más de 300 Mbps inalámbricos en prácticamente cualquier parte de casa, y además con roaming entre los dos puntos de acceso sin notarlo. ¡Esto es el futuro!

París está bien

Friday, 22 de April de 2016

Hasta el momento, mi única visita consciente y adulta a París fue una escala de un día, entre un Eurostar desde Londres y un vuelo a Madrid al día siguiente por la tarde. No fue especialmente bien: perdí el DNI durante el viaje, me olvidé de comer en París, llegué tarde al tren al aeropuerto y al poco de cogerlo se averió (y pese a todo, conseguí volver a Madrid en mi vuelo — y eso que hasta los carritos de bebé me adelantaban por la terminal de lo agotado que estaba).

París

Salvando todo ese drama, y unas temperaturas absolutamente insoportables, la visita estuvo bien, pero me dejó con cierto amargor del que hasta ahora no había conseguido librarme. Pero una amiga, Nani, me convenció para ir en enero de este año y … bueno, resulta que con tranquilidad, París está bastante bien. Y ahora he renovado mi fe en París, su maravillosa red de transporte (sí, es que a mi me van esas cosas…) y también su Autolib'. Ya he cumplido mi objetivo de conducir en otra —caótica— ciudad europea. Londres, ahora es tu turno.

Autolib

Y bueno, aprovechando que estábamos allí no podía faltar un paseo en TGV para comprobar si Estrasburgo está donde dicen que está y cómo están quedando nuestros impuestos.

Strasbourg

Está bien París, sí. Mira, mamá, sin miedo.

République

Porto

Friday, 22 de April de 2016

Porto tiene tres grandes virtudes. La primera es el vino dulce. La segunda es su aspecto inconfundible. Y la tercera son sus vuelos baratísimos desde Madrid. Así que, ¿por qué no ir a pasar un rato, otro enero más? ¡Daytrip!

La primera vez fue en enero del año pasado. Ya hablé de eso anteriormente, y me vine con algunas fotos que aún me traen buenos recuerdos:

Oporto

Aprovechando las ofertas de año nuevo, volví, esta vez con Andrea, y a parte de ponernos finos a vino, pudimos ver cosas bonitas y disfrutar de un tiempo espectacular. Gracias, karma.

Para contrastar, os dejo con mi mejor peor foto:

El Peor

Y bueno, no hay dos sin tres. ¿Nos vemos en enero?

Encapsulando tráfico

Thursday, 13 de August de 2015

"IP over…" da para muchas cosas. Por ejemplo, el maravilloso protocolo de IPoAC. Pero hoy voy a hablar de otra cosa. IP sobre DNS, y de IP sobre ICMP.

¿Motivo? Viajar. Y la necesidad de tener un mínimo de comunicación, aunque sea navegación web reducida a mínimos, Telegram y poco más. Porque a menudo los precios resultan inabarcables… y porque algo bueno tendrá que tener ser un tecnofriki.

Dos cosas, por lo tanto: iodine para encapsular vía DNS, y hans para hacerlo a través de ICMP. En mi caso, he escogido la configuración más sencilla: una máquina en DigitalOcean dedicada exclusivamente para la tarea (dado que interferir con DNS e ICMP puede resultar complicado si no), y un dominio propio con control sobre la zona DNS.

Instalando iodine

Lo primero es crear la zona DNS. Asumiendo que tenemos un dominio h4x0r.com, y la IP de nuestro servidor es 123.123.123.123, bastaría con crearlo de tal manera que iodine.h4x0r.com fuese una entrada A apuntando a la IP, y tunnel.h4x0r.com fuese una entrada NS apuntando a iodine.h4x0r.com. como nombre cánonico. Muy importante el punto al final para que no sea relativo.

Después, en el servidor, hay que instalar iodine. En la última Debian es muy fácil: apt-get install iodine y listo. Con ello, sólo queda configurar bien iodine editando el fichero /etc/default/iodine:

START_IODINED="true"
IODINED_ARGS="10.0.0.1 tunnel.h4x0r.com"    
IODINED_PASSWORD="h4x0r"        

La primera línea hace que el daemon se llegue a ejecutar (si no, el script init.d no se ejecutaría). Después, los argumentos: primero, la IP —privada— que tomaría el servidor una vez establecido un túnel, y después, el dominio público que apunta al túnel (ojo: la entrada NS aquí). Y por último, la contraseña en texto plano del túnel que deberán conocer tanto cliente como servidor. Cámbiala.

Llegados hasta aquí, basta con lanzar iodine como un servicio normal, haciendo /etc/init.d/iodined start y listos.

Cosas a tener en cuenta: primero, que iodined actúa en el puerto 53 así que no debe haber ninguna instancia servidor de bind o de dnsmasq corriendo. De ahí el interés de tener un servidor (virtual) y una IP dedicada únicamente para esta tarea. Después, que realmente iodine lleva dos procesos: iodine que es el cliente, y iodined que es el servidor. Ambos usan argumentos casi idénticos así que puede dar lugar a confusión.

Instalando hans

En Debian esto es un pelín más complicado, porque no viene en los repositorios. Pero no es mucho más complicado. Lo primero: tener todas las herramientas para poder compilar, y git también, por comodidad. Si no lo tienes: apt-get install build-essential git y listo. Luego, basta con compilar y moverlo al $PATH, en mi caso, por elección personal, /usr/sbin que es donde está iodine (puedes verlo usando whereis).

git clone https://github.com/friedrich/hans.git
cd hans
make
sudo mv hans /usr/sbin/

Y ya está. Si ejecutas hans en cualquier directorio debería darte la versión.

Siguiente paso: hacer que se comporte como un demonio. Del sistema. Para eso me he limitado a copiar los ficheros de default de iodine y el init.d también, ajustándolo a las necesidades de hans. Luego con insserv se configura como servicio y se lanza al arranque. Aquí están los ficheros que he usado: el primero se debe copiar a /etc/default/hans y el segundo a /etc/init.d/hans. Luego:

chmod +x /etc/init.d/hans
insserv hans

El fichero de defaults es muy similar al de iodine. En la primera línea, dejar que el script de init.d pueda correr (forma fácil de desactivarlo). Después, la IP privada en la que se situará el servidor host (he usado un rango distinto al de iodine para evitar posibles conflictos). El flag -r hace que hans responda también a los paquetes de ping normales, lo cual puede ser útil para saber fácilmente si el proceso está corriendo. Aunque al no responderse desde la capa kernel, es normal que la latencia percibida en el ping se dispare. No pasa nada. Y finalmente, la contraseña del túnel (no olvides cambiarla y recordarla).

Finalmente, un último detalle: hay que hacer que el sistema no responda a los paquetes ICMP, para que hans pueda hacerlo. Muy sencillo. Basta con editar el fichero /etc/sysctl.conf y añadir una línea al final:

net.ipv4.icmp_echo_ignore_all = 1

Aquí es recomendable reiniciar el sistema. No es necesario realmente: con sysctl -p se pueden refrescar los ajustes del kernel sobre ignorar ICMP, y se pueden levantar ambos servicios a mano, pero así veremos si los servicios se levantan a la vez sin problemas. Y para comprobarlo, ejecuta ps aux como root, y tanto hans como iodine deberían figurar en la lista.

Usando iodine y hans desde OSX

Asumo que a estas alturas cualquier persona ya conoce brew en OSX. Así es muy fácil: brew install iodine y tendremos iodine instalado. Puede que dé algún error con la instalación de tun/tap, pero basta con seguir las instrucciones que ofrece el error para instalar ese componente y listo.

Para hans, se puede compilar (muy fácil en OSX si se tienen las herramientas instaladas) o directamente usar el binario compilado oficial y copiarlo al $PATH de tu elección (en mi caso, /usr/local/sbin, porque es donde están los orígenes de los binarios instalados por brew).

Una vez terminada la instalación de ambos componentes, podremos ejecutar iodine y hans en cualquier directorio con éxito. Y como se están ejecutando en el servidor, ya basta con atacar la parte cliente.

El principio de todo esto es de establecer un túnel. Así, si ejecutamos hans en el cliente con todos los parámetros necesarios, establecerá un túnel mediante ICMP de tal manera que en la dirección 10.0.1.1 tengamos al servidor remoto (pero no acceso a internet puramente dicho). Es exactamente lo mismo con iodine, solo que con la IP 10.0.0.1. En ambos casos, son las IP especificadas en los ficheros de default donde se configuran los argumentos de ejecución de servidor.

Desde el cliente, se lanza así:

# Para iodine
sudo iodine -f -P h4x0r tunnel.h4x0r.com
# Para hans
sudo hans -f -c 123.123.123.123 -p h4x0r

Lógicamente, hay que cambiar tanto la IP, como la contraseña y la ubicación de la entrada NS para corresponderse con lo configurado. Aquí sigue los ejemplos. El parámetro -f hace que se mantengan en primer plano. Se pueden ejecutar en segundo plano quitando ese parámetro.

Si todo funciona con éxito, podremos hacer SSH a la IP remota (que varía según usemos hans o iodine, como explico arriba) y conectarnos con el servidor (y nada más). Así que todo lo que queramos hacer pasa a través del servidor.

Aquí entran en juego varias posibilidades. Por ejemplo, montar un proxy SOCKS (que viene directamente con SSH):

ssh -D 1080 root@10.0.x.1

Y así, en 127.0.0.1:1080 tendremos un proxy SOCKS con acceso a internet. Luego basta con configurarlo en las opciones de red de OSX para que lo usen la mayoría de programas, o en los ajustes avanzados de red en el caso de Firefox, especificando la IP del proxy como 127.0.0.1 (local) y el puerto 1080 (el especificado en el argumento -D de SSH). Y así tendremos internet.

Otra opción más avanzada, basada en la misma, es usar sshuttle, que es una especie de "VPN de mentira" sobre SSH que no requiere nada instalado en el servidor remoto y es mucho más liviano. Basta con instalarlo en OSX y ejecutarlo:

brew install sshuttle
sshuttle --dns -r root@10.0.x.1 0/0

Así, tendremos un túnel entre nuestro ordenador y el servidor (con una IP privada que será 10.0.0.1 o bien 10.0.1.1, según qué tipo de túnel sea), y dentro de ese túnel, todo el tráfico (es decir, el de la subred 0.0.0.0/0) estará enrutado mediante sshuttle.

Hay un montón de opciones más. Por ejemplo, si tenemos OpenVPN montado en el mismo servidor, bastará con lanzar el cliente de OpenVPN y especificar la IP privada del servidor al otro lado del túnel, y debería tener acceso completo a internet entonces. O si tenemos OpenVPN en otro servidor, el mismo cliente (por ejemplo, Viscosity) se puede configurar para emplear un proxy SOCKS.

También existen otras opciones más complicadas como configurar el servidor como router, y una vez establecido el túnel, modificar nuestra tabla de enrutado para configurar al servidor remoto al otro lado del túnel como gateway.

Pero dado el limitadísimo ancho de banda que se suele obtener con un túnel, la opción más sencilla suele ser la mejor… y en este caso, yo creo que usar SOCKS con únicamente un navegador es suficientemente satisfactorio (y además, evitas que otros procesos y programas saturen el poco ancho de banda que tienes, porque no pueden salir a internet al desconocer el proxy). Y si SOCKS se queda corto, entonces sshuttle puede ser el combo ideal. ¡Y con unas pocas líneas de terminal!

Orbitando durante un año

Monday, 23 de March de 2015

La última vez que escribí sobre viajes fue a finales de 2013, tras un año épico: Corea, Tokyo, Alemania, Londres… En general, 2013 fue un año muy intenso. Justo al final, en noviembre, entré a trabajar en ShuttleCloud, donde sigo desde entonces (y más feliz que una perdiz).

Ha llovido muchísimo desde 2013. Pero, pese a tener la universidad de por medio y un nuevo trabajo también, no he dejado de viajar. Y es que 2013 fue sólo un buen comienzo… Porque 2014 no ha estado nada mal.

Empecé el año viajando a Nueva York con la empresa. Fue mi primera vez en NYC, y se podría decir que en EEUU también, por lo menos desde que tengo uso de conciencia (mi único recuerdo de la primera vez de verdad, siendo muy pequeño, se limita a expendedoras de cubitos de hielo, retretes desbordantes y una excursion a Cabo Cañaveral).

No hay nada que pueda escribir sobre NYC que no se haya escrito ya en algún otro sitio (¡luces!, ¡rascacielos!), así que me limitaré a dejar una foto y avanzar:

Nueva York desde el Rockefeller Center

Unos pocos meses después, topé con una "tarifa error" provocada por la fusión de US Airways con American Airlines (¡gracias, Flyertalk!). Y de forma casi inesperada, terminé de nuevo en NYC, sólo meses después de la primera visita. Aunque esta vez aproveché para visitar también Washington DC. Porque en Boston hacía frío, y porque… pues porque me encanta House Of Cards, a quién voy a engañar:

Una cosa grande en DC

En este viaje descubrí que si una empresa se llama 'Eastern Bus', no es porque opere en la costa este… Si no por su público asiático. Y también me (re)enamoré del género humano, de nuevo, en DC. (A veces conviene sentirse vivo.)

Después, tocó visitar el Primavera Sound, que omitiré para no pasarme de moderno. Además, inmediatamente después, terminé aterrizando en Sofía. Una ciudad con un nombre precioso, no tan preciosa, que es la capital de Bulgaria. Bueno, en realidad tiene buenos ángulos, y basta con encontrarlos.

Sofía

Bulgaria es un país muy interesante. También es el país más pobre de la UE, y se nota. Lo realmente curioso, para mi, fue ver como en Sofía, ser turista y no estar solo de paso resultaba extraño y divertido para los locales (¿quién querría visitar esta ciudad?). Me lo pasé como un niño pequeño (pero con edad de tomar mucha cerveza).

En julio, y aprovechando la presencia de compañeros de trabajo de EEUU, visitamos Salamanca. Fue la primera vez que estuve, y fue precioso. ¡Gracias, Félix!

Salamanca

Después siguieron varias escapadas espontáneas: la Euskal Encounter, Francia, y el festival Paredes de Coura. (Quizás el mejor festival, y a la vez, la mayor decepción, del verano.)

Y finalmente cerré el año con un triplete de viajes, cortesía de eDreams y una maravillosa oferta (aunque comercialmente catastrófica para ellos…).

Primero, Ginebra, con amigos y muy rápido. ¡Un lago! ¡Suizos! ¡Cosas carísimas!

¡Hay patos en el Lac Léman!

Luego, Londres. Casi rutinario, y bastante gris. En ocasiones, pasan cosas. Otras veces sale el sol.

Primrose Hill

Y finalmente, Budapest. Una espinita clavada desde que visité Sofía y me quedé con más ganas de ir al este (en contra del dictamen de los Pet Shop Boys, unos meses antes, en Murcia… ¡jubílense, señores!). Una ciudad preciosa y vibrante, aunque por desgracia, enormemente turística. Nada es perfecto.

Bar

Pero bueno, un post no es un post sin algo de trampa. Hay que empezar 2015 con buen pie, y la mejor forma de hacerlo, es enamorándote. Un poquito. (Nunca del todo.)

Oporto

Oporto ha sido mi sorpresa personal del comienzo de 2015. Dejo esta puesta de sol maravillosa y cierro post. Ahora queda vivir 2015, y empezamos en tres, dos, uno… click