sábado, 31 de enero de 2015

Retrotutoriales: discos de vinilo

Hoy retomo desde mi otro blog la sección "retrotutoriales" para explicar un nuevo caso de tecnologia que ha caido en desuso: los discos de vinilo.

Una de las cosas que siempre ha querido el ser humano es comunicarse con la mayor precisión posible. La escritura permite transmitir las palabras y la fotografía las imagenes, pero tambien se quiere transmitir el sonido y para ello es necesario grabarlo de alguna manera.

Para ello, uno de los sistemas que mas se popularizó fue el uso de discos de vinilo. El vinilo es un material ligeramente flexible y que puede ser "raspado" y que quede marcado de manera permanente y en esas "raspaduras" es posible almacenar información de manera continua (analógica).

El sistema empleado en los discos de vinilo es una aguja, que al moverse sobre una raspadura capta las vibraciones de la misma. Esa vibración es tranformada y transmitida a un altavoz o similar y asi se convierte en sonido.

Lo que nos llama la atencion es ¿por que un disco? Se podria hacer en una larga tira de plastico, pero seria imposible de manejar, asi que se raspa en forma de espiral sobre un disco de vinilo. Mucho antes se hacia sobre cilindros (similares a los del papel higienico), pero aparentemente se conservaba peor.

Su caida en desuso se dio al aparecer los sistemas digitales que reducian la fragilidad del vinilo, mejoraban su resistencia al polvo y la humedad y sobre todo permitian que la musica fuera mas transportable mediante el uso de reproductores portatiles (que tampoco tuvieron mucho exito al verse afectados por las vibraciones).

Ahora bien, conocida la tecnología en que se basa, vamos a la parte del "retrotutorial".

Un reproductor de discos está compuesto por tres elementos. El primero, y mas voluminoso, es una superficie circular que gira sobre si misma a una velocidad fija medida en RPM (revoluciones por minuto, el numero de vueltas que da) llamada "plato". A diferencia de un CD, la velocidad de giro es siempre la misma. El segundo es el cabezal que contiene esa aguja y los sensores que captan su movimiento y el cableado que lleva la señal. Por ultimo, está un "brazo" que sostiene el cabezal y permite que se desplace lateralmente por la superficie del disco.

Para usarlo, lo primero es colocar el disco sobre el plato guiandose por un agujero en su parte central. Hay que tener en cuenta que un disco tiene dos caras (cara A y cara B) que contienen distinto contenido. Una vez colocado, se enciende el mecanismo que lo hace girar a la velocidad adecuada (generalmente 33 o 45 RPM). Después se levanta el brazo con la cápsula y se deposita sobre el disco suavemente. En caso de que no se hiciera con cuidado, el disco podria dañarse. La capsula se mueve desde fuera hacia dentro, por lo que el principio del disco está en la parte exterior (también a diferencia del CD). La música o lo que haya grabado en el disco debería sonar.

Otra cosa a tener en cuenta es que hay distintas partes en un disco de vinilo. Está el agujero central, una etiqueta con información sobre la grabación y mas alla hay varias zonas que son aparentemente circulos concéntricos anchos separados por otros circulos mas pequeños. En los circulos anchos está grabada la música y los circulos estrechos son un separador entre las distintas canciones. Por ultimo, la parte exterior es similar a los circulos estrechos, no contiene musica. En principio, se debe poner la aguja sobre los separadores o sobre el borde exterior para evitar daños en la parte grabada por posibles rebotes al posarla.

Espero que os haya resultado interesante. Un saludo.

jueves, 29 de enero de 2015

Experimentos sin sentido: TOR + Torrents

Debido al bloqueo de TPB de hace unos dias me entró una duda sobre como se podrian combinar Tor y uTorrent y si serviria para algo. He hecho mis averiguaciones sobre el protocolo, he trasteado un rato y aunque lo que he hecho me ha ofrecido resultados poco utiles, si que he podido aprender unas cuantas cosas.

Lo primero de todo, una advertencia que voy a poner en negrita:

Este experimento puede causar graves problemas al aplicarlo en torrents de trackers privados puesto que algunos prohiben el uso de proxys, e incluso puede conllevar la expulsion del usuario o un baneo permanente de ese tracker y otros servidores, si comparten una lista negra de baneos. Si pruebas esto que voy a describir asumes este riesgo. No me responsabilizo de posibles problemas.

Venga, pues vamos a entrar en materia. Lo primero, una capturilla:


En esta captura podemos una sección de las opciones de uTorrent, en la que permite utilizar un proxy para las conexiones, y en ella hay un par de casillas interesantes.

Existe la opcion de usar un proxy para "buscar anfitrión", lo que se hace conectando a los trackers, y la de conectar "compi-a-compi", o sea, con los demás equipos ya sean semillas o leechers.

De ahi me vino la duda, si Tor funciona configurado como un proxy, ¿no se podría encriptar la comunicación con el tracker mediante Tor? Esto me permitiria eludir un posible bloqueo gubernamental.

Entonces me puse a ello. Lo primero que necesitaria es poder acceder a Tor, asi que fui a la pagina del proyecto, www.torproject.org. Alli lo que se encuentra en la pagina principal es el Tor browser, que es un navegador preconfigurado para su uso con Tor. No se trata de lo que busco, asi que accedo a donde pone "View all downloads". Lo que necesito es descargar Vidalia, que es un panel de configuración de Tor y me encuentro tres opciones: Vidalia bridge bundle, Vidalia relay bundle y Vidalia exit bundle. Se puede descargar cualquiera de las tres, ya que solo se diferencian en la configuración predeterminada.

Descargamos e instalamos. Despues de la instalación nos muestra la opción de abrir el programa. Quizás nos muestre algún error dependiendo del paquete que hayamos descargado, pero podemos ignorarlo.

Si todo va bien se nos mostrará, aparte de un nuevo icono en el area de notificaciones, la siguiente pantalla:


Estamos ya conectados a Tor, pero no de la manera que queremos. Es el momento de presionar sobre "Settings" (aunque "Setup relaying" también nos lleva al mismo sitio que queremos modificar). En la pestaña Appeareance cambiamos el idioma:


Lo siguiente que vamos a hacer es desactivar que se inicie el programa al iniciar el sistema operativo. Quizás a otras personas le sirva, pero no es mi caso, así que vamos a la pestaña "General" y desmarcamos la casilla "Iniciar Vidalia cuando inicie mi sistema".


Y ahora cambiamos lo mas importante. En la pestaña "Compartiendo" marcamos la opcion de "Ejecutar como solo cliente".


A partir de este momento, en cuanto le demos a Aceptar, tendremos configurado nuestro sistema para usar Tor de una manera mas general de la que nos permitiria Tor browser, incluido configurarlo dentro de otras aplicaciones. Podemos detener y volver a iniciar Tor para que se apliquen los cambios.

Ahora, nuestro equipo tiene un proxy incorporado, que tendremos que configurar en el programa que queramos usar. Los datos de configuración que necesitamos son los siguientes:

Tipo de proxy: Socks5
Dirección IP: 127.0.0.1
Puerto: 9050

Seguramente lo de 127.0.0.1 os suene. Aparecía en la Parte III, pero no lo mencionaba. Un equipo tiene siempre, aunque no tenga ninguna conexión de red, una dirección IP para usar servicios internos diseñados para funcionar a traves de red, y esta dirección es la 127.0.0.1. Siempre que veais esa dirección o "localhost", se refiere a nuestro propio equipo, e incluso nos permite realizar un ping (aunque el tiempo que tarda es inferior a milisegundos).

Si quisieramos aplicarlo a cualquier programa tendriamos que usar esa información. Es importante remarcar que es un proxy Socks5, si se intenta establecer como proxy HTTP no funcionará.

Ahora bien, ¿que ocurre si lo intentamos usar en uTorrent? En principio, al conectar con un tracker le mandamos una serie de datos sobre nuestra IP, nuestro puerto, los datos que tenemos del torrent... Vamos, lo que os puse en este post del año pasado. Los datos que enviamos son datos correctos, con la IP externa real de nuestro programa. Eso si, algunos servidores rechazan las conexiones por proxy, o si la IP no concuerda entre la que se pasa en la información sobre el torrent con la conexión en si. De hecho, sería un sistema muy simple para realizar un ataque a un servidor. Se indica la dirección de un servidor al tracker diciendo que tiene un archivo muy buscado (por ejemplo, con una nueva version de Ubuntu) y todos los interesados se tirarán como un enjambre a realizar peticiones a ese servidor.

En las pruebas que he realizado, trackers como AsiaTorrents me han mostrado un mensaje de error, mientras que otros trackers publicos han funcionado correctamente. Mi consejo, podeis intentarlo, siempre que tengais dos clientes de torrents separados, uno para trackers privados y otro para trackers publicos.

Un saludo.

martes, 27 de enero de 2015

Proyecto redes: Caso practico I

Anoche leia un articulo en Genbeta sobre un bloqueo de Vodafone a The pirate bay (una página de torrents, en adelante TPB): http://www.genbeta.com/actualidad/vodafone-espana-bloquea-el-acceso-a-the-pirate-bay. Me ha llamado la atención y se me ha ocurrido aprovecharlo para el curso de redes como caso real. ¿Que os parece la idea?

Tambien existe mas información en http://www.genbeta.com/web/asi-bloquea-vodafone-el-acceso-a-the-pirate-bay, pero ya sube a un nivel mucho mas técnico, asi que no entraré en detalles y simplificaré el asunto..

Vamos a analizar lo que ocurre y como podemos solucionar el problema de acceso. Ahi va el enunciado del examen, podeis intentarlo vosotros o leer la solución:


Se ha detectado que los clientes de Vodafone y los de otros clientes que utilizan el mismo cableado no pueden acceder a una determinada pagina web (TPB). Sin embargo, los clientes de Vodafone que usan un cableado de otras redes (acceso indirecto) si pueden acceder. Al intentar acceder, en lugar de mostrarse la página de TPB se les redirige a una página de información que indica que se trata de un bloqueo deliberado. Si intentan usar unos DNS distintos, el fallo se mantiene. Sin embargo, el fallo ocurre únicamente si intentan acceder a través de HTTP, y el fallo no se presenta al usar HTTPS.

1. Dibujar un esquema de la red.
2. Indicar como se produce este bloqueo e indicar el punto donde se produce.
3. Explicar los métodos que se pueden emplear para saltar este bloqueo y como funcionan.



1. Veamos el esquema:


En el esquema vemos lo siguiente: existen dos redes fisicas, una de Vodafone (un cuadro rojo) y una de otro proveedor (cuadro verde). En ambas redes existen equipos en color rojo (que han contratado el servicio con Vodafone) y otros en color verde (contratado con otro proveedor). Los equipos que hay dentro del cuadro rojo no pueden acceder a TPB.

2. El proceso de la conexion (desde la red de Vodafone) es el siguiente:

Si se usa el protocolo HTTP:
a) Se conecta con un servidor DNS (Vodafone u otro). Se obtiene la IP del servidor de TPB con éxito.
b) Se intenta atravesar el router de Vodafone.
c) Se redirige a un servidor que muestra el error.

Si se usa el protocolo HTTPS:
a) Se conecta con un servidor DNS (Vodafone u otro). Se obtiene la IP del servidor de TPB con éxito.
b) Se intenta atravesar el router de Vodafone.
c) Se alcanza el servidor de TPB.

Dado que el servidor de TPB si responde al protocolo HTTPS, el bloqueo se realiza entre el paso b y el paso c, y por tanto el bloqueo se produce en el router de Vodafone, y se produce mediante algún tipo de análisis de lo que se está transfiriendo.

3. La solución consiste en acceder al servidor TPB encriptando esa transferencia, mediante protocolos como HTTPS o usando un proxy o VPN, que se encarguen de acceder por nosotros.

Como veis, se trata de aplicar las partes 9 y 10 del curso de redes.



¿Y bien? ¿Que tal os ha salido el examen? Si no os ha salido bien, espero que os haya resultado didáctico y que hayais aprendido de ello. Si lo habeis hecho bien, mi enhorabuena. En cualquier caso, podeis preguntarme cualquier duda que tengais en los comentarios.

Un saludo

domingo, 25 de enero de 2015

Idioma español de ruTorrent

Harto de ver "Detalless" donde debería poner "Detalles", "Webserver" donde debería poner "Servidor web" y varias frases sin traducir, he corregido la traducción de ruTorrent al castellano.

Para instalar la traducción solo hay que descomprimir el archivo https://app.box.com/s/h71i9gj81u9re33i6v4oui1zqzuduuc8 en el directorio lang de la instalación de ruTorrent, sobreescribiendo el archivo es.js (que es la traducción existente) con la nueva.

Un saludo.

sábado, 17 de enero de 2015

Legal high SP2: enlace y distribución


Este es el enlace a los subtitulos del 2º especial de Legal high:


Podeis descargarlos de forma gratuita (y si alguien os quiere cobrar por ello, decidme quien es), e incluso distribuirlo, pero teneis que cumplir las siguientes normas:

1. La distribución siempre ha de ser gratuita. Si yo no cobro por hacerlos, tampoco tiene que cobrar nadie en mi nombre.
2. Se debe distribuir preferiblemente  a través de un enlace a este post o al blog.
3. Deben ser distribuidos de forma independiente al video. No está permitido insertarlos en el mismo (hardsubs), ya que sería violar la propiedad intelectual de los autores originales del video. Me podriais meter en un lio. Tampoco los metais en un paquete con el video.

4. Estos subtitulos son obra mia y reclamo mi titularidad. No debeis apropiaroslos, ni modificarlos. Si veis algun error, me lo comentais y lo arreglaré.
5. Están basados en los subtitulos del usuario kangaroo de D-Addicts y los podeis encontrar en este enlace. No están firmados y carecen de indicaciones de distribución, asi que asumo que puedo realizar la traducción.
6. En caso de querer traducirlos de nuevo, desaconsejo que se use mi traducción y os remito a la version original o a la traducción en que me he basado.
7. Yo no he traducido directamente del video, sino de una traducción no profesional. Los derechos de mis subtitulos no violan los de la versión original, ni incumplen ninguna ley.

La versión del video que encaja con estos subtítulos es la correspondiente a este torrent:


Acepto comentarios y correcciones, aunque os pido que no lo hagais de forma anonima.

Un saludo.

También teneis todas mis traducciones relacionadas con esta serie en este enlace.

En caso de que querais recompensarme por mi trabajo, podeis visitar mi sección de afiliados en este enlace o en la barra lateral.


Proyecto LHSP2: Dia 5 (final)

Bueno, pues queda finalizado el proyecto de traducción del segundo especial de Legal High. Ha sido una sesión de 1.09, con las lineas 1285 a 1577. Total, 4.24 lineas por minuto.

El total por tanto ha sido 1577 lineas, en 414 minutos, 3.80 lineas por minuto.

Ahora, la ficha, y me despido hasta el proyecto siguiente.

viernes, 16 de enero de 2015

Proyecto LHSP2: Dia 4

Hoy había que cumplir objetivos, si o si. Aunque he estado peleandome con la nueva tablet (que espero ya sea la definitiva), había decidido que superaría la linea 1250 a toda costa.

En principio, hice por la mañana una sesión de 56 minutos, que cubrió las lineas 949 a 1160 (3.76 lineas por minuto), y como no había llegado al objetivo marcado, tuve que realizar otra sesión de 32 minutos con las lineas 1161 a 1284 (3.84 lineas por minuto). Esto hace 335 lineas entre 88 minutos, que son 3.80 lineas por minuto.

Quedan 293 lineas para finalizar. Intentaré sacarlas todas mañana, aunque no se si podré revisar los subtítulos o los publicaré tal cual y esperaré las notas que me querais hacer llegar.

Bueno, me voy a descansar un poco, a seguir con la tablet y los problemas que me de, y a ver algun capítulo de alguna serie interesante.

Un saludo.

jueves, 15 de enero de 2015

Proyecto LHSP2: Dia 3

Empiezo a tener miedo de no alcanzar el plazo fijado. Hoy he traducido las lineas 670 a 948 en una sesión de 1 hora y 12 minutos. 3.86 lineas por minuto.

Pero es que he andado con lio, compré el otro dia una tablet y entre que la configuraba, le ponia mi software habitual, me daba errores... pues menos tiempo para traducir, y encima ayer veo que me falla el GPS integrado, asi que hoy he tenido que pegarme con el soporte tecnico y ver que otra tablet puedo comprar para sustituirla. Mañana me llega la nueva, asi que veremos que ocurre.

Bueno, si nos sirve de consuelo, casi llego a las 1000 lineas y he superado el 50%

Un saludo.

miércoles, 14 de enero de 2015

Proyecto LHSP2: Dia 2

Las estadisticas de hoy: una unica sesion de 1 hora y 17 minutos, que me ha dado para hacer las lineas 349 a 669. Eso me da 4.17 lineas por minuto, mas de lo esperado.

Entre las notas de traducción, hay dos lineas que quiero aclarar y pedir opinion.

En la linea 408 Komikado-sensei se refiere a su oponente como "Mr. Helpless" (en la version en ingles), puesto que no es capaz de defenderse en un juzgado. Lo he traducido como "Inutil-sensei", aunque una amiga que tiene mas idea de ingles que yo me dice que helpless es mas como "idiota o despistado o que no tiene remedio". Dudo si es correcto, ¿que opinais?

Otra corrección es la linea 550, en la que se refiere a esta misma persona como "Mr. Greengrass". En este caso, dado que le criticaba despues de actuar como un picapleitos buscando la confrontacion mediante ataques al testigo, lo he traducido como "Verdulero-sensei", aplicando la definicion de la RAE de verdulera como "Mujer descarada y ordinaria".

Vosotros direis, ¿teneis alguna traducción mejor?

martes, 13 de enero de 2015

Proyecto LHSP2: Dia 1

Hoy he realizado la primera sesión, que me ha alcanzado para las lineas 1 a 348. La he realizado en 1 hora y 48 minutos, lo que me salen 3.22 lineas por minuto, una cantidad mas que aceptable para el primer dia en este especial.

Dado que el video tiene 1577 lineas, calculando una media similar a la de hoy la estimacion de tiempo está en unos cinco dias, lo que está dentro de los siete dias que me he planteado como limite.

Veremos mañana. ¿Habre cogido algo mas de ritmo? ¿Podre hacer mas de una sesión? El tiempo lo dirá.

Un saludo.

lunes, 12 de enero de 2015

Proyecto traducción: Legal high Special 2

Empiezo con un nuevo proyecto de traducción, esta vez con el segundo especial de Legal high. Es independiente de todo lo anterior, no hay personajes especiales.

Este especial consta de 1577 lineas y tiene una duración de 1 hora y 47 minutos. Tambien tiene unas cuantas frases complejas, y requiere la adaptación habitual de la longitud debida a la forma de hablar del protagonista, por tanto, calculo que la traducción me llevará unos 7 dias máximo.

Como es habitual, seguire mi ritmo de publicaciones en el post de "un dia de traducción = un post". En el indicaré el numero de lineas traducidas, el tiempo que he necesitado en cada sesión de traducción y la media de lineas por minuto. Las condiciones de distribución tambien serán las acostumbradas y la publicación definitiva será al final de la traducción.

Espero poder comenzar esta tarde o mañana. Si quereis comentar sobre ello, podeis hacerlo en cualquier post del proyecto (me llega un correo electronico en las siguientes dos horas) o en Twitter con el hashtag #LegalHighSP2SubEsp.

Un saludo

domingo, 11 de enero de 2015

Proyecto Redes: Parte XIII

Hoy, para acabar con el proyecto, voy a hablar de un par de casos de proxys.

El primero son las extensiones de navegador. Existen extensiones disponibles, como Hola (gracias, kisi89), DotVPN o ZenMate. Todas estas extensiones (si, incluida DotVPN, a pesar del nombre) son proxys a pesar de sus nombres, y son bastante utiles por su forma de instalarse (a veces es suficiente con proporcionarles un correo electronico) y de manejarse. Por lo general os valdrán para engañar a los servidores de destino haciendo creer que estais en otro sitio. Aun así, os recuerdo de nuevo que las conexiones pasan por servidores de terceros y por tanto no debeis enviar informacion confidencial sin codificar.

El segundo, es un proxy conocido como Tor (The onion routing). El sistema es mas complejo, ya que se trata de convertir el PC que utilizas en un proxy en si mismo. No conozco muy bien los detalles, asi que cualquier error en este caso es involuntario.

Se ejecuta un programa (tor) que descarga un listado de equipos. Esos equipos tienen un sistema de encriptacion por el cual puedes encriptar los paquetes para que solo los puedan leer ellos. Tor se encarga de encriptar varias veces esos paquetes y enviarlos por una ruta aleatoria trazada entre al menos 3 equipos.

Supongamos que tenemos un paquete que queremos enviar desde nuestro equipo al de Amigo 1.
-Descargamos una lista de equipos y conseguimos las claves de Conocido 1, Conocido 2 y Conocido 3.
-Entonces establecemos una ruta: queremos que nuestro paquete vaya a traves de ese orden: Conocido 1, Conocido 2, Conocido 3 y Amigo 1.
-Codificamos el paquete que queremos enviar con la clave de Conocido 3 y dejamos indicaciones de que envie la informacion del paquete a Amigo 1.
-Codificamos de nuevo el paquete que ya habiamos codificado, ahora con la clave de Conocido 2 y le damos indicaciones de que debe enviarlo a Conocido 3. Conocido 2 ya no sabe nada sobre el paquete original.
-Codificamos de nuevo con la clave de Conocido 1 el paquete que tenemos y se lo enviamos junto con las indicaciones de enviarlo a Conocido 2.
-Conocido 1 descodifica el paquete que le ha llegado. Sabe que su destino es Conocido 2. No sabe ni el contenido del paquete, ni el destino final. Ni siquiera sabe que ocurrirá despues de enviarselo a Conocido 2, asi que se lo envia a Conocido 2.
-Conocido 2 hace lo mismo. Sabe que se lo envio Conocido 1, pero no sabe quien lo envió originalmente a Conocido 1. Tampoco conoce el destino final, sabe unicamente que tiene que enviarlo a Conocido 3. Por supuesto, tampoco conoce el contenido del paquete.
-Conocido 3 recoge el paquete y lo descodifica, recibiendo el paquete original, y lo envia a Amigo 1. No sabe quien se lo envió.

Esto funciona por capas, como una cebolla (onion) y protege el paquete de que se conozca su contenido, su origen o su destino. El unico que conoce el contenido y el destino es Conocido 3, y el unico que conoce el origen es Conocido 1.

Podeis probarlo descargando el paquete disponible en torproject.org y usando el navegador que os proporciona. No necesitareis, en principio, ninguna modificación.

Como podreis comprobar y debido a que debe pasar por varios equipos y codificarse y descodificarse en varias ocasiones, el sistema no es demasiado adecuado para su uso con programas de P2P. Es perfectamente posible configurarlo, pero la velocidad se ve especialmente mermada.

Bueno, con esto doy ya por concluido el proyecto, o al menos sus objetivos originales. Si lo habeis seguido entero ya comprendeis los principales terminos que os podeis encontrar y os servirá para poder entender explicaciones sencillas en foros tecnicos.

Si necesitais que os aclare cualquier cosa (o simplemente saludar), solo teneis que dejarme algun comentario en cualquiera de los posts del proyecto y os lo intentare contestar. Incluso si es algo que requiera una explicación en profunidad podría haber algun post adicional.

Por el momento me despido, y me preparo para proximos proyectos. Un saludo.

sábado, 10 de enero de 2015

Proyecto Redes: Parte XII

El post de hoy completa el tema de las VPNs que comence ayer, pero desde el lado contrario. Si ayer veiamos como crear un servidor VPN, hoy toca ver como se crea un cliente VPN.
La idea, recordamos, es crear una conexion encriptada con otro equipo de una red distinta para poder acceder a los servicios de esta (incluyendo salidas a la nube).

Aqui va el tutorial (para Windows 7):

Lo primero, accedemos al "Centro de redes y recursos compartidos" tecleandolo en el cuadro de texto o desde el panel de control, que nos lleva a una ventana como esta:



Desde aqui presionamos en "Configurar una nueva conexion o red" y nos preguntara que clase de conexion queremos crear. Como ya comenté, las VPN inicialmente se necesitaban para uso empresarial asi que lo metieron dentro de "Conectarse a un area de trabajo":


Presionamos sobre ello y nos preguntara si queremos crear una conexion nueva o usar una antigua. Como queremos crear una nueva, marcamos la primera opcion.


Aqui ya nos da la opcion que queremos, crear una nueva VPN. Presionamos el primer boton

Y aqui ya es donde toca introducir datos. Necesitamos la IP publica (la que corresponde al lado de la nube) del servidor al que nos vamos a conectar (por supuesto, el puerto TCP 1723 debe estar ya redirigido como explicaba en la parte XI). El nombre de destino es solo el nombre que queremos dar a la conexion para que se vea de una forma mas clara.


La opcion de "Usar una tarjeta inteligente" se refiere a un sistema de autenticación que no usamos, asi que podemos olvidarnos de ella. La opcion de "Permitir que otras personas usen esta conexion" se usa en el caso de que haya varios usuarios en el mismo equipo. En caso de que no se marque, si cambiamos de usuario no podremos hacer uso de esa conexion y deberemos configurarla de nuevo.


Nos pide el nombre de usuario y la contraseña, que serán los que configuramos la vez anterior. El dominio es algo que se usa en empresas y con conexiones mas complejas, asi que lo dejamos en blanco y cuando presionamos en conectar realiza la conexion y por si lo hemos hecho correctamente nos muestra un mensaje de exito.



A partir de ahora, podemos activar o desactivar la conexion VPN desde el icono del area de notificaciones de la barra de herramientas.

Recordad que esta conexion VPN afecta a TODO el trafico de vuestro equipo. Es decir, si usais el navegador pasara por la otra red, pero si usais tambien cualquier otro programa como uTorrent tambien pasará por ahi. Esto puede generar "cuellos de botella", dado que la maxima velocidad que alcanzareis será siempre la menor de las velocidades disponibles en la comunicacion (por lo general, la velocidad de salida de una de las redes), aparte de que se comparte con los equipos de la otra red. No espereis aumentar vuestra velocidad porque no será asi.

Me despido hasta la proxima entrega, en la que hablaré de distintas extensiones de navegador que prometen "anonimizar" vuestra conexión.

Un saludo.

viernes, 9 de enero de 2015

Proyecto Redes: Parte XI

Hoy toca empezar con el tema practico de las VPN. Veremos ahora como se configura una conexion entrante, que es permitir a otros que se conecten a nuestra red. Para el ejemplo, como hago habitualmente, usare Windows 7.

Lo primero, debemos acceder a la pantalla de Conexiones de Red. Solo tenemos que teclearlo en el cuadro de texto del menu inicio y nos saldra "Ver conexiones de red".


Despues vamos al menu Archivo (si no aparecen los menús al apretar la tecla ALT aparecerán) y ahi seleccionamos la opcion "Nueva conexion entrante". Nos aparece la siguiente pantalla:


En ella seleccionamos que usuario queremos autorizar. En mi caso he creado un usuario llamado "Usuario_VPN" y le he asignado una contraseña. Obviamente, si vamos a dejar abierta nuestra red a conexiones de fuera tendremos que poner algun sistema de seguridad.

En la siguiente pantalla, salvo que tengamos alguna configuración extraña, nos preguntará desde donde se conectarán los usuarios. Debemos seleccionar que se conectan a través de Internet, y pasamos a la siguiente pantalla. Aqui ya la cosa se complica.



Tenemos varias opciones para configurar, pero solo tocaremos la primera. En caso de no hacerlo, es muy probable que no tengamos acceso a Internet. Seleccionamos la primera opcion y presionamos en Propiedades.


Tendremos que cambiar las opciones de la parte inferior. Cuando se conecte otro equipo, preguntará que dirección IP usar en la red. Marcaremos un rango dentro de nuestra red. Como mi red es la 192.168.1.x, he marcado esas dos IPs que veis en la imagen.

Aceptamos y presionamos en "Permitir acceso". Tras un breve instante, podremos cerrar la ventana.

Ahora bien, tenemos que tener un par de cosas en cuenta cuando nos vayamos a conectar. La primera, hemos configurado la IP que deberán usar los equipos que se conecten a la red, y nuestro equipo será su puerta de enlace, sin embargo no hemos configurado un servidor DNS. Deberemos hacerlo manualmente en el otro equipo.

Tambien tenemos que redireccionar un puerto en nuestro router, el puerto TCP 1723 (existen dos tipos de puerto TCP y UDP, pero no explicaré las diferencias). Hecho esto, nuestro equipo está disponible para que se puedan conectar a nuestra red (por si usais redes publicas como las de aeropuertos o restaurantes, principalmente). No olvideis que debeis conocer la IP de vuestro router en la nube, o usar un servicio como No-IP para asignarle un nombre de dominio.

En el siguiente, la parte complementaria: como conectar con un servidor VPN.

Un saludo.

jueves, 8 de enero de 2015

Proyecto Redes: Parte X

Hoy voy a explicar lo que es una VPN y para que sirve. Este tema da para mas de una entrega, puesto que quiero comentarlo de forma mas detallada para que le podais sacar algo mas de jugo. Empezamos.

Recordamos que una red local quedaba separada de la nube al pasar a traves del primer router, pero ¿que es lo que podemos hacer si necesitamos que un equipo forme parte de esa red (por seguridad y control de acceso, por ejemplo) pero está en otra ubicación?

Para eso se crearon las VPN (Redes privadas virtuales). Se basan en un equipo (puede ser un PC debidamente configurado y con ciertos puertos redirigidos, un servidor o un router avanzado) conectado a la nube y que tiene acceso a la red local.

Despues, alguien desde la nube lanza una peticion hacia ese equipo para acceder a la red local y entre ambos quedan conectados a traves de un canal encriptado. El nuevo equipo recibe una IP de la red local y a partir de ese momento forma parte de la misma.

Veamoslo con una imagen:


En el diagrama podemos ver que desde nuestro equipo aparece una conexión que he marcado en un color distinto para recalcar que se trata de una conexion encriptada. Esta conexion está encriptada desde el punto de inicio hasta el final, que puede ser un proxy o un equipo de otra red. Esto quiere decir que si alguien desde cualquier router intermedio (como los que he marcado con circulos) intentase leer los mensajes que transmito no podria hacerlo (al menos sin recurrir a equipamiento muy potente, generalmente restringido por su coste a ejercitos o servicios gubernamentales).

Ahora bien, ¿que nos permite esto? Por una parte, podemos acceder a otra red local, pero esto no es todo. Si esa red tiene salida a la nube saldremos con la IP de esta red, y eso nos permitiria saltarnos restricciones geograficas o de contenido. Viendo un ejemplo, si accedemos a traves de una VPN a la red de un amigo en Noruega podriamos ver el contenido de paginas que están restringidas en España y a las que no tenemos acceso, pero a las que nuestro amigo noruego si puede acceder. Tambien podriamos enviar información confidencial sin temor a que sea interceptada (por ejemplo, por censura politica).

Para ello no es necesario que tengamos un amigo noruego. Existen servicios de VPN que nos permiten esta clase de servicios, operando como un proxy.

Una anotacion a tener en cuenta: mientras un proxy actua solo sobre un programa, aunque algunos se basen en la configuración del proxy que hemos configurado por defecto, una VPN actua sobre todos los programas al mismo tiempo, no es posible enviar trafico de torrents por la salida normal a la red y navegar a traves de la VPN.

Otra utilidad menos empleada y que deberia usarse mas es la de asegurar las comunicaciones en las redes compartidas, como las de un hotel o un aeropuerto. Solo habria que configurar la red de casa (donde el ordenador que usamos es "fiable" y supuestamente no hay nadie observando lo que entra y sale, aparte de nuestro antivirus) y conectar nuestro equipo a esa VPN. Esto tan sencillo y tan poco utilizado nos proporciona una capa de seguridad adicional cuando estamos en el extranjero.

En las proximas entregas mostraré como configurar un equipo para recibir conexiones entrantes y como hacer lo propio para las conexiones salientes.

Un saludo.

miércoles, 7 de enero de 2015

Proyecto Redes: Parte IX

Hoy no voy a hablar de un bloqueo como los mencionados, sino que quiero contar algo mas "ligero" y que quedaria fuera por estar en desuso aparentemente (en realidad no es asi y ya veremos por qué), que es el uso de proxys.

Recordamos que un proxy es un equipo que actua de intermediario entre el servidor de destino y el nuestro, enmascarando nuestra dirección, o sirviendo para redireccionar el tráfico.

En el caso que hoy nos ocupa, veremos lo que ocurre con los bloqueos regionales en un servidor.


Esta clase de bloqueo se usa en las paginas que no dan servicio a determinados paises (o que no permiten el acceso a cierto contenido).

El uso de proxys se suele aplicar solo a un cierto tipo de trafico, principalmente trafico web (HTTP y/o HTTPS) y no afecta al resto de las conexiones, aunque algunos programas permitan tambien aplicarlo a determinados protocolos (uTorrent permite aplicarlo de manera independiente a trackers y a peers).

Existen varias formas de acceder a una pagina usando un proxy, mediante un proxy integrado en una pagina web (por ejemplo hidemyass.com) o configurandolo a traves de las opciones de Internet de nuestro sistema operativo.

Para configurarlo, vais a vuestro panel de control y ahi a las opciones de Internet.


En la pestaña Conexiones aparece una opcion que es Configuracion de LAN. Aunque no se trate de la red local, funciona igual.


Ahi marcamos que queremos usar un proxy e introducimos la dirección que queremos usar. Se pueden usar distintos proxys segun el tipo de trafico presionando en Opciones avanzadas:


Podeis encontrar una lista de proxys en http://proxylist.hidemyass.com/

Tened en cuenta que estais pasando trafico por un servidor desconocido, asi que puede ser facilmente interceptado. Intentad no usar cuentas de usuario ni poner contraseñas.

Y mañana mas. Un saludo.

martes, 6 de enero de 2015

Proyecto Redes: Parte VIII

Comenzamos con los bloqueos que nos podemos ir encontrando. Empezaré con el bloqueo por DNS, el mas simple de comprender y el mas rudimentario que puedan aplicarnos.

Como recordareis, el servidor DNS lo que hacia era traducir el nombre del dominio (como www.tiendaonline.com) a su dirección IP (12.34.56.78). Le enviabamos esa solicitud de informacion directamente a su IP (que nos proporcionó nuestro proveedor de Internet) y este nos respondia con la IP correspondiente.

Ahora bien, cuando se establece un bloqueo, el servidor DNS en vez de devolvernos la IP correcta nos indica una IP distinta (por ejemplo 87.65.43.21) con una pagina de "contenido bloqueado" o simplemente dar un error como si desconociera la IP de ese dominio.

La solucion es bastante simple. Al igual que accedemos a nuestro DNS podemos acceder a otro distinto, de otra compañia o de otro pais incluso. En la imagen aparece una explicación gráfica: mientras DNS está bloqueado (circulo rojo), se puede usar el DNS-2 (circulo verde).



Existen DNS disponibles para cada proveedor o pertenecientes a compañias como Google u OpenDNS.

Las direcciones IP de los servidores DNS de Google son 8.8.8.8 y 8.8.4.4.

OpenDNS ofrece tambien las direcciones 208.67.222.222 y 208.67.220.220, y ofrece servicio de bloqueo parental y contra phishing.

Veamos ahora como cambiar nuestras DNS. Para el ejemplo usare Windows 7. Para ello, accedemos a la pantalla de "Conexiones de red" (la forma mas rapida es tecleando "Conexiones" en el cuadro del buscador del menu inicio).

Tras ello, nos apareceran las conexiones que tengamos en nuestro equipo. En mi caso, aparecen dos conexiones. Presionamos el boton derecho sobre la que queremos modificar y escogemos "Propiedades".


Aparecerán distintas opciones, pero la que nos interesa es la del protocolo IP version 4. Lo seleccionamos y presionamos "Propiedades".


Alli podremos cambiar nuestra IP de manera manual y/o los servidores DNS. Si modificamos nuestra IP tendremos que poner tambien a mano los DNS.


Ponemos los DNS que queremos, en el ejemplo usaré los de Google. Podemos encontrar listados de DNS con una sencilla busqueda en Internet.


Y por ultimo, para que pase a tener efecto, aceptamos en todas las ventanas (pueden tardar un poco en cerrarse) y borramos nuestra tabla nombre de dominio-IP mediante el comando IPCONFIG /FLUSHDNS.


Con esto doy por concluida la entrega de hoy. Espero vuestros comentarios. Un saludo.

lunes, 5 de enero de 2015

Proyecto Redes: Parte VII

Empiezo hoy con la parte dedicada a los bloqueos, y que seguramente sea una de las mas esperadas. He decidido prolongar un poco el proyecto, asi que todavia tendremos unas cuantas partes mas.

Cuando se bloquea una pagina, lo que se intenta es que no se pueda llegar desde un equipo (o mas de uno) a un servidor que está censurado. Para ello, es necesario intervenir en algun punto intermedio. Veamos donde puede actuar nuestro "censor" en el siguiente dibujo, que es nuestra red de ejemplo con unos cambios.



En la imagen aparecen marcados seis puntos en color rojo. Son todos los puntos en que un censor puede intervenir para limitar con exito el acceso al sitio censurado. Vamos a ver como funciona cada bloqueo.

Empezamos con el bloqueo directo del sitio censurado. Se desconecta tal cual. No puede acceder nadie, ya que esta desconectado. Es el metodo definitivo para evitar que se acceda a el. Esto suele aplicarse con una orden judicial.

El siguiente bloqueo es el se produce sobre la conexion entre el sitio censurado y las conexiones con el resto de la nube. Si bien el servidor no se ve afectado, queda incomunicado y nadie puede acceder. Se ejecuta por parte del proveedor de Internet de ese sitio, ya sea por orden judicial o por incumplir los acuerdos de servicio con el proveedor. Al igual que el anterior, es definitivo.

Otro bloqueo posible se daría en el router de la nube mas cercano a mi equipo. Este se suele aplicar de una manera mas selectiva. El equipo bloquea las solicitudes de parte de mi IP (o de las IPs de un determinado origen o destino). Existen varios casos a poner como ejemplo:
- El "gran cortafuegos" chino: bloquea todas las conexiones a ciertas paginas o a los paquetes de determinado contenido (ya sea revisando el contenido del paquete o limitando que los paquetes con un puerto de origen o destino determinado puedan pasar).
- El sistema de censura anti-pornografía británico: desde hace unos meses, los usuarios de Internet en el Reino Unido deben solicitar de manera expresa el acceso a contenido pornográfico. En caso contrario, queda bloqueado. Tambien está disponible en casi todos los proveedores de Internet un filtro similar.

Un bloqueo mas cercano es el que se efectua sobre la puerta de enlace. Es algo comun en las redes compartidas, como las de una institucion educativa, una red publica de un aeropuerto o muy frecuentemente en las empresas. Se introduce un proxy (que tambien sirven para esto) entre el nuestro equipo y la nube. Este bloqueo es propio de cada red, no depende de ningun gobierno.

El bloqueo mas cercano de todos es el que se realiza en el propio equipo. Este generalmente se usa en equipos compartidos como los que hay en las bibliotecas. Limita cada equipo de forma individual sin afectar al resto de la red.

Y he dejado como ultimo caso el bloqueo mas rudimentario de todos, que es el bloqueo por DNS. Consiste en algo tan simple como reprogramar el DNS para que cuando se solicite la IP del sitio censurado se responda con una IP distinta (como puede ser la de una pagina de advertencia de que el sitio se ha bloqueado) o con un error, como si el dominio no existiera. Es facil de aplicar y hacerlo tiene un coste minimo. Se suele hacer por orden judicial, como en el caso del bloqueo a la pagina de Uber que se produjo hace unos dias.

Vistos esos bloqueos, en la siguiente entrega explicaré como eludirlos.

domingo, 4 de enero de 2015

Proyecto Redes: Parte VI

Hoy explico dos elementos inicialmente diseñados para el mundo empresarial y que luego se han adaptado a otros ambitos, que son los proxys y las VPN.

Un proxy es un equipo intermedio que se usa a la hora de acceder a otro de una red, y si es necesario adaptar los datos que vienen de este.

Pongo varios casos, para entenderlo facilmente:

- Supongamos que tenemos un equipo al que queremos proteger especialmente por seguridad o por disponibilidad. Por ejemplo, una base de datos con informacion medica, o un banco o algo parecido. Todos los accesos deben estar controlados, nadie debe acceder sin autorizacion, y debe mantenerse funcionando sin problemas, puesto que puede necesitar que este disponible desde varios sitios (por ejemplo, para acceso de los clientes y tambien para la intercomunicacion entre bancos).

Pues se autoriza a los equipos (proxys) que sean necesarios para que accedan y que todas las peticiones se realicen a esos equipos. En caso de que se intente realizar un ataque para "tirar" el equipo con la base de datos el unico que sufriria seria el equipo intermedio, no se sobrecargaria el que mantiene la base de datos, y quedaria funcional para los otros servicios, y en el caso de que haya que hacer modificaciones de seguridad se realizan sin necesidad de tocar el equipo con la base de datos.

- El siguiente caso es usarlo como "cache". Supongamos este ejemplo: estamos en una residencia universitaria. Todos los alumnos usan una misma salida a Internet, pero al mismo tiempo todos van a las mismas paginas. Si no queremos que se sature la conexion, podemos optar por guardar una copia de ciertas paginas en un equipo (el proxy) y que cuando alguien intente acceder a las paginas que ya tiene guardadas en vez de salir a Internet a buscar esa informacion se utilizan las copias que hay dentro de la misma red.

- El tercer y ultimo caso que voy a explicar es el que siguen algunos navegadores moviles como Opera, o las redes de telefonia movil para mejorar la velocidad. Supongamos que queremos acceder a una pagina con imagenes. Esas imagenes normalmente son demasiado grandes, requieren muchos datos y además no se captan con todo detalle desde un telefono. ¿Se podria reducir ese tamaño sin que se note demasiado? Claramente si. Para eso se usa un proxy, el dispositivo le hace la peticion al servidor proxy, que a su vez le pide la informacion al servidor de destino. Una vez recibida esa informacion, la optimiza y la reenvia a quien la pidio originalmente. Aparentemente, el navegador Chrome tambien realiza algo similar para mejorar la velocidad usando un protocolo llamado SPDY.


El siguiente (y ultimo) elemento que explico hoy son las Redes Privadas Virtuales (o VPN, Virtual Private Network).

El concepto consiste en crear una conexion encriptada hacia otra red, y acceder a ella como si formase parte de esta. Supongamos que quiero acceder a la red de Amigo 2. Creo una conexion segura hasta uno de los equipos (que ya esta preparado para ello, con sus puertos abiertos) y este me permite acceder a la red de mi amigo como si estuviera alli. Inicialmente se usa para conectar oficinas que están en distintos puntos geográficos o para jugar en red con otras personas.


Con esto ya doy por concluidas las explicaciones de conceptos. Si lo habeis seguido hasta ahora ya conoceis como funciona Internet y los principales servicios.

La siguiente parte ya sera la ultima. En ella explicaré cuales son las formas que se usan para bloquear una pagina web y como eludir esos bloqueos.

sábado, 3 de enero de 2015

Proyecto Redes: Parte V

Como ya adelantaba en la anterior entrega, hoy voy a explicar algo que es imprescindible que los que descargan mediante P2P conozcan: NAT.

Recordemos que existian dos tipos de redes, la "red local", con unas IPs pertenecientes a unos rangos mas limitados, y la "nube", una gran red que interconecta equipos entre si y con otras redes locales (a traves de equipos intermedios).

Para conectar unas con otras se usan dispositivos llamados routers. Esos dispositivos funcionan como un embudo. Cogen todos los datos de varios equipos de una red local y los sacan por una unica salida. Veamos como lo hacen.

Cada equipo en una red tiene su IP. Un router tiene (al menos) dos IPs, una por cada red a la que pertenece. Para sacar los datos a la nube un router recibe un mensaje desde un equipo de su red local, pero como no puede sacarlo directamente (al haber varias redes conectadas a la nube, con equipos con la misma IP no seria posible que las respuestas volvieran correctamente) lo que hace es re-empaquetar el mensaje con su IP y un nuevo puerto. Pensemos el siguiente caso de ejemplo:

Equipo 1: tiene la IP 192.168.1.100
Router (red interna): IP 192.168.1.1
Router (red externa): IP 9.8.7.6
Tienda online: 12.34.56.78

- El equipo 1 quiere acceder al servidor web (puerto 80) de la tienda online. Para eso crea un mensaje desde un puerto cualquiera (2222) con esta cabecera: 192.168.1.100:2222 -> 12.34.56.78:80
- Como no tiene acceso directamente a la tienda, al estar en otra red, manda el paquete a su puerta de enlace 192.168.1.1.
- El router lo recoge y lo reempaqueta con su IP externa y un puerto nuevo al azar (el 9999), enviando el paquete 9.8.7.6:9999 -> 12.34.56.78:80.
- El servidor de la tienda online recibe el mensaje, y genera una respuesta, que la envia al equipo que realizo la solicitud: 12.34.56.78:80 -> 9.8.7.6:9999
- El router recibe la respuesta y la reenvia a quien creo el paquete original. Este recibe el paquete 12.34.56.78:80 -> 192.168.1.100:2222, como si no hubiera ningun intermediario.

A esto se le llama NAT ("Network address translation", "Traduccion de direcciones de red"), y permite que varios equipos de una misma red compartan una salida comun a otra red distinta.

Esto, tan comodo en este caso, crea un problema en el caso contrario. ¿Que ocurre si lo que se pretende es acceder a un equipo dentro de una red local desde la nube? La solucion esta en la configuracion del router (lo que se denomina "abrir puertos").

Al "abrir un puerto" le decimos al router que reserve un determinado puerto para un determinado equipo. Si un equipo de una red local quisiera ofrecer servicios web, usaria su puerto 80 para "escuchar" las peticiones. Si "redirigimos" el puerto 80 del router (de la red externa) al puerto 80 de un equipo, a todos los efectos será como si ese equipo estuviera conectado de manera directa, sin que hubiera ningun router entre medias.

Eso lo puede hacer el propietario del router de manera manual o el programa mediante un protocolo llamado UPnP. Ese sistema automatizado no todos los routers lo activan por defecto por razones de seguridad (no conviene que un programa vaya abriendo puertos a lo loco), y no todos los programas lo incorporan.

Existe un caso importante que quiero tratar ahora: los programas de P2P.

Un programa de P2P actua de dos maneras, como "cliente" que envia peticiones a un "servidor" y como "servidor" que recibe peticiones de un cliente. Obviamente, para conectarse entre dos equipos el que actua como servidor tiene que estar accesible. En las redes P2P hay un "apaño" consistente en que como los participantes de la red conocen a los demas las peticiones no solo las hace el cliente sino que el servidor tambien va preguntando a los clientes si necesitan datos, en lugar de quedarse simplemente a la espera.

La cuestion importante es que SIEMPRE tiene que haber alguien con los puertos redirigidos. Si una persona no tiene un numero de telefono puede usar una cabina para llamar, aunque no pueda recibir llamadas, pero jamas se podran comunicar dos personas sin numero de telefono, pues ninguno puede llamar al otro.

Por eso siempre es conveniente tener los puertos abiertos al usar P2P, para poder recibir solicitudes y que no se de el caso de que no podamos conectar con otros clientes al tener ellos los puertos cerrados.

Explicado todo esto, segun mi planificacion ya solo me quedan dos asuntos, que son los proxys y las VPNs y como funcionan los bloqueos para censurar un servidor.

Si hay dudas o quereis dar vuestra opinion, publicad un comentario y os respondere.

Un saludo

viernes, 2 de enero de 2015

Proyecto Redes: Parte IV

Para hoy os traigo un tema que jamas, en todo el tiempo que llevo navegando por Internet, he visto bien explicado: que son los puertos.

Mencioné en la primera parte los paquetes, pero no les he dado mas importancia hasta ahora. Se trata de los bloques de datos que enviamos desde el origen al destino. Aparte de los datos en si, contienen varios elementos (en realidad son mas, pero voy solo a explicar lo que nos interesa) metidos en una "cabecera":

- El tamaño.
- El orden del paquete.
- La IP de origen.
- El puerto de origen
- La IP de destino.
- El puerto de destino.

Lo que es el tamaño, es evidente. La cantidad de datos que van en el paquete, para evitar que se junten dos paquetes de distintos tamaños o que se manden datos "en blanco".

El orden del paquete es un indicador de que parte del mensaje se esta transmitiendo. Si quieres transmitir el mensaje "bienvenido a mi blog" y solo puedes usar paquetes de cuatro letras (los espacios cuentan como letra) los tienes que ir numerando para poder reconstruir el mensaje. Entonces envias "bien"(1), "veni"(2), "do a"(3), " mi "(4), " blo"(5) y "g___"(6). Si por casualidad llegasen desordenados por ir por distinto camino podria reordenarlos.

Ademas, podemos ver que quedan datos en blanco. Si hubiera puesto tambien el tamaño del paquete, esos datos no se habrian emitido.

Las IPs de origen y destino, tambien las hemos explicado, asi que ahora vamos a por los puertos.

Si en un servidor ofrecemos distintos "servicios", como servicio de paginas web, servicios de correo o servicios de base de datos en el mismo equipo. ¿Como sabe el servidor que programa se tiene que hacer cargo de las peticiones que le haga otro equipo? Para eso están los puertos.

Un puerto es una marca adicional que sirve para que un equipo reparta los datos que recibe a los programas correspondientes. Veamoslo de forma mas detallada: el puerto 80 por defecto esta asignado al servidor web. Entonces si accedemos a la tienda online del ejemplo hacemos la solicitud a 12.34.56.78:80 (o sea, IP:Puerto) para poder entrar en su servidor web. El servidor ve que se lo han mandado al puerto 80 y automaticamente lo manda al programa que hace de servidor web. No lo manda al servidor de base de datos o al de correo electronico, que se preguntarian "¿y esto que es?" aparte de malgastar recursos en algo que solo va a dar error.

Pero esto que hemos visto es el puerto de destino, y hemos visto tambien que existe un puerto de origen. ¿Cual es su funcion? Exactamente la misma, pero a la hora de recoger las respuestas.

Ampliamos el ejemplo, ahora llevandolo mucho mas alla. Nuestro Amigo 1 coge su telefono movil (al que le vamos a poner la IP 1.2.3.4) y teclea la direccion de "tiendavirtual.com". Como en principio no sabe a que IP corresponde "tiendavirtual.com", pregunta a su servidor DNS cual es la IP correspondiente, y este le responde que es 12.34.56.78. El telefono de nuestro Amigo 1 ahora manda una peticion a 12.34.56.78:80 compuesta por uno o mas paquetes, que van cada uno por su camino. En esos paquetes pone como remitente 1.2.3.4:9999 (el puerto de origen en muchas ocasiones se escoge de manera aleatoria, en este caso he escogido 9999). El servidor que tiene la IP 12.34.56.78 recibe la peticion, mira que tiene el puerto 80 y envia esos datos al programa que funciona de servidor web, y este responde con los datos que pidio al remitente de los paquetes, esto es, a 1.2.3.4:9999. Al ver los paquetes, el telefono movil recuerda que el navegador habia lanzado una peticion con ese puerto y le envia el mensaje correspondiente, y se muestra en pantalla lo que Amigo 1 habia pedido.

Termino esta parte explicando un concepto nuevo, el firewall. Un firewall es un programa que bloquea las peticiones a un determinado puerto o a un determinado programa para protegerlo de ataques (entre otras posibles razones). Tambien puede bloquear los accesos restringiendo las IPs de origen (si bien un equipo determinado puede tener acceso a una base de datos, no debe permitirse el acceso a cualquiera).

Bueno, ya toca descansar un poco la cabeza. En la siguiente parte explicaré por que he usado como ejemplo a un equipo fuera de una red local y que es "abrir los puertos".

jueves, 1 de enero de 2015

Proyecto Redes: Parte III

Hoy voy a introducir un concepto nuevo, el DNS, y a ampliar un poco mas los posts anteriores, pero esta vez de forma mas interactiva.

Recordemos el caso anterior de la tienda online. La idea era la siguiente: para acceder a una tienda online mando paquetes de datos a su servidor y este me responde con otros paquetes. Sin embargo, ¿como se la IP de su servidor?

Mirad de nuevo la imagen del post. Podeis ver un servidor, que he puesto cerca de mi red local, llamado DNS. Los servidores DNS ("Domain name server" o servidor de nombre de dominio) funcionan al igual que un listin telefonico. Asocian nombres de dominio, como puede ser "tiendavirtual.com" con una direccion IP, como puede ser 12.34.56.78. Yo ya conozco la direccion IP del DNS ya que me la proporciona mi ISP (a traves del router), asi que cuando accedo a la tienda online hago lo siguiente.

1. Tecleo el nombre de la tienda en mi navegador (tiendavirtual.com)
2. Mi ordenador no sabe su IP, asi que se la pregunta al DNS (que puede ser un DNS o mi router, que se encargaria de pedirsela a otro DNS).
3. El DNS responde a mi ordenador que la IP de tiendavirtual.com es 12.34.56.78.
4. Mi ordenador envia los paquetes que van a tiendavirtual.com a la dirección 12.34.56.78.

Y pocos secretos mas tiene la navegacion web "basica".

Os preguntareis, ¿y por que ha metido esto aquí? Pues porque nos va a aparecer el concepto de DNS en el siguiente bloque.

Ahora viene la parte práctica. ¿Que tal si veis cada uno como funciona aplicado a vuestros equipos? Para ello, usaremos una serie de herramientas en nuestros ordenadores. Voy a dar las explicaciones para Windows, principalmente, y quizas alguna para Linux. OSX es muy parecido a Linux, por lo que los comandos seguramente os funcionaran.

Lo primero que debemos hacer es abrir una ventana de "simbolo de sistema" en Windows (en Accesorios) o de "terminal" en Linux.

Ahora vamos a ver cual es nuestra IP. Vereis que puede ser distinto en vuestros equipos. Mi configuracion es manual, y posiblemente la vuestra sea automatica (usando un protocolo llamado DHCP). Para ello, los que useis Windows teneis que teclear IPCONFIG. Os saldra algo parecido a esto (voy a tachar cierta informacion).


En vuestro equipo lo vereis mas simple. Nos vamos a centrar en las dos primeras conexiones, Adaptador Ethernet VirtualBox Host-only network y Adaptador Ethernet Conexiones de red inalambricas.

¿Veis que aparece la dirección IP? Cada conexion de red tiene su propia IP, una es la 192.168.56.1 y la otra la 192.168.1.100. Tambien existen una serie de direcciones IP mas largas, que he tachado, que utilizan un protocolo distinto al que estoy explicando. Vemos tambien que la conexion de red inalambrica (que es mi conexion principal) tiene una Puerta de enlace predeterminada (el router al que se mandan las peticiones para equipos fuera de mi red), que es 192.168.1.1. Podeis encontrar aun mas información si en vez de IPCONFIG tecleais IPCONFIG /ALL. En mi caso ocupa mas de una pantalla, pero si nos limitamos a una sola conexion podemos ver algo como esto:


Aqui no solo vemos el nombre de "Conexiones de red inalambricas" sino tambien el tipo de dispositivo, la "dirección fisica" (la MAC, que se asigna de forma unica para cada dispositivo de red por parte del fabricante), si la configuracion esta realizada de forma automatica (DHCP) y los servidores DNS. Es bastante mas informacion.

¿Y en Linux? Uso tres comandos distintos (lo hago en otro equipo, por eso los datos son distintos), ifconfig, cat /etc/resolv.conf y route -n y nos sale lo siguiente:


Tras teclear ifconfig encontramos como antes que tengo varias conexiones. La que me interesa es la tercera, la que aparece junto a wlan0, que es mi conexion inalambrica (eth0 es la conexion por cable, ahora desconectada). Me indica mi IP, 192.168.1.103, entre otros muchos datos sobre la calidad de la transmision.

El segundo comando, cat /etc/resolv.conf me informa de cual es mi DNS. En este caso me aparece que mi "nameserver" (NS) es 192.168.1.1, correspondiente a mi router.

La salida del tercer comando, route -n, es tambien mas complicada que lo que se ve en Windows. Dice que para las conexiones a cualquier IP en general (0.0.0.0) use como puerta de enlace la dirección 192.168.1.1.

He dejado muchas cosas sin explicar, puesto que esto es solo la introduccion a las redes, no un tratado exhaustivo.

La siguiente cosa que vamos a ver es el comando ping. Este comando manda una solicitud de respuesta a otro equipo para medir cuanto tarda en regresar.

Veamos los resultados de un ping a twitter desde Windows:


Envia cuatro paquetes de prueba y calcula lo que tarda, indicandonos el tiempo mas rapido, el mas lento y la media. Con Linux es identico, aunque si no marcamos el numero de paquetes que queremos enviar, con la opcion -c, lo hace de manera continua y hay que pararlo con CTRL+C. Aqui va el mismo ejemplo, con cuatro paquetes de prueba.

Podeis ver que twitter.com me responde desde distintas IPs. Lo he realizado desde distintos equipos en distintos momentos, asi que me responden varios servidores de Twitter segun su disponibilidad.

La siguiente herramienta que usare es Traceroute, que va indicandonos el recorrido que sigue un paquete de datos dentro de Internet. Aplicamos el comando tracert en Windows:


Y desde Linux, el comando traceroute:


En ambas trazas, observamos por que servidores pasa el paquete y que aparece el tiempo minimo, maximo y medio de los pings entre cada servidor. Tambien que hay servidores que no facilitan esa informacion, por seguridad.

Ahora, para no extenderme, os comento un par de comandos interesantes para Windows con respecto a los servidores DNS:

IPCONFIG /DISPLAYDNS: muestra las asociaciones nombre de dominio-IP mas recientes devueltas por los servidores DNS a vuestro equipo.
IPCONFIG /FLUSHDNS: borra esa tabla de asociaciones. Por si quereis comprobar como al borrarlos y volver a entrar en las paginas se vuelve a regenerar.

Linux, en las distintas distribuciones, puede almacenar o no una tabla similar. No puedo daros unos comandos equivalentes ya que no hay un estandar.

Lo se, la tercera parte ha sido larga y complicada. Tambien ha sido lioso explicarla. Si teneis dudas, que las tendreis, planteadlas en los comentarios en vez de guardaroslas. Las redes son un tema complicado y poco de lo que he explicado aqui es facil, y menos para gente sin conocimientos previos.


Aviso a los tiquismiquis: si, existen algunas cosas que no son 100% exactas, pero he sacrificado la exactitud para mejorar la comprension.