Iptunnels - Resum tema ip tunnels PDF

Preview

Summary

Configuring IPIP tunnelsR2$ ip tunnel add tunnel0 mode ipip local 198.51.100 remote 192.0.2 ttl 0 nopmtudisc dev ethAssign @IP to an interfaceR2$ ifconfig tunnel0 2.2.Update tablaR2$route add -net 192.168.0/24 dev tunnelR1$ ip tunnel add tunnel0 mode ipip local 192.0.2 remote 198.51.100 ttl 0 nopmtu...

Description

Configuring IPIP tunnels R2$ ip tunnel add tunnel0 mode ipip local 198.51.100.2 remote 192.0.2.2 ttl 0 nopmtudisc dev eth2 Assign @IP to an interface R2$ ifconfig tunnel0 2.2.2.2 Update tabla R2$route add -net 192.168.0.0/24 dev tunnel0 R1$ ip tunnel add tunnel0 mode ipip local 192.0.2.2 remote 198.51.100.2 ttl 0 nopmtudisc dev eth2 R1$ ifconfig tunnel0 1.1.1.1 R1$route add -net 172.16.1.0/24 dev tunnel0

5.Testing the tunnels: protocol and TTL fields 5.1. Open FOUR wireshark network analyzers in the PHYSICAL HOST and capture traffic in each of these networks: SimNet0, SimNet1, SimNet2 and SimNet3. To properly see fragmented messages, DISABLE the following option in all these wiresharks: Edit-Preferences-Protocols-IPv4-Reassenble fragmented IPv4 datagrams. 5.2. Send the following ping from host2 to host3: (a) What is the meaning of the -c option? (consult the man page of ping if necessary)

-c indicates number of pings that we whant to ralize, in this case we use -c 1 that means do 1 ping (b) Is the ping working? How many packets can you see?

Yes, we see 1 ping, with the paquets ICMP request and ICMP reply

WIRESHARK: Simnet0

Simnet1

Simnet2

Simnet3

5.3. Assuming that the ping is working, it is necessary to emphasize certain aspects related to tunneling issues: (a) Verify that the IP packet in SimNet1 and SimNet2 is encapsulated using IPIP. How many IP headers can you see in these packets? Which is the value of the “Protocol” field in the Outer Header? Vemos que hay 2 ip headers ya que en el túnel se encapusla el paquete procedente de simnet0 o simnet3 en uno nuevo (el paquete encapsulado va en el campo de datos del nuevo paquete). El valor del Protocolo de la cabecera outer es IPV4 (solo tienen outer los paquetes que viajan por el tunnel ya que son los encapsulados). (b) Determine the difference in size from the original IP packet (in SimNet0) and the encapsulted one (in SimNet1). La diferencia es de 20Bytes, dado que el paquete original se encapsula al hacer un túnel ip se encapsula en otro paquete (en el campo de datos) y este nuevo paquete tiene un nuevo header de ip (que corresponde al incremento de 20Bytes) que hay entre los paquetes que salen de Simnet0 y vemos en Simnet1. (c) Identify the value of the “TTL” field in the original IP packet and how this value evolve during the transmission, both in the inner and in the outer headers. Remind that we used the option ttl inherit during the creation of the tunnels. TTL Outer header Inner header

Simnet0

Simnet1 64

Simnet2 63 63

Simnet3 62 63

62

El TTL se decrementa cada vez que el paquete consulta la tabla de rutas. En el momento que se encapsula por el tunnel hereda el TTL que tiene el paquete encapsulado, a partir de aquí mientras este en el tumnel la ttl de la cabecera inner no se decrementa, se decrementa la de la outer. 5.4. To evaluate the behavior of the tunnel when the TTL expires, we will send IP packets from host2 (192.168.0.2) to host3 (172.16.1.3) increasing one by one the TTL. First, clear and start again the capture in the four wiresharks to perfectly monitor step by step the transmission of this packets in all the involved networks (SimNet0, SimNet1, SimNet2 and SimNet3).

Next, send again one ICMP echo-request messages using the ping program and TTL=1. host2$ ping -c 1 -t 1 172.16.1.3 (a) Can you see packets in all the networks? Did the packet reach the destination host? In which host the packet was lost? No vemos que el paquete haya viajado por todas las redes, y por lo tanto tampoco vemos que haya alcanzado su destino. El paquete agota su ttl al consultar el primer router por lo tanto muere al router R1 que se encunetra en el simnet0 (b) Can you see any ICMP error message? Which one? In which network? Wireshark (simnet0)

Podemos ver el mensaje de error, que dice que se ha excedido el TTL, aparece en simnet0, es enviado por R1

(c) Which are the origin and destination IP addresses of this error message?

Es enviado desde R1 con destino el emisor del paquete, en este caso host2. Now clear all the wiresharks and send again another ping, but with TTL=2. host2$ ping -c 1 -t 2 172.16.1.3 (a) Did the packet reach the destination host? In which machine the packet was lost? Vemos que el paquete no ha alcanzado su destino. Se ha perdido en simnet1, se pierde ya que alcanza TTL = 0 en el router RC. (b) Can you see any ICMP error message? Which one? In which network? Podemos ver el mensaje de error, que dice que se ha excedido el TTL, aparece en simnet0, es enviado por RC, por lo tanto se pierde en Internet. (c) Which is the origin and destination IP addresses of this error message? El origen es la IP del router RC y el destino es la IP (que esta en la interficie eht2) del router R1 (d) Can you see any ICMP relaying? No lo vemos. El ICMP relaying es el mensaje ICMP que se envia y que pasa de dominio publico a privado. CON TTL NO HACE NUNCA EL ICMP relay Send again the same ping with TTL=2. (e) Is there any soft state? Soft state: guarda información No hay soft state, dan exactamente los mismos errores, no hay ninguna aportación de modificación debido a la memoria de antecedentes pasados. (f) Is this behavior compliant with RFC 2003 (see section 4.4)? RFC 2003 4.4. Time Exceeded (Type 11) ICMP Time Exceeded messages report (presumed) routing loops within the tunnel itself. Reception of Time Exceeded messages by the encapsulator MUST be reported to the sender of the original unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host Unreachable is preferable to Network Unreachable; since the datagram was handled by the encapsulator, and the encapsulator is often considered to be on the same network as the destination address in the original unencapsulated datagram, then the datagram is considered to have reached the correct network, but not the correct destination node within that network. Now use TTL=3: (a) Did the packet reach the destination host? Sí (b) Can you see any ICMP reply message? Si

0.6 Testing the tunnels: nopmtudisc Remember:

-

maximum length of an IP datagram is 64KBytes Maximum Transmission Unit (MTU) is defined as the size of the largest IP packet (including the IP header) that the link layer can transmit MTU depends on the type of transmission link, for example, ethernet links have a MTU of 1500 bytes IP routers can fragment IP datagrams, and the receiving station is responsible for reassembling the fragments. The main fields of the IP header involved in fragmentation are “identification”, “total length”, and “fragment offset”. There are also the "more fragments" (MF) and "don’t fragment" (DF) flags. Fragmentation can cause overhead "Path MTU" is the smallest MTU of all the hops of the path between source and destination path MTU is the largest packet size that can traverse this path without suffering fragmentation Basically, the DF (don’t fragment) flag is set in the IP headers of outgoing packets Any router in the path whose MTU is smaller than the packet will drop it, sending back an ICMP Destination Unreachable ***Datagram Too Big message (also known as Fragmentation Needed) This error message contains the value of this more restrictive MTU, and it is used by the source host to reduce its assumed path MTU.***

6.1 Limiting the MTU 6.1.1 Use ifconfig to see which is the value of the MTU in the tunnel interfaces both in R1 and R2. (a) Which is this value? MTU in the tunnel interfaces is 1480 Bytes in both cases R1 and R2

(b) Is there any relationship between the MTU assigned to the tunnel, and the MTU assigned to the physical interface? Si, que la MTU de la physical interface te 1500 Bytes mentre que la del tunnel té 1480 degut a que s’ha d’afegir una capçalera ip més degut al encapsulat. 6.1.2. Delete the previously configured tunnel in R2. Instead of doing it manually, you can use this script to do so. Go to the console of your HOST machine, and execute: physicalHost$ simctl iptunnel exec deltun (this will delete the tunnel in both sides R1 and R2)

6.1.3. Change the MTU of SimNet2 to the value 996 bytes. So, get the consoles of R2 andRCand use the ifconfig command to do so. For instance, in R2 execute:

CAL APLICAR ALS DOS ROUTERS R2$ ifconfig eth2 mtu 996 RC$ ifconfig eth2 mtu 996

6.1.4. Reestablish again the tunnel using the following script: physicalHost$simctl iptunnel exec addtun_nopmtu (a) Which is now the MTU in both sides of the tunnel?

Vemos que en un extremo del tunnel (R1) hay la MTU 1480 Bytes, mientras que en el otro extremo R2 hay la MTU que hemos asignado de 976 Bytes. En la interfaz eth2 de R2 se situa en 996Bytes y la de R1 en 1500 Bytes. (b) Why this change in the MTU value? Porque temenos que restar los 20Bytes de cabecera que le añade el tunnel al encapsular el paquete con una cabecera ip adicional

0.6.2 Fragmentation fields and options 1. Put all wiresharks listening traffic in all SimNet interfaces. 2. Send the following ping from host2 to host3: host2$ ping -c1 -s 500 -M want 172.16.1.3 Consult the man page of ping to know what is the meaning of the -s and -M options. -s “size” of data The -M want option is intended to “do PMTU discovery, fragment locally when packet size is large” That is, the DF flag is set byd efault, but when there is the necessity of fragmentation, the origin can do it. (a) How many ICMP packets can you see? What kind of packets? Hay dos paquetes icmp, el request y el reply en cualquier Simnet que se mire. (b) Which is the size of these packets? Describe the headers of these packets. Ineers 542Bytes

Outers 562Bytes (c) Have these packets been fragmented? Why? No fragmentan ya que están por debajo de la MTU mínima del sistema, en este caso 976Bytes. Si analizamos los icmp requests vemos que tienen el flag don’t fragment a (1). (d) Which is the value of the “don’t fragment” (DF) flag in the ICMP packets in SimNet0? El valor del don’t fragment flag (DF) en simnet0 vale 1, es decir no fragmenta (e) And in SimNet1, which is the value of DF in the Outer and Inner headers? El valor del don’t fragment flag también es 1 en simnet1, es decir no fragmenta. 6.3. Ahora vamos a poner -M dont, que significa don’t fragment flag a 0. (Es decir si que fragmenta) Ejecutamos: host2$ ping -c1 -s 500 -M dont 172.16.1.3

(a) What is the difference compared to the previous test? Vemos que en este caso obtenemos los mismos paquetes icmp de request y reply, no se fragmentan, pero si vamos a los flags, tienen el Don’t Fragment (DF) desactivado es decir 0. 6.4. Ahora vamos a poner -M dont, que significa don’t fragment flag a 0. (Es decir si que fragmenta) Ejecutamos: host2$ ping -c1 -s 500 -M do 172.16.1.3 The do option “prohibit fragmentation, even local one”. (a) Can you see any difference in wireshark compared to the first case? Is there any difference at all? No hay diferencia, es exactamente lo mismo, 1 icmp-request y reply, con los (DF=1) Now that you understand how encapsulation is performed, calculate which is the size necessary to make the encapsulated packet have the maximum sized alowed by SimNet2. Send a ping of this size and verify that there is no fragmentation. MTUmin-48Bytes(de headers), en SimNet2 el MTUmin hemos establecido al principio que era de 996Bytes, si le restamos los 48Bytes de headers. Esto nos da un size máximo de data de 996-20-20 = 952 Bytes

The -M want option the following script automatically deletes this cache in all machines involved: phyhost:$ simctl iptunnel exec flushcache Execute the following command in host2: host2$ ping -c 1 -s 1000 -M want 172.16.1.3 (a) Is the ping working? El ping se transmite, pero no se recibe, así que no funciona. (b) How many ICMP packets can you see in SimNet0? What kind of packets? Is set the DF flag in the IP header of the ICMP echo-request? Solo se ve un paquete en simnet0, que es el icmp request, tiene el DF=1, y no fragmenta ya que en el R1 el tamaño de mtu son 1480 Bytes, y en este caso el paquete es de 1042 Bytes. (c) And in SimNet1, what packets can you see? Is the DF flag set in the IP headers (inner and outer)?

Vemos que aparece el request y un mensaje de error que nos dice que el destino no se puede alcanar porque necesita de fragmetnacion. El flag DF=1 tanto en la inner como en la outer, el mensaje de error tiene el DF=0. As you can see, there is an error produced by the MTU by means of a message ICMP fragmentation needed. This error apears due to the DF flag is Set in the Outer IP header of the ICMP echo-request message. (d) What device is the origin of the ICMP fragmentation-needed message? El router RC And the destination? El router R1 Which is the maximum MTU notified in this message? El MTU del siguiente hop es 996Bytes es decir la MTU del RC

(e) In your opinion, what entity should be the proper destination of this message? La entidad a la que deberia ir destinado el mensaje de error es el host2, pero como tiene dirección privada, y el paquete viaja en dirección publica por internet entonces el router RC tiene que enviarlo a R1 como destinatario y R1 ya se lo llegaría a enviar a host2. (ya que RC es conocedor de la existencia de R1, pero no de host2) (f) According to RFC2003 (see Section 4.1), is R1 acting as relay of the message and sending it to host2? Host Unreachable (Code 1) : the encapsulator SHOULD relay Host Unreachable messages to the sender of the original unencapsulated datagram, if possible. Como vemos, en simnet0 no aparece el mensaje de error, por lo tanto R1 no esta actuando como relay. Now, delete kernel routing cache, phyhost:$ simctl iptunnel exec flushcache and execute this command: host2$ ping -c 2 -s 1000 -M want -i1 172.16.1.3 With this command we are sending two ICMP echo-request messages with 1000 Bytes of data and separated by an interval (-i option) of 1 second.

(a) Is the ping working? How many ICMP messages can you see in SimNet0? Is the DF flag set in the IP header of these messages? Simnet0

Vemos 3 mensajes icmp, 2 icmp-request y 1 de error (fragmentation needed), El dont fragment es DF=1 en el icmp request, y DF=0 en el icmp error (b) In SimNet1, how many ICMP echo-requests can you see? What about the DF flag? Simnet1

Vemos dos mensajes icmp, el request y uno de error (fragmentation needed), El dont fragment es DF=1 en el icmp request, y DF=0 en el icmp error (c) Can you see an ICMP fragmentation-needed message in SimNet0? Which is the origin and destination of this message? Which is the maximum MTU notified in this message? Si que vemos un mensaje de error de fragmentation needed en simnet0, el origen del mensaje es el R1 (salida que da a la red privada 192.168.0.0/24), y el destino es el host2(192.168.0.2).

Si miramos los paquetes de error en simnet0 y simnet1 tenemos las siguientes mtu: Simnet0: 976Bytes, ya que le resta los 20Bytes adicionales que le mete la cabecera ip que añade el tunnel. Simnet1: 996Bytes (que es el mtu que le hemos puesto al RC cuando lo hemos configurado) (d) Do you think that R1 maintains a soft state of the MTU of the tunel? R1 tiene soft state ya que en el segundo icmp-request ya no traviesa el router. El soft state se puede ver ejecutando el comando: R1:$ ip route show cache

Now, delete kernel routing cache, phyhost:$ simctl iptunnel exec flushcache and execute this command: host2$ ping -c 3 -s 1000 -M want -i 1 172.16.1.3

(a) Is the ping working? How do you know that? Vemos que el ping funciona, ya que recibimos un icmp-reply, pero tendríamos que recibir tres icmp-reply. (b) In SimNet0, have a look at the DF flag in all the ICMP echo-request messages. What can you deduce? Is there any difference in the third ICMP Echo request message?

Los dos primeros mensajes icmp-request tienen el DF=1. Si miramos el 3r icmp-request tiene los siguientes flags activados:

Vemos que cuando se ha recibido el mensaje de error de fragmentation needed el siguiente paquete icmp se adapta el size a la mtu que son 976 Bytes, el 3r paquete icmp-request tiene 972 Bytes de total length que esta por debajo de los 976Bytes a partir de los cuales fragmentaria.

(c) In SimNet0, who is performing the fragmentation of the third ICMP echo-request? Which are the sizes of the packets that compose this third ICMP echo-request? Take notes of the existing headers. La fragmentación la hace el host2. Los sises son de 986 Bytes, el total length es de 972Bytes, de los cuales 936 Bytes son de data. (d) In SimNet1, how many fragmented packets can you see that correspond to this third ICMP echo-request? What about the DF flag in the Inner and Outer IP headers?

Dos, el que se envia primero, el segundo icmp request no aparece ya que el router R1 tiene soft state y no lo deja pasar al exceder el tamaño de la mtu, el tercero icmp request envaido por host2 (2do request de la imagen de wireshark de simnet1) lo vemos ya que R1 lo deja pasar debido a que no excede el tamaño de MTU. Las cabeceras outer y inner del primer icmp-request, tienen los flags DF=1 La cabecera outer del segundo icmp-request tiene el DF=0 y la cabecera inner de este segundo paquete tiene DF=1 (e) Describe in detail the sizes and headers of these packets. Is fragmentation performed in the same way than SimNet0? Why the difference? Notice that the Fragment Offset field in the IP header is meassured in units of 8 bytes. Primer icmp-request: La diferencia entre el paquete capturado en simnet0 y simnet1 es que el de simnet1 esta encapsulado con una nueva dirección ip debido al tunnel y tiene 1048 Bytes. Outer: 1048 Bytes Inner: 1028 Bytes Segundo icmp-request: El icmp-request que pasa por simnet0 tiene 972 Bytes mientras que el tamaño del icmp-request de la cabecera inner es de 996 Bytes, el de la outer es de 1028 Bytes Outer:1028 Inner:996 (f) In SimNet3, how many ICMP echo-requests can you see? Describe sizes and headers. Solo hay 1 icmp-request. El header size es de 1028 Bytes, tienen los flags DF=0, la cabecera outer tiene (g) In SimNet3, how many ICMP echo-reply messages can you see? Describe sizes and headers. Solo hay un icmp-reply. El header size es de 1028 Bytes, tienen los flags DF=0 (h) In SimNet2, how many fragmented packets can can you see that correspond to this third ICMP echo-reply? Describe in detail sizes of these packets and headers. Is fragmentation performed in the same way than for the ICMP Request message? Describe in detail sizes of these packets and headers. Solo hay un paquete icmp-reply, el paquet size es de 992 Bytes en la outer y 972 Bytes en la ineer. Now, delete kernel routing cache, phyhost:$ simctl iptunnel exec flushcache and execute this command: host2$ ping -c 2 -s 1460 -M want -i 1 172.16.1.3 (a) Is there any error message? Who is the sender of this error? Si, hay un mensaje de error de fragmentation needed, lo envia el host2 hacia el router R1 (interfaz que da hacia la red privada). (b) Which is the value of MTU that is reporting this error message? Is this value the real path MTU value? Why there are no more errors during the transmission? Have a look to the DF flag. El maximo MTU es 1480, no es el valor real del path de mtu ya que en el router RC va a tener que fragmentar debido a que tiene el max size de 996Bytes de mtu En el primer icmp-request se esta enviando 1460 de data, al añadir los headers supera el MTU ya que el length del paquete es 1488Bytes, tiene el flag DF=1. El segundo icmp-request tiene el flag DF=0 y el more fragments a 1, el size del paquete no excede el limite que marca la mtu que son 1480 Bytes, el icmp-rquest que se manda esta segunda vez tiene 1476 Bytes

0.8 Testing tunnels: TCP and MSS Saber el tamany de mtu: “Options“ del TCP header en los segmentos SYN

0.8.1 Netcat and TCP 2. Start a netcat server in host3 listening in port 12345: host3$ nc -l -p 12345 3. Start the netcat client in host2: host2$ nc 172.16.1.3 12345 (a) Can you see the classical 3-way handshake of TCP? Si, vemos SYN, SYN/ACK, ACK que es el protocolo de handshake a 3 que usa TCP al establecer una conexión. (b) Which is the v...