redes privadas virtuales capítulo 03

REDES PRIVADAS VIRTUALES · Capítulo 03

blog.carreralinux.com.ar 1



Capítulo 03 - TÚNEL, ENCAPSULAMIENTO, PPP E IPIP

ÍNDICE

Tunneling 3PPP POINT to POINT PROTOCOL 5PPPoE – PPP OVER ETHERNET 10IPIP 14

Suscribite a nuestro Twitter:twitter.com/CarreraLinuxAr

Suscribite a nuestro Facebook:www.facebook.com/carreralinuxar

Suscribite a nuestro Blog:blog.carreralinux.com.ar



Capítulo 03 - TÚNEL, ENCAPSULAMIENTO, PPP E IPIP

Tunneling

Como veremos más adelante; pero podemos ir adelantando, VPN son túneles segu-

ros. En una primera etapa durante este módulo acabamos de ver los conceptos de

seguridad, ahora veremos ejemplos de tunneling.

El tunneling es una forma de crear redes

virtuales que atraviesan una o varias redes

físicas.

Cabe aclarar que no estamos hablando de VPN, solamente de redes virtuales ya que

la privacidad de una VPN no se logra con tunneling.

Por lo que es muy importante tener en cuenta

que el tunneling nos va a servir para simu-

lar que nuestra máquina se encuentra dentro

de nuestra red local, aun estando físicamen-

te distante.

Básicamente lo que hace es encapsular un protocolo de red sobre otro protocolo de

red y de esta manera se crea el túnel dentro de una red de computadoras. Así po-

dremos transmitir un PDU (Packet data unit) de un extremo a otro sin que haya una

interpretación intermedia del paquete encapsulado.

Así el paquete va de origen a destino y los nodos intermedios, en algunos casos, no

pueden ver el contenido de dichos paquetes. El túnel queda definido por los pun-

tos extremos y el protocolo de comunicación empleado.




Supongamos que queremos comunicar dos redes Novell Netware diferentes separa-

das, a través de Internet. Las redes Novell usan como protocolo de red IPx, mientras

que Internet usa IP. En el gráfico superior podemos ver una de las formas que propo-

ne la rfc1234. Aunque hoy por hoy nadie use Novell, nos servirá como ejemplo.

Cuando un paquete va de la Novell LAN 1 hasta la Novell LAN 2, el primer gateway

IP encapsula el paquete IPx como payload de una trama UDP, y la envía sobre IP por

Internet. A través de internet, los diferentes routers solo verán el encabezado IP. O

sea, jamás llegarán a ver el contenido del protocolo IPx, por lo que cuando llega al

segundo gateway IP, éste extrae el paquete IPx del paquete UDP, y lo inyecta en la

red Novell2. Esto es posible ya que el Gateway IP sabe cómo enrutar dicho paquete

en la red Novell, o sea, en su tabla de enrutamiento sabe cómo llegar a la red Novell,

o conoce el gateway que llevará a la red Novell. Esto es un túnel IPx sobre una red IP.

Hay que notar que el paquete IPx no se rutea en Internet, es

solo una carga, un “dato opaco”, es inyectado en Internet por

un extremo, y solo es utilizado por el otro extremo, no por

ningún host intermedio.



NovellLAN 1

IPx

IPGW

IPGW

IPxIP | UDP | IPx

NovellLAN 2INTERNET



Estos túneles, como vemos, no nos brindan seguridad, es decir:

· No tiene integridad porque no se si alguien modifico el paquete IPx en el medio.

· No tiene autenticidad, ya que no se si quien me envía es realmente quien dice ser

que es.

· No tiene privacidad, ya que cualquier persona entre origen y destino puede ver el

contenido del paquete.

Esto se logra con protocolos de seguridad, y lo veremos en VPN por lo que hasta

ahora es solo tunneling.

En el caso que acabamos de ver, hemos encapsulado un protocolo de capa 3 (IPx) en

un protocolo de capa 4 (UDP).

Vamos a analizar algunos mecanismos de túneles bien conocidos y utilizados en las

redes actuales, como son los protocolos PPP, PPPoE, IPIP y GRE.

PPP POINT to POINT PROTOCOL

Es un protocolo usado para establecer una

conexión directa entre dos nodos de red a

nivel de enlace de datos; es decir, en capa

2 del modelo OSI/ISO.

Era usado sobre varios tipos de redes físicas: seriales, líneas telefónicas, líneas ce-

lulares. Es un protocolo antiguo; pero nos dará el puntapié inicial para comprender

como funciona el tunneling.




La mayoría de los ISPs lo utilizaban para brindar acceso a Internet por dial-up, co-

nectando un modem telefónico a un centro de acceso remoto. Aparte de brindar

conexión a internet, también era muy para conectar a los llamados road-warriors, o

empleados de empresas que se conectan desde cualquier punto de Internet a la red

local de su empresa para hacer uso de los servicios internos.

Se usan además dos formas encapsuladas de PPP (PPPoE y PPPoA) para conectar

servicio de Internet por DSL.




Como PPP trabaja en capa de enlace, lo que encapsula en su payload o campo de

carga útil es una datagrama de capa de red, IP o IPx, por ejemplo.

PPP es un protocolo de enlace punto a punto

que brinda transporte de datos entre hosts, y

además provee servicios de autenticación de

usuarios, generalmente mediante user+pass,

y asignación de dirección IP dinámicamente.

Es esta una de las razones principales por las que los ISP’s que proveen servicios

por dial-up lo utilizan para autenticar a sus usuarios, y encapsular todo el tráfico de

Internet desde el usuario final hasta el concentrador de accesos remotos en el pro-

veedor. O sea, cuando nos conectábamos con nuestro módem telefónico, si quería-

mos acceder a google, la información del Stack TCP/IP viaja como payload dentro de

PPP. Entonces, lo que era el IP Gateway en el ejemplo anterior, en este caso son los

modems de nuestro ISP.

Los campos PPP son:

· Flag: indica principio o fin.

· Address: dirección de broadcast, siempre tiene FF.

· Protocol: si es NCP. LCP o el protocolo que está encapsulando. Ahora lo vamos a

ver más adelante.

· Information: que es el contenido del datagrama.

· FCS: chequea el checksum para determinar si hay algún error.





PPP consta de las siguientes fases:

Establecimiento de conexión

Durante esta fase, una computadora contacta con la otra y negocian los pa-

rámetros relativos al enlace usando el protocolo LCP. Este protocolo es una

parte fundamental de PPP y por ello está definido en el mismo RFC. Usando

LCP se negocia el método de autenticación que se va a utilizar, el tamaño

de los datagramas, números mágicos para usar durante la autenticación.

Autenticación

No es obligatorio. Existen dos protocolos de autenticación. El más básico

e inseguro es PAP, aunque no se recomienda dado que manda el nombre

de usuario y la contraseña en claro. Un método más avanzado y preferido

por muchos ISPs es CHAP, en el cual la contraseña se manda cifrada.

Configuración de red

En esta fase se negocian parámetros dependientes del protocolo de red

que se esté usando. PPP puede llevar muchos protocolos de red al mis-

mo tiempo y es necesario configurar individualmente cada uno de estos

protocolos. Para configurar un protocolo de red se usa el protocolo NCP

correspondiente. Por ejemplo, si la red es IP, se usa el protocolo IPCP para

asignar la dirección IP del cliente y sus servidores DNS.

Transmisión

Durante esta fase se manda y recibe la información de red. LCP se encarga

de comprobar que la línea está activa durante periodos de inactividad. Ojo

que PPP no proporciona cifrado de datos.

Terminación

La conexión puede ser finalizada en cualquier momento y por cualquier

motivo.

3°

4°

5°

1°

2°



PPP tiene todas las propiedades de un protocolo de nivel de enlace:

· Garantía de recepción

· Recepción ordenada

Volviendo a los túneles, yo podría tener toda una comunicación TCP/IP; es decir,

segmentos TCP encapsulados dentro de datagramas IP, todo encapsulado dentro de

paquetes PPP.

Para poder enviar esto por Internet, como se hace en las líneas DSL actuales, a su vez

se encapsula todo el paquete PPP dentro de UDP como transporte, e IP para poder

rutearlo a destino. Dicho de otra manera tendremos IP encapsulado en PPP y este

encapsulado en IP.

Los hosts tienen dos interfaces; una real, con un determinado direccionamiento,

y otra virtual, que es la interfaz del túnel, con otro direccionamiento. Dicho de otra

manera, los extremos del túnel tendrán su propia interfaz que el sistema operativo los

verá como una interfaz de red con su propia dirección de red. Es por ese motivo que

los extremos del túnel veremos que tendrán su propia dirección IP.

Los hosts se comunican “virtualmente” con paquetes IP que van

desde origen a destino; pero estos paquetes no viajan direc-

tamente desde la interfaz de uno a la de otro, sino que son

encapsulados en un túnel para ser enviados por Internet.


EncabezadoIP

EncabezadoGRE

EncabezadoPPP

Cifrado

Marco PPP

Carga PPP(datagrama de IP)



PPPoE – PPP OVER ETHERNET

PPPoE es un ejemplo de túnel en el que se

encapsula un protocolo de capa de red sobre

otro; pero en este caso encapsula PPP dentro

de un datagrama Ethernet.

Básicamente nos va a permitir implementar una capa IP sobre una conexión entre dos

puertos Ethernet, pero con las características de software del protocolo PPP, por lo

que se pueden transferir paquetes IP, basados en las características del protocolo PPP.

Esto nos dejará utilizar software tradicional basado en PPP

para manejar una conexión con paquetes orientados a redes

locales como Ethernet para proveer una conexión clásica con

autenticación para cuentas de acceso a Internet.




Además, las direcciones IP en el otro lado de la conexión sólo se asignan cuando la

conexión PPPoE es abierta, por lo que admite la reutilización de direcciones IP (direc-

cionamiento dinámico). Veamos un ejemplo práctico.

Un módem DSL es un bridge Ethernet que conecta un sitio remoto con una oficina

central utilizando un DSLAMs.

DSLAM son las siglas de Digital Subscriber

Line Access Multiplexer (Multiplexor de lí-

nea de acceso de abonado digital).

El DSLAM es un multiplexor localizado en la central telefónica que proporciona a los

abonados acceso a los servicios DSL sobre cable de par trenzado de cobre. El dispo-

sitivo separa la voz y los datos de las líneas de abonado.

Una vez que cliente y servidor negocian algunos parámetros de la conexión estable-

cen el túnel PPPoE; es decir, se comienzan a transmitir datagramas PPP encapsula-

dos directamente sobre tramas Ethernet.

ISP Internet

DSLAMProvider Premises

Voice PhoneSystem

Home 1

Home 2

IntegratedRouter

IntegratedRouter

DSLModem

DSLModem




¿Cuáles son esos parámetros? Bien, aunque tradicionalmente PPP es un protocolo

capa a capa, PPPoE tiene una relación cliente-servidor ya que muchos hosts pueden

conectarse al mismo servicio para proveer una conexión física simple. Para establecer

una conexión PPPoE, se debe obtener la dirección Ethernet del servidor remoto

PPPoE. Además, también se debe negociar un identificador de sesión único. El método

para obtener esta información se conoce como la fase de descubrimiento de PPPoE.

La fase de descubrimiento de PPPoE se compone de cuatro pasos: confirmación

de iniciación, oferta, request y session:

El cliente envía paquete de PPPoE Active Discovery iniciación (PADI):

El cliente PPPoE envía un paquete PADI a la dirección de broadcast.

El DSLAM retorna un PPPoE Active Discovery offer (PADO) de PPPoE:

El servidor PPPoE o concentrador de acceso, debe responder a la PADI

con un PADO si el concentrador de acceso es capaz de atender. El paque-

te PADO se responde a la dirección de unicast del cliente de PPPoE.

El cliente envía el paquete PPPoE Active Discovery request (PADR) de

PPPoE:

Cuando se recibe un paquete PADR, el cliente PPPoE responde con un

paquete PADR. Este paquete se envía a la dirección de unicast del DSLAM.

El cliente puede recibir varios paquetes PADO, pero el cliente responde a la

primera PADO válido que recibió el cliente. Si el paquete PADI inicial.

El paquete de PPPoE Active Discovery session confirmation (PADS):

Cuando se recibe el PADR, el concentrador de acceso genera una iden-

tificación de sesión único (ID) para la sesión de protocolo punto a punto

(PPP) y devuelve este identificador para el cliente de PPPoE. Este paquete

se envía a la dirección de unicast del cliente.


3°

4°

1°

2°



Cuando haya finalizado este proceso, el cliente tiene la dirección del concentrador

de acceso y una sesión que se ha establecido junto con el ID. En este momento, se

inicia una sesión PPP normal. Negociándose las fases de comunicación de PPP, todo

viajando sobre Ethernet.

Fase 1: LCP (Link control protocol)

Se negocian los parámetros sobre la transmisión de datos en el medio físico, como

ser la compresión de headers, el tipo de CRC (checksum de control), o los protocolos

de autenticación (PAP, CHAP, etc.).

Fase 2: Autenticación

Aquí es cuando se utiliza el protocolo de autenticación seleccionado durante la fase

1: PAP (Password Authentication Protocol), CHAP (Challenge-Handshake Authenti-

cation Protocol).

Fase 3: NCP (Network Control Protocol)

Negocia parámetros de red, como la IP, DNS, CCP (Compression control protocol),

ECP (Encryption control protocol), etc., pues estamos interesados en enviar paque-

tes IP encima de paquetes PPP, ya que tenemos que lograr comunicar al cliente con

servidores en Internet, servidores accesibles por IP, y la única manera de accederlos

mediante una conexión PPPoE con nuestro proveedor de servicios de Internet, es

enviar los datagramas IP destinados a los equipos de Internet, encapsulados dentro

de tramas PPPoE.





IPIP

En este tipo de túneles, los datagramas IP

se encapsulan como payload de otro datagrama

IP.

Para encapsular un paquete IP adentro de otro, se agrega un encabezado (outer

header) con la IP de origen, la IP de entrada al túnel junto con el Destination Point y

el punto de salida del túnel. Lo que hace esto, es que el paquete interno no sea modi-

ficado (excepto por el TTL). El TOS y fragmentacion (todos campos del protocolo IP)

son copiados al Outer header.

Si el paquete es mayor que el MTU permitido, el paquete es

fragmentado internamente y el outer header es incluido en

cada fragmento. Luego, el decapsulador (que es lo que se hace

en destino) reensambla el paquete.

IP Header

Outer IP Header

IP Payload IP Payload

IP Header





Para entender un poco más a detalle vamos a ver algunos campos del encabezado

IP del outer header:

· Type of Service (TOS): 8 bits

Como dijimos anteriormente, lo copia del interno.

· Total Length: 16 bits

Es el tamaño de todo (including Outer IP header, Inner IP header, IP Payload)

· Identification: 16 bits

Es para identificar los fragmentos del datagrama.

· Flags: 3 bits: R, DF, MF

· DF: 1 bit: Dice si el datagrama puede ser fragmentado o no. Si esta en 1 en el

inner header, entonces el outer header también tiene que estar en 1 que indica

que el datagrama no puede ser defragmentado. Si llegara a estar en 0 en el in-

ner-header, entonces el outerheader puede estar en 0 o 1.

· MF 1 bit: Indica que el datagrama fue fragmentado. Esto no se copia del inner

header. Es lógico, porque el inner header no tiene la marca de que fue defrag-

mentado.

· Time To Live (TTL): 8 bits

Trackea el lifetime del paquete. Es decremenado previo a la encapsulación y no es

cambiado en el desencapsulamiento.

· Protocol: 8 bits

Es el field del próximo protocolo y es seteado a “4”, ya que el próximo va a ser IP.

Supongamos que tenemos dos redes geográficamente separadas, con sus propios

direccionamientos, y quisiéramos poder comunicarlas a través de un túnel.




La idea es poder comunicar un host llamado cla-snt con otro llamado cla-snt2 a

través de un tunel IP-IP. Supongamos también que ambos host son gateways y que

cada uno también apunta a una subred privada.

· cla-snt es la sede de Quito con la subred 10.10.0.0/24

· cla-sn2 es la sede de Montevideo con la subred 10.10.1.0/24

· cla-snt, IP del extremo del túnel: 172.16.0.1/30

· cla-snt2. IP del otro extremo del túnel: 172.16.0.2/30

SOLO PARA ESTE EJEMPLO, las IPs públicas de los respectivos

hosts son 1.2.3.4 para cla-snt y 5.6.7.8 para cla-snt2.

Ponemos esto de manera genérica porque variará dependiendo de las IPs públicas

de los gateways de ambos sitios.

Cuando el host cla-snt envía un datagrama al host cla-snt2, tiene la IP de origen y

destino de las interfaces de ambos hosts. O sea, supongamos que un host de IP de

origen 10.10.0.10 le envía un mensaje a un host de IP destino 10.10.1.15. En pocas pa-

labras, un host de la LAN de Quito le envía un mensaje a un host de la LAN de Ecuador.

Dentro de cla-snt lo encapsula dentro de otro datagrama IP, con dirección origen

172.16.2.106 (IP de la interfaz del túnel) y destino 172.16.0.1 (el otro extremo del tú-

nel, cuya interfaz se encuentra en la interfaz del túnel de cla-snt2), y entonces lo envía

a Internet; pero a través del túnel.

Cuando este datagrama llega a la interfaz del túnel de cla-snt2, extrae el datagrama

original, y el interior, lo enruta dentro de su red. Al observar de nuevo la dirección IP de

destino ve que es 10.10.1.15 y vuelve a ver con su tabla de ruteo para de esta manera

saber que lo tiene que enviar a la interfaz IPIP.




Ejemplo práctico:

Lo primero que debemos hacer es revisar que ambos hosts se vean, por lo

que en este caso haremos un ping de cla-snt a cla-snt2. Todos los comandos

primos los ejecutaremos dentro de cla-snt:

cla-snt# ping cla-snt2

Luego creamos la interfaz de túnel IPIP entre el host local 172.16.2.106 y el

remoto 172.16.0.1

cla-snt# ip tunnel add ip0 mode ipip remote 1.2.3.4 local 5.6.7.8

cla-snt# ifconfig ip0

Le asignamos una dirección IP a la interfaz del túnel IPIP, y la levantamos:

cla-snt# ip addr add 172.16.0.1/24 dev ip0 brd +

cla-snt# ip li set dev ip0 up

Enrutamos todo el tráfico que vaya hacia la red destino 10.10.1.0/24 por la

interfaz del túnel:

cla-snt# ip ro add 10.10.1.0/24 dev ip0

Luego, dentro de cla-snt2 haremos el camino inverso, por un lado para que

los paquetes seapan como volver, y para setear el full duplex de los túne-

les. Creamos la interfaz de túnel IPIP entre el host local 172.16.0.1 y el remoto

172.16.2.106:

cla-snt2# ip tunnel add ip0 mode ipip remote 5.6.7.8 local 1.2.3.4

Le asignamos una dirección IP a la interfaz del túnel IPIP, y la levantamos:

cla-snt2# ip addr add 172.16.0.2/24 dev ip0 brd +

cla-snt2# ip li set dev ip0 up

cla-snt2# ifconfig ip0


05

06

04

01

02

03



Enrutamos todo el tráfico que vaya hacia la red destino 10.10.0.0 por la interfaz

del túnel. Suponiendo que la 10.10.0.1 sea una IP existente:

cla-snt2# ip ro add 10.10.0.0/24 dev ip0

cla-snt2# ping 10.10.0.1

Si capturamos, en cualquiera de los dos hosts el tráfico de red, podemos ver

que en la interfaz ip0 el tráfico es normal, como si los dos hosts se encontraran

uno al lado del otro:

cla-snt2# traceroute -n 10.10.0.1

cla-snt2# traceroute to 10.10.0.1 (10.10.0.1), 30 hops max, 60

byte packets

1 10.10.0.1 8.001 ms 16.001 ms 24.002 ms

07

08




redes privadas virtuales capítulo 03

Documents