Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
lunes, 19 de febrero de 2024
Inocentada: La verdad detrás del coqueteo de QUIC y BGP
jueves, 23 de febrero de 2023
El juego del dominó y TCP/IP
En mi vida, al igual que muchas personas, tengo varias pasiones: familia, trabajo, deporte; y en este último incluyo el hermoso juego del dominó. Hace unos 25 años alcancé mi mejor nivel en este juego, participé de varios torneos (ganando algunos pocos) y la guinda de la corona, obtuve un 6to lugar en un torneo nacional. Adicionalmente, menciono que vengo de una familia con alguna herencia de fanáticos del dominó, como lo eran dos tíos, mi padre y mi hermano.
Jugar dominó es una de las cosas más lindas entre familia, amigos y no tan amigos. Ahora bien, ¿en qué se parece el juego del dominó al protocolo TCP/IP? Alguno quizás ya debe estar pensando “Alejandro ahora sí se volvió loco”; quizás no me volví loco, probablemente ya lo estaba.
Pero ese no es el punto, te demostraré que TCP/IP y el dominó tienen mucho en común.
Los protocolos TCP/IP según IBM [1] lo definen como:
“Los protocolos son conjuntos de normas para formatos de mensaje y procedimientos que permiten a las máquinas y los programas de aplicación intercambiar información. Cada máquina implicada en la comunicación debe seguir estas normas para que el sistema principal de recepción pueda interpretar el mensaje.”
Suena interesante…, pero probablemente aún no veas qué tiene que ver con el dominó, y sigues pensando que es una locura. ¡A no desesperar, ya vamos a llegar!
Y el Dominó (según chatgpt):
“El juego de dominó es un juego de mesa en el que los jugadores utilizan fichas con números en ambos extremos para colocarlas en un tablero. El objetivo del juego es colocar todas las fichas antes que los demás jugadores. La comunicación entre los jugadores en el juego de dominó se basa en la estrategia y en la planificación. Los jugadores deben comunicar qué fichas tienen y qué fichas pueden jugar, y deben trabajar juntos para encontrar la mejor manera de colocar las fichas en el tablero. Además, los jugadores deben estar atentos a las jugadas de los demás jugadores y adaptar su estrategia en consecuencia. En resumen, la comunicación en el juego de dominó es esencial para el éxito del equipo y para ganar el juego.”
Ahora, pensemos un poco macro, a estas alturas podemos apreciar que en ambos hay piezas que deben ser enviadas/jugadas, y las mismas deben mantener un orden para poder alcanzar una comunicación exitosa. Además, en ambos hay estrategia y planificación para lograr el objetivo, en uno se conectan las piezas y en el otro dispositivos, ¿ya comencé a convencerte?
Ahora hablemos de comunicación y el Dominó en parejas, y es aquí donde está el corazón del tema al que quiero llegar.
Independiente del estilo de dominó que cada uno juegue (Cubano, Latino, Méxicano, Chileno, etc) “el dominó en parejas” es un juego de comunicación, no es diferente a una red de datos. Un jugador tiene que comunicarse con su pareja (A → B, B → A) para indicarle qué piezas tiene o no.
Igualmente, ¿cómo me comunico si una de las reglas es no poder hablar?. Allí está la grandeza de los buenos jugadores, al igual que TCP/IP -y cualquier otro protocolo de comunicación- hay que seguir ciertas reglas.
Luego de mis tres décadas de experiencia en ambos mundos, aquí les dejo lo que considero los principales jugadas en el ecosistema del dominó en parejas y su contraparte en TCP/IP:
La salida en el dominó
La salida en el dominó (primera pieza que coloca el salidor) es idéntica a un SYN Packet de TCP (y más específicamente es un SYN con payload al estilo TCP Fast Open). Esta es una comparación hermosa, porque la salida en el dominó por parejas *siempre* lleva información, generalmente se refiere al palo (número) que uno más desea. TCP Fast Open (una lindura del mundo de TCP) se encuentra definido en el RFC 7413 y su principal objetivo es poder enviar información en el primer paquete con en el que comienza toda comunicación TCP (SYN)
La pensada (double ACK)
Se considera payload no necesario en algunas redes pero puede valer la pena. La “pensada” de un jugador indica explícitamente que el jugador tiene más de una pieza del “palo” (número) jugado; con ello, el jugador está comunicando eficientemente información a su compañero quien debe darse notar estas pensadas, es muy similar a aquellos servidores y redes donde se configuran dispositivos para enviar más de un ACK en TCP (acuso de recibo)
Pasar (packet dropped)
En TCP al perder un paquete se entra en la fase de “Congestion Avoidance”, allí disminuye en un 50% la ventana TCP y por ende la velocidad de transmisión. Nada más similar al pasar en dominó; claro, aquí se entra en etapa de pánico, sobre todo cuando hay mucho que transmitir.
La versión
En el mundo de IP estamos acostumbrados a IPv4 e IPv6, en el dominó la única diferencia es que la versión va del 0 (blancas) al 6. (si, si, ciertamente existen Dominoes hasta 9, toda regla tiene su excepción ;-)
Pensar en falso
TCP Half-Open, ¿se recuerdan?, es cuando en el saludo de tres vías (SYN, SYN+ACK, ACK) se queda en la mitad del saludo (ojo, este es el concepto moderno, en honor a la verdad no respeta RFC 793). También es comúnmente utilizado para realizar ataques de DoS.
Tamaño de la carga (Total Length)
Cuando vamos levantando nuestras fichas en dominó, ¿cuántos -puntos- cargué?.
La dirección origen y el destino
Aquí nos encontramos específicamente en el mundo de capa 3. Este es un caso muy interesante donde, al igual que en redes de comunicación, un host se comunica con algún otro. Lo mismo sucede en el dominó, es decir, algunos paquetes pueden ir orientados al compañero; sin embargo, en algunos casos se puede orientar a los oponentes según la necesidad (ejemplo, cuando se busca “tal palo”).
Pensar en cada jugada
Bufferbloat es una situación muy particular pero a su vez ocurre con mucha frecuencia. Básicamente son situaciones donde los hosts (principalmente middlewares al estilo, routers, firewalls, Switches) agregan delay (cargando los buffers) al momento de conmutar los paquetes. Lo anterior crea latencia y jitters innecesarios. Por favor, si administras redes no dejes de revisar si sufres de bufferbloat..
Trancar la partida/mano
Es el momento donde ya es imposible jugar alguna pieza de dominó, y en TCP/IP supone la caída de la red, por lo que tampoco se puede enviar ningún paquete.
Consecuencias de la buena y mala comunicación
En dominó en pareja, al igual que en cualquier protocolo de red, comunicarse bien o mal trae sus consecuencias. Si uno tiene buena comunicación en el dominó alcanzará -muy seguramente- la victoria. Si la comunicación *no* es buena, el resultado será la pérdida del partido. En TCP/IP si la comunicación es buena se establecerá la conexión correctamente y se entregarán los datos. Si la comunicación es mala, obtendremos datos corruptos y/o el no establecimiento de la conexión.
Doble Cabeza
En el dominó se entiende que tienes doble cabeza cuando llevas la última pieza de dos números diferentes. ¿Con qué se puede comparar? Con TCP Multipath (MPTCP), definido en el RFC 8684.que permite operar conexiones por diferentes caminos. Es por ello que MPTCP ofrece redundancia y eficiencia en el ancho de banda a consumir.
¿Aún no los convencí? Bueno, tengo una oportunidad más a ver si lo logro.
A continuación les presento un modelo capa a capa entre TCP/IP vs dominó
Modelo TCP/IP (+ capa de usuario) | Modelo Dominó |
Usuario | Jugador |
Aplicación | Construir la jugada |
Transporte | Seleccionar la ficha/piedra |
Red | Tomar las piedras |
Enlace | Piedras/Fichas |
Física | Colocar en la mesa la ficha |
Un paquete en el modelo TCP/IP se construye desde las capas superiores a las inferiores (posteriormente se inyecta a la red, etc), lo recibe el host destino y lo procesa “a la inversa”, desde la capa física hasta la aplicación. En el modelo dominó, ocurre exactamente igual: el jugador arma su jugada, selecciona su ficha/piedra, la toma para luego inyectarla en el juego.
Conclusión
La comparación entre el juego de dominó en parejas y el protocolo de comunicación TCP/IP puede parecer extraña al principio. Sin embargo, si observamos con atención, podemos encontrar similitudes, En el dominó existen dos jugadores que actúan como emisores y receptores de información, ya que cada uno tiene su propio conjunto de fichas y deben comunicarse entre sí para decidir qué ficha jugar en cada turno. Del mismo modo, en TCP/IP existen dispositivos que actúan como emisores y receptores de información.
Estos contrastes ilustran cómo a menudo pueden existir similitudes entre sistemas aparentemente disímiles, y que comprender estas semejanzas pueden ser útiles para entender conceptos complejos y ver las cosas desde una perspectiva diferente.
jueves, 10 de abril de 2014
Super sencillo sniffer en python3
Luego de mucho sufrir y mucho buscar logre adaptar con muy pocos cambios un sniffer que esta en python2 y llevarlo a python3..., es el unico sniffer que me ha funcionado usando python3.3. Lamentablemente es MUY basico pero creo que alguien le puede servir, por ello se los dejo.
Al menos captura y muestra origen, destino, puertos TCP e incluso la data en hex. Lo que no he podido hacer es "unpack" la data sobre TCP.
-----
#!/usr/bin/python3.3
#Sniffs only incoming TCP packet
import socket, sys
from struct import *
#create an INET, STREAMing socket
try:
s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_TCP)
except:
print ('Socket could not be created. Error Code : ' + str(msg[0]) + ' Message ' + msg[1])
sys.exit()
# receive a packet
while True:
packet = s.recvfrom(65565)
#packet string from tuple
packet = packet[0]
#take first 20 characters for the ip header
ip_header = packet[0:20]
#now unpack them :)
iph = unpack('!BBHHHBBH4s4s' , ip_header)
version_ihl = iph[0]
version = version_ihl >> 4
ihl = version_ihl & 0xF
iph_length = ihl * 4
ttl = iph[5]
protocol = iph[6]
s_addr = socket.inet_ntoa(iph[8]);
d_addr = socket.inet_ntoa(iph[9]);
print ('Version : ' + str(version) + ' IP Header Length : ' + str(ihl) + ' TTL : ' + str(ttl) + ' Protocol : ' + str(protocol) + ' Source Address : ' + str(s_addr) + ' Destination Address : ' + str(d_addr))
tcp_header = packet[iph_length:iph_length+20]
#now unpack them :)
tcph = unpack('!HHLLBBHHH' , tcp_header)
source_port = tcph[0]
dest_port = tcph[1]
sequence = tcph[2]
acknowledgement = tcph[3]
doff_reserved = tcph[4]
tcph_length = doff_reserved >> 4
print ('Source Port : ' + str(source_port) + ' Dest Port : ' + str(dest_port) + ' Sequence Number : ' + str(sequence) + ' Acknowledgement : ' + str(acknowledgement) + ' TCP header length : ' + str(tcph_length))
h_size = iph_length + tcph_length * 4
data_size = len(packet) - h_size
#get data from the packet
data = packet[h_size:]
print ('Data : ' + str(data))
print ()
(solo captura TCP pero es muy sencillo adaptarlo a otros protocolos)
------
Basado en:
http://www.binarytides.com/python-packet-sniffer-code-linux/
jueves, 27 de diciembre de 2012
Que hacer cuando falla "clear line N" en Cisco
Al realizar un "clear line" en Cisco para desconectar una sesión Telnet o SSH sencillamente sigue apareciendo el usuario.
Ejemplo:
IMP#sh user
Line User Host(s) Idle Location
2 vty 0 aacosta idle 00:00:01 a.b.c.d
* 4 vty 2 pepe idle 00:00:00 xx.yy.zz.dd
Queremos sacar a pepe del equipo y realizamos:
IMP#clear line vty 2
y sigue apareciendo:
IMP#who
Line User Host(s) Idle Location
2 vty 0 aacosta idle 00:00:39 a.b.c.d
* 4 vty 2 pepe idle 00:00:00 xx.yy.zz.dd
Procedimiento y solución:
Hay dos manera de hacerlo:
a) Manera rápida y 99% seguro que funciona (y menos probabilidades de error de dañar otra cosa). En vez de utilizar "clear line vty" utilizaremos "clear tcp line":
Así (nuevamente para desconectar a pepe):
IMP#clear tcp line 2
[confirm]
[OK]
lunes, 12 de septiembre de 2011
Ejemplos de hping
Enviar paquetes TCP SYN al puerto 0 en la máquina example.com (nótese que hping incrementara el puerto origen en 1 por cada paquete enviado):
#hping example.com-S-V
Enviar los paquetes TCP SYN al puerto 443 en el host example.com:
#hping example.com -S-V-443 p
Enviar paquetes TCP al puerto 443 en el host example.com con los flags SYN + ACK encendidos en conjunto:
#hping example.com-S-A-V-443 p
Enviar paquetes TCP al puerto 443 en el host example.com con el SYN + ACK FIN + set:
#hping example.com -S-A-F-443 V-p
Enviar paquetes TCP SYN cada 5 segundos en el puerto 443 en el host example.com:
#hping example.com -S-443 V-p-i 5
Enviar paquetes TCP SYN cada 100.000 microsegundos (es decir, cada 0,1 segundos o 10 por segundo) en el puerto 443 en el host example.com. Tenga en cuenta que se ha eliminado detallado:
#hping example.com -S-p 443-i u100000
Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada 0,01 segundos, o 100 por segundo) en el puerto 443 en el host example.com:
#hping example.com-S-p 443-i u10000
Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada segundo de 0,01 o 100 por segundo) en el puerto 443 en el host example.com. Parar después de 500 paquetes:
#hping example.com-S-p 443-i-c u10000 500
Enviar paquetes UDP al puerto 111 en el host example.com (argumento - udp puede ser sustituido por -2): #hping example.com - udp-V-111 p
Enviar paquetes ICMP echo request para recibir example.com (argumento - icmp puede ser sustituido por -1):
#hping example.com - icmp-V
Enviar ICMP paquetes de solicitud de marca de tiempo para organizar example.com:
#hping example.com - icmp - icmp-ts-V
Escaneo de puertos TCP 100 a 110 en el host example.com (argumento - el examen puede ser sustituido con -8)
#hping example.com-V - scan 100-110
Enviar paquetes UDP falsa a partir de host de origen para recibir 192.168.1.150 example.com
#hping example.com - udp - parodia 192.168.1.150
Enviar paquetes UDP falsa a varios de IP de origen aleatoria para recibir example.com
#hping example.com - udp - rand-fuente
Enviar paquetes UDP con la parte de datos rellena con 100 bytes para albergar example.com
#hping example.com-V - udp - los datos de 100
Enviar paquetes UDP con la parte de datos rellena con 100 bytes, pero con el contenido de payload.txt para albergar example.com (la carga útil se truncará si es menor de lo especificado por el argumento - de datos)
#hping example.com-V - udp - payload.txt archivo - los datos de 100
Más info:
El presente documento es una traducción con una pequeña adaptación de:
http://rationallyparanoid.com/articles/hping.html (documento sencillo y practivo que me pareció excelente)
miércoles, 7 de septiembre de 2011
Utizando Netem. Simulando escenarios de red. Ejemplos de tc/netem
Deseo simular algunos escenarios de red.
a) Simular en un salto satelital
b) Simular perdida de paquetes
Lo anterior es de mucha utilidad porque permite probar escenarios -casi reales-. Se pueden probar aplicaciones y conocer como se comportan ante una alta tasa de pérdida de paquetes y/o ante altos tiempos de respuesta. Otra opción es conocer el comportamiento ante pérdidad y/o RTT aleatorios y muchas otras cosas.
Solución:
Netem (Network Emulacion) que permite simular escenarios de red muy tipicos en redes WAN, MAN y Satelitales.
Netem es controlado con el comando tc que es parte de iproute2
Ejemplos:
a) Simular el Round Trip Time de un salto satelital (550 ms):
# tc qdisc add dev eth0 root netem delay 550ms
Fijense del tiempo del ping antes y durante el comando (salto del 10 al 11):
[root@localhost ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=48.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=51.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=50.4 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=51.1 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=53 time=600 ms
b) Simular una red WAN con tiempos de mayor variación (de 100 ms - 10 ms) de manera aleatoria:
# tc qdisc change dev eth0 root netem delay 100ms 10ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=53 time=49.3 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=53 time=50.5 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=53 time=59.6 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=53 time=50.7 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=53 time=49.6 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=53 time=143 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=53 time=152 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=53 time=157 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=53 time=153 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=53 time=159 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=53 time=155 ms
c) Simular perdida % de paquetes:
# tc qdisc change dev eth0 root netem loss 0.1%
El comando anterior ocasiona una pérdida de 1/1000 paquetes descartados de manera aleatoria
Más opciones:
Existen muchas otras opciones como:
a) Duplicar paquetes
# tc qdisc change dev eth0 root netem duplicate 9%
b) Corromper (dañar) un paquete:
# tc qdisc change dev eth0 root netem corrupt 0.1%
Mas información:
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/
viernes, 22 de abril de 2011
MEDICIÓN Y ANÁLISIS DE TRÁFICO TRANSPORTE EN UNA RED SATELITAL
Resumen: Las redes satelitales se han convertido en una solución para la conectividad de sitios remotos donde la conexión terrestre no llega o es muy costosa llevarla a través de los medios masificados. En este articulo se presentan los primeros resultados de la observación, análisis y caracterización del tráfico transporte de la red VSAT propiedad de la empresa British Telecom Latinoamerica (BT Latam) en Venezuela. Hicimos especial énfasis en el Acelerador TCP el cual incrementa, considerablemente para el trafico de datos hacia la VSAT, el rendimiento de las transferencias TCP. Este articulo corresponde al primero de un estudio inédito en el país y, en nuestro mejor esfuerzo de búsqueda, en Latinoamérica.
Los links para el articulo completo son:
- Saber-ULA http://www.saber.ula.ve/handle/123456789/32810
- VIII Congreso Internacional de Ingeniería Electrónica y Tecnologías de Avanzada CIETA Universidad de Pamplona. Link directo al archivo PDF del programa de Ponencias: aqui
BGP Stream: un año de análisis sobre incidentes BGP
BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta la prim...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...