Si este fuera un blog maricón y pedagógico, este post arrancaría explicando que: «Se conoce como rogue a todo dispositivo que en tu red local… bla bla bla…» Me chupa un huevo. No te pienso explicar. Googlealo y volvé si querés. Este es un blog porongudo y poco pedagógico.

Yendo al tema; si nunca te pasó todavía, o bien podés considerarte el elegido o bien todavía no tenés la cantidad de horas de vuelo necesarias, pendejo, por que a todos los que vivimos del IT nos toca mas tarde o mas temprano:

Un servidor DHCP que no sabés de donde mierda salió entrega números de IP y te rompe la conectividad en la LAN, o te rompe el acceso a internet o como mínimo, las pelotas. Un serdivor DHCP rogue.

 

Típicos escenarios:

  • Una red lo suficientemente extensa en superficie edificada como para que te sea difícil hacerle un seguimiento exhaustivo.
  • Un pelotudo en la última oficinita del fondo del altillo del último piso habilitó por ejemplo la conexión compartida a internet.
  • O le pareció buena idea comprarse su propio router wireless por que la señal no le llega bien.
  • O algún dispositivo se puso en factory-defaults y se le encendió el DHCP server.
  • O alguien fué y se contrató su propia bajada de internet para su sección sin avisarte y el ISP le dió un router con DHCP activado.
  • O simplemente te la tiene jurada y te quiere cagar la vida, entonces sin quererlo o intencionalmente se pone a entregar números de IP a tu red.

Acto seguido, pelás tu packet sniffer de cabecera para dar con el hijo de puta que está sirviendo DHCP y con un poco de suerte, la mac addres del dispositivo agendada y una inspección/investigación visual, das con el dispositivo problemático y lo hacés mierda con el hacha que casualmente llevabas con vos desde que te empezó a pasar.

 

No saben lo difícil que se me puso esta vez encontrar que imagen ponerle a este post. Como no encontré, va Rogue, de X-Man

No saben lo difícil que se me puso esta vez encontrar que imagen ponerle a este post. Como no encontré, va Rogue, de X-Man

 

Continúa leyendo

«Dime cuantos paquetes de datos pierdes y te diré cuán como la mierda navegas.»

… O de como hacer uso y abuso del comando ping para verificar un enlace de datos.

Mas que nada en conexiones inalámbricas pero puede darse en cualquier otra circunstancia también y por motivos de lo mas diversos, además de una buena latencia es muy importante evitar la pérdida de paquetes de datos entre tu PC y su interlocutor a toda costa.

Hay miles de herramientas, algunas que funcionan en modo texto, otras tantas en modo gráfico que te permiten darte una idea muy aproximada de la calidad real de un enlace de datos pero si tengo que poner primera en la lista de las mas usadas al menos por mí –y creo que por el colectivo de informáticos también– definitivamente el comando ping para consola se lleva todos los laureles, además viene preinstalado de serie en cualquier sistema operativo, sea el que sea.

De todo corazón espero que no seas usuario de Windows. Si lo sos, entonces ni te gastes en seguir leyendo, por que si bien el comando ping para windows dispone de alrededor del 2% de las funcionalidades que nos provee el mismo para Linux, todo lo que voy a explicar a continucación queda sin efecto. Si sos usuario de Windows por otro lado, he aquí otra buena razón para tener siempre un Linux cualquiera a mano, en un CD, en un pendrive o en alguna partición pequeñita, por que nunca sabés cuando lo vas a necesitar.

Volviendo al asunto, no voy a entrar en detalles sobre el principio de funcionamiento del comando ping para Linux ni a explicar como entender la salida en pantalla del mismo (para los que se estén desayunando con esto por primera vez y les interese, los remito al manual del comando) si no a centrarme en una característica puntual que lo vuelve una de las mejores herramientas a la hora de hacer verficaciones de calidad de servicio mientras se hacen modificaciones sobre el enlace de datos: La capacidad de inundación, lo que en inglés se conoce como «Flood».

Ping para Linux es la navaja suiza de las herramientas de testeo de calidad del enlace y la capacidad de floodear que posee debe ser una de las mejores herramientas «graficas» para consola que podés encontrar por ahí. Unicamente disponible para superusuarios –necesitás privilegios de root para poder usar esta caraterística– te permite conocer con presición como anda la cosa mientras toqueteás algún que otro parámetro en tu router.

La genialidad de la opción flood radica en su principio de funcionamiento: Por cada paquete de datos que se envía se imprime un punto -un » . «- en la pantalla. Por cada paquete de datos que se recibe, se borra un punto. Eso es todo.

El nombre de «flood» o inundación que sería la traducción literal proviene del hecho de que el kernel no esperará absolutamente nada entre un paquete enviado y otro, inundará la red con peticiones usando el protocolo ICMP tan rápido con el enlace en si mismo lo permita y a menos que específicamente le habilites el modo «adaptativo» pasandole al comando la opción » -A » forzará al enlace a todo lo que dé produciendo inevitablemente fallos que serás capaz de visualizar a golpe de ojo nada mas viendo como se van imprimiendo (o no) puntitos en la pantalla en tiempo real.

Dependiendo del escenario puede que te interese verificar cuanto es el máximo ancho de banda disponible en un enlace inalámbrico o cuantos paquetes pierde tu conexiòn a internet por culpa de lo anterior. Suponiendo que quisieramos hacer esta última prueba, haciendo ping contra el servidor de DNS de Google por ejemplo, el comando en cuestión es tan simple como lo que sigue:

ping -f 8.8.8.8

Que en una red sana debería devolverte algo como esto:

Usando ping con flood habilitado para verificar el estado de la conexión.

Usando ping con flood habilitado para verificar el estado de la conexión.

Y que por otro lado, en una red con problemas, debería devolverte esto otro:

Verificando una red con problemas de pérdida de paquetes con ping.

Verificando una red con problemas de pérdida de paquetes con ping.

Todos los puntitos que se ven en la última captura representaron en tiempo real la pérdida de paquetes que hubo durante todo el proceso. Usé además la opción «count» representada por » -c » para pedirle a ping que solo envíe 1000 paquetes y se detenga a continuación.

Es muy util también la opción «size» para especificar el tamaño de paquete, esto sirve para diagnosticar otro tipo de problemas por ejemplo cuando estás jugando con el MTU de tus routers o interfaces de red o el RTS o el Fragemnation Threshold de tu router inalámbrico.

Como la cabecera del protocolo ICMP utiliza siempre 8 bytes, para forjar un paquete por ejemplo de 512 bytes de tamaño necesitas tener estos 8 bytes en cuenta, restándoselos al momento de ejecutar el comando:

ping -f -c 1000 -s 504

Es muy común ver como una red inalámbrica se desempeña a la perfección con paquetes de datos pequeñitos, los de 64 bytes que envía ping por defecto (la cabecera ICMP + 56 bytes adicionales) cuando no se le especifica el tamaño pero se viene todo a pique cuando el tamaño de paquete excede los 512 o 768 bytes, por ejemplo. Y ni hablar de cuando excede al MTU que por defecto en este tipo de redes es de 1500 bytes.

También es muy útil a la hora de testear redes que tienen implementado QoS por que permite especificar los bits ToS en la cabecera del paquete, con lo que podés ver en tiempo real que tal se desempeña tu router en este sentido. Por ejemplo para el ToS «Maximice Data Throughput» basta con ejecutar:

ping -f -c 1000 -s 504 -Q 0x08

Ping: La herramienta que no te puede faltar a la hora de aislar fallos puntuales en una red. Preinstalada por defecto y gratis. ¿Que mas se puede pedir?

Calidad de servicioAyer leyendo Un Sanjuanino en Rio Cuarto me dí con una entrada mencionando un vínculo a HowtoForge donde se plantea la alternativa mas facil que he visto hasta ahora para tener una implementación de QoS (por Quality of service en inglés: calidad de servicio) que aunque rudimentaria es totalmente funcional.

Se puede extender a cualquier otra disciplina de encolado y mejorar en función de las necesidades de cada uno, así que vamos a los bifes.

Requisitos necesarios:

  • Kernel con soporte para iptables.
  • Iptables instalado.
  • El comando tc instalado, que es parte del paquete iproute2
  • Opcional, l7filter para iptables.

Cualquier distribución orientada a servidor/router o redes en general ya trae estos tres requisitos preinstalados y configurados. En caso de no ser así basta con usar el gestor de paquetes de cabecera para instalar iproute2 e iptables, y seguir cualquier guía de configuración del kernel para darle soporte a iptables.

Esquematizando un poco:

El esquema de mi red es exactamente el mismo del ejemplo de howtoforge:

[internet]<–>[cablemodem]<–>[eth1  linux  eth0]<–>[red local]

Queda en cada uno adaptar las siguientes instrucciones para la topología de su red.Continúa leyendo