Categories
diseño tcp-ip

¿Pensáis que IPV6 es más rápido que IPV4?

Un compañero vuestro de clase ha propuesto este interesante tema para discutirlo. Como punto de partida, os dejo su opinión:

La respuesta es que no, IPV4 resulta ser un poco más rápida que IPV6. Esta afirmación es como
resultado de que “RIPE” , elaboró un estudio sobre qué tecnología era la más rápida. Mientras
que un análisis comparativo realizado por “Compuware” entre urls de ambos protocolos
muestra que los sitios IPv6 son un 80% más lento que sus homólogos IPv4.
En un futuro en el que probablemente IPV6 estará destinado a sustituir a IPv4 (cuyo límite en el
número de direcciones de red admisibles está empezando a restringir el crecimiento de
Internet), al margen de esto planteo las siguientes preguntas:
¿Consideráis esto un avance tecnológico o más bien un retroceso?
¿Pensáis que puede ser solamente una estrategia económica para vender dispositivos que
admitan IPV6 o no?
¿Que tecnología prefieres actualmente IPV4 o IPV6? ¿Cuáles son los motivos?

Recordar que los argumentos, deben ser razonados. Por si os sirve de ayuda, revisad esta entrada anterior

Categories
hardware de red tcp-ip

¿Cómo podemos saber si nuestro ISP cumple o no con la Neutralidad de red?

Estos últimos días hemos asistido al debate en el Senado de una moción en defensa de la neutralidad de la red y los debates posteriores generados en los medios, sobre todo, en Internet.

El objetivo de esta entrada no es entrar en esas discusiones. Independientemente de la existencia o no de este tipo de leyes, ¿estamos seguros de que nuestro ISP no prioriza determinado tráfico? ¿Estamos seguros que cuando usamos determinados protocolos, estos no están siendo penalizados?

Con esta entrada me gustaría que, entre todos, aprendiéramos de los mecanismos que existen para comprobar si se está o no aplicando la neutralidad de red, los debatiéramos e hiciéramos un listado de comprobaciones que nos permita saber qué actitudes toma nuestro ISP. También existe software implementado que realiza estas acciones: podemos hacer un listado.

Seguro que esta entrada, además de para aprender, si lo hacemos bien, nos aporta información útil para tomar decisiones en casa ;-).

Categories
seguridad tcp-ip

Captura y análisis de paquetes de red

En esta entrada vamos a cambiar un poco la forma de trabajar con respecto a lo que ha sido habitual hasta ahora: vamos a realizar una tarea y vamos a comentarla analizando los resultados.

Una de las tareas de un administrador de red es monitorizar el tráfico de sus redes, aunque en esta entrada nos vamos a centrar en la captura y análisis de paquetes de red.

Para realizar esta tarea contamos con Wireshark: analizador de tráfico de red multi-plataforma que intenta capturar paquetes de red y mostrar dichos paquetes en tanto detalle como sea posible (está disponible en el DVD de la EPS).

La tarea a realizar consiste en ejecutar Wireshark en una red (la del laboratorio o la de casa, como queráis) y capturar los paquetes que circulan por dicha red. Para generar tráfico, abrid un navegador y conectaros a http://www.eps.ua.es.

En los comentarios de esta entrada debéis copiar las cabeceras de 10 paquetes que capturéis con esta herramienta e indicad qué información habéis obtenido de ellos. También podéis comentar las interpretaciones de otro compañero con la información de los paquetes que nos proporciona (siempre y cuando ampliéis o corrijáis lo que se dice) .

Categories
General servicios tcp-ip

DNS + Blogs

Vuestro compañero Daniel Navarro, propone esta entrada para comentar en el blog:

Tenemos un servidor que da un servicio web (por ejemplo apache).
Los dominios y los contextos del servidor se van añadiendo de forma automática
a través de un formulario de alta para los clientes, el cual añade a la
configuración DNS la entrada correspondiente al dominio dado
de alta y a su vez añade en la configuración del servidor web el contexto
para que pueda servir este dominio.

Ejemplo:
Cliente: prueba

Dominio: prueba.misblogs.com

Entrada en el DNS:  =prueba:X.X.X.X:300

Contexto de apache: ServerName prueba.misblogs.com

El problema que se plantea es que desde que un cliente se da de alta hasta
que puede acceder a su blog puede pasar tiempo, ya que tienen los DNS que
utilice este cliente que actualizar la zona. ¿Se podría hacer alguna
configuración en la cual no hiciese falta actualizar el DNS cuando se diese
de alta un nuevo cliente?
Planteo el siguiente tema: Tenemos un servidor que da un servicio web (por
ejemplo apache). Los dominios y los contextos del servidor se van añadiendo
de forma automática a través de un formulario de alta para los clientes, el
cual añade a la configuración DNS la entrada correspondiente al dominio dado
de alta y a su vez añade en la configuración del servidor web el contexto
para que pueda servir este dominio.

Ejemplo:
Cliente: prueba

Dominio: prueba.misblogs.com

Entrada en el DNS:  =prueba:X.X.X.X:300

Contexto de apache: ServerName prueba.misblogs.com

El problema que se plantea es que desde que un cliente se da de alta hasta
que puede acceder a su blog puede pasar tiempo, ya que tienen los DNS que
utilice este cliente que actualizar la zona. ¿Se podría hacer alguna
configuración en la cual no hiciese falta actualizar el DNS cuando se diese
de alta un nuevo cliente?
Categories
diseño General tcp-ip

Geolocalización IP

Existen diversas herramientas (como ésta) que permiten a cualquier desarrollador o webmaster aplicar tecnologia de geolocalización para poder determizar la situación geografica de cualquier dirección IP (por ejemplo para la auto seleccion de idiomas, zona horaria,…)

En esta entrada, dirigida sobre todo a los que tenéis que aprobar esta parte para la convocatoria de Julio (aunque no excluye a nadie 😉 ), volvemos a aplicar la técnica de aprendizaje denominada “Caza del tesoro”.  El objetivo es recopilar información sobre la Geolocalización IP: cómo se realiza, tecnologías involucradas,…

El comentario debe consistir en: URL donde reside la información y descripción de la información que podemos encontrar en ella.

Categories
General seguridad tcp-ip

Protocolo de transporte p2p

Hemos comentado varias veces en clase el tema de los filtros anti-p2p en Internet y la cabezonería de algunos gobiernos de intentar “ponerle puertas al mar“.

En meneame he encontrado esta noticia referente al protocolo de transporte de p2p. En el resumen se comenta:

El cliente para intercambio P2P de ficheros de BitTorrent, uTorrent, ha cambiado, como respuesta a un sistema de filtrado de la compañia Bell Canada, el protocolo de transporte de ficheros por defecto de TCP a UDP, que antes sólo usaba como protocolo para intercambio de trackers. Otras aplicaciones, concretamente las de VoIP, juego en red y videoconferencia, usan ese mismo protocolo, con lo que las medidas que los ISP puedan tomar, como limitar ese protocolo por el alto tráfico generado, puede afectar mucho la calidad de esos servicios.

Por otra parte, un compañero vuestro (Antonio Manuel Espinosa) me propuso una entrada relacionada con el p2p:

Es muy comun el utilizar programas de intercambio como emule, y como administradores de una red, sabemos lo que ocasiona este tipo de trafico en una red, por lo que una posible entrada para nuestro blog seria el como afectaría ( o como afecta ) el trafico p2p a las redes, y cual sería la solución para aligerar la red. Así como si las medidas que piensan llevar a cabo los operadores son adecuadas o no.

¿Qué pensáis vosotros? Los comentarios deben ir enfocados a argumentaciones sobre:

  • Cómo afecta al tráfico p2p a otros servicios de la red y consecuencias.
  • Posibles soluciones para la convivencia de estos servicios y protocolos.
  • Qué pensáis que supone la estrategia de cambiar el protocolo de transporte de TCP a UDP de los protocolos p2p.
Categories
General seguridad servicios tcp-ip

Ponerle puertas al mar

Pues eso, estamos de nuevo con el socorrido tema de filtrar-controlar-… el P2P para “acabar” con el “pirateo” de música, pelis, etc.

He leído (a través de barrapunto) el artículo del diario Público en el que se analiza la intención de las grandes operadoras de tomar el ejemplo de Gran Bretaña y Francia para limitar el uso de las redes P2P.

Al margen de los comentarios políticos-económicos y de los morales, si nos centramos en los técnicos, podríamos aprender mucho simplemente pensando en cuáles son los pasos que, como administradores de redes, realizaríamos para conseguir el objetivo marcado por “los jefes”; ver qué se puede hacer, qué conseguiríamos y que no, nos puede ayudar a aprender de redes, TCP/IP, filtros,…

Si no nos queremos calentar la cabeza, siempre están las iptables y el módulo ipp2p que realizan un trabajo aceptable (aunque no perfecto)

IPP2P identifies P2P patterns in TCP and UDP packets, the default behavior is to search TCP traffic
only. The need to specify “-p tcp” is reversed with IPP2P version 0.7-pre2 and above. You now have
different ways to search UDP and TCP packets:
iptables -A FORWARD -p tcp -m ipp2p –bit -j DROP /*TCP traffic only*/
iptables -A FORWARD -p udp -m ipp2p –bit -j DROP /*UDP traffic only*/
iptables -A FORWARD -m ipp2p –bit -j DROP /*UDP and TCP traffic*/

Categories
General seguridad servicios tcp-ip

Direcciones IP y datos personales

Existe un dicho que dice que “todo depende del color del cristal con el que se mire”.

La Unión Europea (y también el Gobierno de España) considera la dirección IP como un dato de carácter personal, por lo que debe ser tratado según dicta, para el caso español, la Ley de Protección de Datos (para más información).

Google no opina lo mismo. Argumenta que una IP cambia constantemente (para eso está el DHCP pensarán 😉 ) y que la dirección IP sólo proporciona información del usuario a los ISP (ya que éstos, cruzando datos, pueden saber a qué usuario le corresponde, en un momento dado, una dirección IP).

¿Quién pensáis tiene razón? ¿O quién se saldrá con la suya?

Dos preguntas que pueden no tener la misma respuesta…

Categories
General servicios tcp-ip

Prácticas recomendadas de DHCP

Instalar y configurar los parámetros de red de todos los nodos de una LAN, se puede centralizar y automatizar mediante DHCP. Esto es aplicable en entornos heterogéneos, es decir, con variedad de clientes (Windows, Linux, Mac,…). Es posible que nos encontremos con la circunstancia de que, bien por disponibilidad, bien por carga, instalemos más de un servidor de DHCP para gestionar este proceso.

En la página de Microsoft (opción, a la derecha, de prácticas recomendadas) dicen que una práctica recomendable para distribuir la carga entre dos servidores DHCP es la llamada regla de diseño 80/20. Dicha regla consiste en distribuir el 80% de las direcciones disponibles para una red entre un primer servidor de DHCP y el 20% restante mediante un segundo servidor. ¿Qué pensáis? ¿Palabra de Microsoft? 😉 ….

Categories
General tcp-ip

Encaminamiento regulado

Por fin uno de vosotros (un compañero vuestro) se ha lanzado y propone un tema que, bajo mi punto de vista y desde el enfoque de la administración de redes de computadores, me parece MUY interesante.

Os animo a los demás a seguir su ejemplo.

Aquí os lo dejo. La idea es que, como en las entradas anteriores, expongáis otros ejemplos de escenarios en los que es interesante y útil el dirigir paquetes mediante encaminamiento regulado.

Edito: Por si alguien tiene dudas, os aclaro que también se pueden usar los ejemplos expuestos en clase. Lo que no debéis es repetiros en los comentarios.

——————–

Autor de la entrada: Juan Galiana

Texto:

Encaminamiento regulado es la capacidad de encaminar entre distintas redes en base a la información que contiene la cabecera o datos de los paquetes que circulan por ellas. Se pueden crear normas para clasificar los paquetes que vendrán determinadas de varias maneras: dirección origen, destino, interfaz entrante, TOS y fwmark. En concreto iproute2 permite usar la información de marcado de iptables (fwmark) para encaminar por una ruta u otra los paquetes dependiendo de estas marcas.
Utilidades que puede tener esto:

No sólo podemos usar información de la cabecera (como por ejemplo puerto, o tipo de protocolo) sino también otra información extendida que permite iptables, aunque es un dato propio de una máquina y no de una red, vamos a redirigir por ejemplo el tráfico TCP del usuario con UID 1000 por la IP 172.16.70.70 y dispositivo eth1, (los demás irán por la ruta por defecto):
1)# echo “200 FILTRO”>> /etc/iproute2/rt_tables
2)# ip rule add fwmark 1 table FILTRO
3)# ip route add table FILTRO via 172.16.70.70 dev eth1
4)# iptables -t mangle -A OUTPUT -p tcp -m owner –uid-owner 1000 -j MARK –set-mark 1

1) Creamos la tabla en el rt_tables
2) Añadimos una regla, asociando nuestra tabla FILTRO con la marca “1” en los paquetes.
3) Añadimos una ruta para la regla FILTRO, configurando que saldrán por lainterfaz eth1, ip 172.16.70.70
4) Marcamos con iptables el tráfico TCP del usuario con UID 1000 con la marca “1”
El redirigir tráfico de un UID específico puede servirnos para salir a Internet por una interfaz distinta (otra interfaz física o vpn) cuando la ruta por defecto no permita el paso de ese tipo de tráfico, simplemente corriendo el proceso con uid distinto.
El marcado por UID es un ejemplo curioso que permite iptables, pero también se podrían marcar por otros características como tipo de protocolo de transporte TCP o UDP, marcarlo con distintas marcas y luego asociar rutas distintas mediante reglas que asocien estas marcas con la ruta que nos interese.