Archivo del sitio
Knet será la primera compañía en pasarse a IPv6. Ejemplo de DNS64 y NAT64 en routers Cisco.
Una pequeña operadora de ADSL se adelanta a las grandes competidoras e instala IPv6 en su sistema. Knet ha sido la primera que anunció que ofrecería conectividad IPv6 a todos sus clientes. Según un comunicado de la empresa, lo hará antes de que se agoten las direcciones IPv4. Con esto, dará podrá dar servicio a nuevos clientes sin la necesidad de utilizar sistemas NAT, como Movistar. No utilizar el sistema NAT significa no tener que compartir la misma dirección IP con varios usuarios.
Estamos ante una necesidad de cambiar hacia el protocolo de direccionamiento IPv6, ya que se han agotado las direcciones tradicionales de 32 bits. En un primer momento, no se harán demasiados cambios en los ordenadores, puesto que los sistemas ya son compatibles, aunque no se descarta la posibilidad de cambiar los módems de acceso.
Knet, la operadora de La Rioja trabajará con dual-stock, lo que significa que tendrá equipo que trabajara al mismo tiempo con los dos protocolos, tanto con el IPv4 como con el IPv6. Además, se ha demostrado que ambas tecnologías se comunican entre sí a través de los sistemas DNS64 y NAT64.
En primer lugar, el NAT64 se encarga de la traducción de las direcciones entre hosts que sólo tienen conectividad IPv6 con hosts que sólo tienen conectividad IPv4. Tras la resolución del nombre por el DNS64, se pide la dirección web a través de NAT64.
Para lograr este objetivo se debe contar con un equipo de red que sea capaz de realizar una traslación de protocolos IPv4 <-> IPv6. Entre otras cosas, este mapeo debe incluir el mapeo de las direcciones de capa de red de uno y otro protocolo.
Del lado de la red solo-IPv6, las direcciones IPv4 se mapean dentro de un prefijo IPv6 el cual debe tener suficientes bits de host para mapear todo el espacio IPv4.
En segundo lugar, el DNS64, sirve para compatibilizar la resolución de nombres de ambos sistemas. Si el usuario está usando el protocolo IPv6, al acceder a una página que no se hay adaptado a este protocolo, DNS64 hará una petición a IPv4 pidiéndole un registro. A través de este registro, los servidores DNS responderán, traducirán la página al IPv6 y se la mostrarán al usuario, incluyendo en las respuestas registros AAAA que mapean las direcciones IPv4 dentro del prefijo NAT64.
En conclusión, podemos decir que es importante que las operadoras estén dando pasos hacia un nuevo protocolo en Internet, aunque desde Knet no se dan fechas exactas del cambio.
Fuentes: http://www.readwriteweb.es y http://es.wikipedia.org
Ejemplo de configuración de una red de enrutamiento para una comunicación NAT64 sin estado.
Aprovechando esta noticia que en realidad se conoce desde hace unos días, vamos a presentar un ejemplo de configuración del NAT64 para routers Cisco. La comunicación NAT64 sin estado está habilitada en la solución Cisco Carried-Grade IPv6, que pretende preservar las infraestructuras IPv4 y prepararse para una transición gradual hacia IPv6.
Los requisitos para configurar NAT64 sin estado son los siguientes:
- Una dirección IPv6 asignada a cualquier host de la red debe tener una dirección válida de IPv4 traducible y viceversa.
- Se debe habilitar el comando IPv6 unicast-routing para que esta configuración funcione.
- Hay que poseer una IOS lo suficientemente actual para que soporte NAT64. Con mi IOS c7200 no es suficiente, por lo que no voy a poder mostraros con GNS3 el resultado de ejecutar los comandos. Lo mostraré de todos modos en texto plano.
- Habilitamos el modo privilegiado EXEC:
Router> enable - Entramos en modo de configuración global:
Router# configure terminal - Habilitamos el envío de datagramas IPv6 unicast:
Router(config)# ipv6 unicast-routing - Configuramos un tipo de interfaz y entramos en la interfaz modo de configuración:
Router(config)# interface giabitethernet0/0/0 - Añadimos una descripción a la interfaz de configuración:
Router(config-if)# description interface towards ipv4 side - Permitimos el procesamiento de IPv6 en una interfaz:
Router(config-if)# ipv6 enable - Configuramos una dirección IPv6 sobre la base de un prefijo de IPv6 general y habilitamos el procesamiento de IPv6 en una interfaz:
Router(config-if)# ipv6 address 2001:1::/96 - Habilitamos la traducción NAT64 sin estado en la interfaz IPv6:
Router(config-if)# nat64 enable - Salimos del modo de configuración de interfaz y volvemos al modo de configuración global:
Router(config-if)# exit - Configuramos otro tipo de interfaz y entramos en la interfaz modo de configuración:
Router(config)# interface giabitethernet1/2/0 - Añadimos una descripción a la interfaz de configuración:
Router(config-if)# description interface towards ipv6 side - Configuramos una dirección IPv4 para esa interfaz:
Router(config-if)# ip address 192.168.0.0 255.255.255.0 - Habilitamos la traducción NAT64 sin estado en la interfaz IPv4:
Router(config-if)# nat64 enable - Salimos del modo de configuración de interfaz y volvemos al modo de configuración global:
Router(config-if)# exit - Definimos el prefijo sin Estado NAT64 que se añadirá a los hosts IPv4 para traducir la dirección IPv4 en una dirección IPv6. El comando también identifica el prefijo que debe ser usado para crear las direcciones IPv4 traducibles para los hosts IPv6.
Router(config)# nat64 prefix stateless 2001:0db8:0:1::/9 - Enrutamos el tráfico IPv4 hacia la correcta interfaz de IPv6.
Router(config)# nat64 route 192.168.0.0/24 gigabitethernet0/0/1 - Salimos del modo de configuración global y volvemos al modo privilegiado EXEC:
Router(config)# end
Seguimiento y mantenimiento de la red de enrutamiento NAT64 sin estado.
Para verificar y monitorear la red de enrutamiento sin estado NAT64, vamos a ejecutar los siguientes comandos en el modo privilegiado.
- show nat64 statistics
Este comando muestra las estadísticas globales y específicas de la interfaz de los paquetes que se traducen y los que se pierden.Router# show nat64 statisticsNAT64 StatisticsGlobal Stats:
Packets translated (IPv4 -> IPv6): 21
Packets translated (IPv6 -> IPv4): 15
GigabitEthernet0/0/1 (IPv4 configured, IPv6 configured):
Packets translated (IPv4 -> IPv6): 5
Packets translated (IPv6 -> IPv4): 0
Packets dropped: 0
GigabitEthernet1/2/0 (IPv4 configured, IPv6 configured):
Packets translated (IPv4 -> IPv6): 0
Packets translated (IPv6 -> IPv4): 5
Packets dropped: 0 - show ipv6 route
Este comando muestra el prefijo configurado sin estado y la ruta específica para las direcciones IPv6 (IPv4 traducidas) apuntando hacia el lado de IPv6.Router# show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - Neighbor Discovery
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
LC 2001::1/128 [0/0] via FastEthernet0/3/4, receive
S 2001::1B01:10A/128 [1/0] via FastEthernet0/3/4, directly connected
S 3001::/96 [1/0] via ::42, NVI0
S 3001::1E1E:2/128 [1/0] via FastEthernet0/3/0, directly connected
LC 3001::C0A8:64D5/128 [0/0] via FastEthernet0/3/0, receive
L FF00::/8 [0/0] via Null0, receive - show ip route
Este comando muestra las direcciones IPv4 en Internet que han alcanzado el lado de IPv4.Router# show ip routeCodes: R - RIP derived, O - OSPF derived,
C - connected, S - static, B - BGP derived,
* - candidate default route, IA - OSPF inter area route,
i - IS-IS derived, ia - IS-IS, U - per-user static route,
o - on-demand routing, M - mobile, P - periodic downloaded static route,
D - EIGRP, EX - EIGRP external, E1 - OSPF external type 1 route,
E2 - OSPF external type 2 route, N1 - OSPF NSSA external type 1 route,
N2 - OSPF NSSA external type 2 route
Gateway of last resort is 10.119.254.240 to network 10.140.0.0
O E2 10.110.0.0 [160/5] via 10.119.254.6, 0:01:00, Ethernet2
E 10.67.10.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
O E2 10.68.132.0 [160/5] via 10.119.254.6, 0:00:59, Ethernet2
O E2 10.130.0.0 [160/5] via 10.119.254.6, 0:00:59, Ethernet2
E 10.128.0.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
E 10.129.0.0 [200/129] via 10.119.254.240, 0:02:22, Ethernet2
E 10.65.129.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
E 10.10.0.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
E 10.75.139.0 [200/129] via 10.119.254.240, 0:02:23, Ethernet2
E 10.16.208.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
E 10.84.148.0 [200/129] via 10.119.254.240, 0:02:23, Ethernet2
E 10.31.223.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
E 10.44.236.0 [200/129] via 10.119.254.240, 0:02:23, Ethernet2
E 10.141.0.0 [200/129] via 10.119.254.240, 0:02:22, Ethernet2
E 10.140.0.0 [200/129] via 10.119.254.240, 0:02:23, Ethernet2
IPv6 Routing Table - default - 6 entries - debug nat64
Este comando habilita la depuración del NAT64 sin estado.Router# debug nat64 statisticsNAT64 statistics debugging is on
Sep 16 18:26:24.537 IST: NAT64 (stats): Received stats update for IDB(FastEthernet0/3/5)
Sep 16 18:26:24.537 IST: NAT64 (stats): Updating pkts_translated_v4v6 from 94368894 to
95856998 (is_delta(TRUE) value(1488104))
Sep 16 18:26:24.537 IST: NAT64 (stats): Received stats update for IDB(FastEthernet0/3/4)
Sep 16 18:26:24.537 IST: NAT64 (stats): Updating pkts_translated_v6v4 from 7771538 to
7894088 (is_delta(TRUE) value(122550))
Sep 16 18:26:24.537 IST: NAT64 (stats): Received global stats update
Sep 16 18:26:24.537 IST: NAT64 (stats): Updating pkts_translated_v4v6 from 1718650332 to
1720138437 (is_delta(TRUE) value(1488105))
Sep 16 18:26:24.537 IST: NAT64 (stats): Updating pkts_translated_v6v4 from 1604459283 to
1604581833 (is_delta(TRUE) value(122550)) - ping
Lo siguiente es un ejemplo de una captura de paquetes desde el lado de IPv6 cuando se especifica el comando ping 198.168.0.2 después de configurar el comandonat64 enabletanto en lasinterfaces IPv4 como en las interfaces IPv6.Router# ping 198.168.0.2Time Source Destination Protocol Info
1 0.000000 2001::c6a7:2 2001::c6a8:2 ICMPv6 Echo request
Frame 1: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)
Arrival Time: Oct 8, 2010 11:54:06.408354000 India Standard Time
Epoch Time: 1286519046.408354000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 118 bytes (944 bits)
Capture Length: 118 bytes (944 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocol in frame: eth:1pv6:icmpv6: data]
Ethernet II, Src:Cisco_c3:64:94 (00:22:64:c3:64:94), Dst: Cisco_23:f2:30
(00:1f:6c:23:f2:30)
Destination: Cisco_23:f2:30 (00:1f:6c:23:f2:30)
Address: Cisco_23:f2:30 (00:1f:6c:23:f2:30)
(0 .... .... .... .... = IG bit: Individual address (unicast... ....
(0 .... .... .... .... = LG bit: Globally unique address (factory default... ....
Source: Cisco_c3:64:94 (00:22:64:c3:64:94)
Address: Cisco_c3:64:94 (00:22:64:c3:64:94)
(0 .... .... .... .... = IG bit: Individual address (unicast... ....
(0 .... .... .... .... = LG bit: Globally unique address (factory default... ....
Type: IPv6 (0x86dd)
Internet Protocol Version 6, src: 2001::c6a7:2 (2001::c6a7:2), Dst: 2001::c6a8:2
(2001::c6a8:2)
0110 .... = Version: 6
[0110 .... = This field makes the filter “ip.version ==6” possible:: 6]
0000 0000 ... .... .... .... .... = Traffic class: 0x00000000 ....
0000 00.. .... .... .... .... .... = Differentiated Services Field: Default ....
(0x00000000)
0. .... .... .... ... .... = ECN-Capable Transport (ECT): Not set.. .... ....
0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 .... .... ....
Payload length: 64
Next header: 64
Hop limit: 64
Source: 2001::c6a7:2 (2001::c6a7:2)
[Source Teredo Server IPv4: 0.0.0.0 (0.0.0.0)]
[Source Teredo Port: 6535]
[Source Teredo Client IPv4: 198.51.100.1 (57.88.255.253)]
Destination: 2001:c6a8:2 (2001::c6a8:2)
[Destination Teredo Server IPv4: 0.0.0.0 {0.0.0.0)]
[Destination Teredo Port: 65535]
[Destination Teredo Client IPv4: 198.51.100.2 {198.51.100.2)]
Internet Control Message Protocol v6
Type: 128 (Echo request)
Code: 0 (Should always be zero)
Checksum: 0xaed2 [correct]
ID: 0x5018
Sequence: 0x0000
Data (56 bytes)
Data: 069ae4c0d3b060008090a0b0c0d0e0f1011121314151617...
[Length: 57]
Configuración final
Si copiamos la siguiente secuencia en el modo de configuración global obtendremos la configuración deseada. Para listarla de nuevo, por ejemplo para guardarla en un fichero, podemos utilizar el comando show running config.
ipv6 unicast-routing
!
interface GigabitEthernet0/0/1
description interface towards ipv4 side
ip address 198.168.0.0 255.255.255.0
nat64 enable
!
interface GigabitEthernet1/2/0
description interface towards ipv6 side
ipv6 address 2001::1/128
ipv6 enable
nat64 enable
!
nat64 prefix stateless 2001::/96
nat64 route 198.167.0.0/24 GigabitEthernet1/2/0
Esto es todo. Un saludo.
Fuente: http://www.cisco.com
Jornada sobre empleo y talento en el sector TIC
Organizada por CISCO en Colaboración con sus principales Partners.
¿Reconoces una buena oportunidad?
¿Deseas potenciar tu carrera en el sector TIC?
¿Te interesa la tecnología CISCO?
Miércoles, 11 de Mayo de 2011, de 9:30h a 18:00h en Cisco Madrid Avda. de la Vega 15 Edif. 4 28100 Alcobendas (Madrid)
El objetivo de este evento es dar a conocer las diferentes vías de Desarrollo Profesional en el entorno tecnológico a través de Cisco y sus principales Partners, facilitando el acceso directo a las oportunidades de empleo tanto a futuros talentos como a profesionales en activo.
Tendrás oportunidad de:
- Participar en foros de discusión relacionados con el sector de TIC.
- Conocer y acceder a los principales partners de Cisco donde desarrollar tu actividad profesional.
- Conocer el entorno tecnológico de Cisco.
Accederán con preferencia los candidatos con certificaciones Cisco (CCNA 3 en adelante).
Acércate y descubre nuevas oportunidades en tu futuro profesional.
Para asistir a la jornada será imprescindible realizar el registro: http://www.partnertalentevents.com/candidates/madrid
Adjunta tu Currículum Vitae, de este modo facilitarás la planificación de reuniones individuales y en grupo con las empresas asistentes.
Asimismo, queremos recordarte que puedes adjuntar tu candidatura en el Talent Portal, espacio donde las empresas publican sus ofertas de trabajo: http://www.partnertalentportal.com/europe/login.asp
Esperando contar con tu presencia en La Jornada sobre Empleo y Talento Tecnológico, recibe un cordial saludo,
Cisco & Partners de Cisco.
Fuente: Cisco Networking Academy <news_netacad@cisconaemeaspanish.imakenews.net>
Cómo implementar redes WAN seguras y convergentes. Simulación de una VPN con IPsec en GNS3.
1. INTRODUCCIÓN.
IPsec es un marco de estándares abiertos desarrollados por el Internet Engineering Task Force (IETF), que proporciona seguridad para la transmisión de información sensible a través de redes sin protección, como es el caso de Internet.
IPsec actúa en la capa de red, lo que hace que sea más flexible frente a otros protocolos que actúan a partir de la capa de transporte (modelo OSI), como SSL, TLS o SSH. Así, proporciona protección y autenticación de los paquetes IP entre los dispositivos IPsec participantes («pares»), por ejemplo dos routers de Cisco.
En la figura siguiente se ofrece una visión simplificada de cómo funciona IPsec en un router
Cisco. Dos routers establecen un túnel IPsec virtual entre sí utilizando algoritmos y parámetros comunes. El tráfico de color rojo es el tráfico que fluye a través del router, que sirve para ir a Internet y no a través del túnel VPN. El verde es el tráfico que pretende ir de un sitio a otro a través del túnel IPsec VPN.
¿Pero por qué utilizar IPsec para crear redes privadas virtuales?
Porque debemos asumir que los nodos externos pueden ser maliciosos e IPsec proporciona una solución de seguridad más robusta que los servicios propiertarios de Cisco y está basada en estándares.
¿Y entonces por qué utilizar routers Cisco?
Porque, al fin y al cabo, Cisco es el líder mundial en el suministro de hardware y soluciones de software de redes LAN y WAN. La sede de la empresa Cisco se encuentra en San Francisco y las sucursales y distribuidores autorizados de Cisco en la actualidad existen en la mayoría de los países en el mundo por lo tanto los dispositivos de hardware de Cisco se utilizan en todas las regiones del mundo. Así pues, creo que puede ser interesante mostrar un ejemplo de su funcionamiento.
2. HERRAMIENTAS DE USO.
Para esta práctica, actualmente no puedo contar con el hardware necesario para construir una maqueta en la que poder mostrar el funcionamiento de una VPN con IPsec, por lo que he decidido utilizar un simulador gráfico de red, el GNS3.
GNS3 es un simulador de distribución libre que permite diseñar topologías de red complejas y poner en marcha simulaciones sobre los routers. Está estrechamente relacionado con Dynamips, un emulador de IOS que permite a los usuarios ejecutar imágenes de las IOS de los routers de Cisco Systems. En conjunto, se trata de una buena herramienta complementaria a los verdaderos laboratorios para administradores de redes Cisco y en especial para estudiantes. Lo podéis descargar desde aquí.
La IOS escogida para este ejemplo es la del Cisco router 7200, que aunque comienza a estar anticuado, sabemos que soporta las funciones de configuración para la implementación de una VPN con IPsec. He subido la imagen que he utilizado yo a Megaupload. Podéis descargarla desde este enlace.
Una vez cargada la imagen de la IOS y seleccionado el espacio de trabajo, podemos comenzar a diseñar nuestra topología.
3. ESCENARIO.
La maqueta está formada por tres routers c7200. Hay que arrastrar cada uno de los dispositivos al espacio de trabajo y configurar sus interfaces. Así pues, seleccionamos el router añadido con el botón derecho del ratón y hacemos click en la pestaña Slots. Nuestros routers dispondrán, por ejemplo, de un slot con una interfaz Fast-Ethernet y de otro con 8 interfaces Serie.
La topología final será la siguiente, los routers R1 y R3 estarán conectados a R2, que es el router externo que se conecta a Internet. R1 se conecta mediante su interfaz Fast-Ethernet. El uso del switch en la vida real será necesario o no según si usamos conectores RJ45 directo (para dispositivos desiguales) o cruzado (para dispositivos igualitarios). R3 se conectará a R2 mediante una interfaz serie.
Para conectar los routers mediante las interfaces simplemente se usa el icono con forma de conector que se observa en la imagen superior y se hace click en uno de los nodos que queremos conectar, arrastrándolo hasta el otro nodo.
Cuando ya esté todo conectado, pulsamos el play para activar el funcionamiento de nuestra maqueta.
Para comenzar a configurar los routers, ya sólo hace falta pulsar el icono de consola, y se abrirán automáticamente tres ventanas que emularán las consolas de los routers. Ya podemos empezar a configurar, utilizando el Cisco IOS command-line interface.
Los objetivos son los siguientes:
- Configurar las interfaces de direccionamiento de los routers así como un protolo de routing, por ejemplo, EIGRP.
- Crear una VPN IPsec entre los nodos R1 y R3, para evitar que R2 pueda ver los paquetes enviados.
- Verificar el funcionamiento de IPsec.
A partir de ahora veréis un seguimiento paso a paso.
4. CONFIGURACIÓN DE LAS INTERFACES.
En primer lugar configuraremos las interfaces de loopback y las interfaces serie, asignando las direcciones IP a cada una y aplicando el comando ‘no shutdown’ a todos las conexiones físicas para dejarlas abiertas. El comando ‘clock rate’ es necesario para sincronizar las interfaces Serie.
Aplicaremos un clock rate de 64000 bits por segundo en el conector DCE.
Imaginaremos que hemos contratado la subred 192.168.12.0/24, que usaremos para las interfaces Fast-Ethernet y la subred 192.168.23.0/24 para las interfaces serie. La interfaz de loopback de R1 será la 172.16.1.1/24 y la de R2, la 172.16.3.1/24.
En todos los routers, habilitamos el modo configuración global y le ponemos un nombre para evitar confusiones a la hora de configurar. Los mensajes que contienen un asterisco son los mensajes de confirmación que nos aparecen por consola a medida que escribimos las órdenes.
Router>enable Router#configure terminal *Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname R1 R1(config)#
Ahora configuraremos las interfaces de cada uno de los routers.
R1(config)#interface loopback0 *Jun 8 10:30:51.335: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up R1(config-if)#ip address 172.16.1.1 255.255.255.0 R1(config-if)#interface fastethernet0/0 R1(config-if)#ip address 192.168.12.1 255.255.255.0 R1(config-if)#no shutdown *Jun 8 10:36:39.063: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up *Jun 8 10:36:39.063: %ENTITY_ALARM-6-INFO: CLEAR INFO Fa0/0 Physical Port Administrative State Down *Jun 8 10:36:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up R2(config)#interface fastEthernet 0/0 R2(config-if)#ip address 192.168.12.2 255.255.255.0 R2(config-if)#no shutdown *Jun 8 10:47:02.647: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to down *Jun 8 10:47:02.647: %ENTITY_ALARM-6-INFO: CLEAR INFO Fa0/0 Physical Port Administrative State Down *Jun 8 10:47:02.647: %ENTITY_ALARM-6-INFO: ASSERT CRITICAL Fa0/0 Physical Port Link Down R2(config-if)#interface serial1/0 R2(config-if)#ip address 192.168.23.2 255.255.255.0 R2(config-if)#clockrate 64000 R2(config-if)#no shutdown *Jun 8 10:48:39.323: %LINK-3-UPDOWN: Interface Serial1/0, changed state to up *Jun 8 10:48:39.323: %ENTITY_ALARM-6-INFO: CLEAR INFO Se1/0 Physical Port Administrative State Down *Jun 8 10:48:40.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up R3(config)#interface loopback0 *Jun 8 10:51:27.167: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to R3(config-if)#ip address 172.16.3.1 255.255.255.0 R3(config-if)#interface serial1/0 R3(config-if)#ip address 192.168.23.3 255.255.255.0 R3(config-if)#no shutdown *Jun 8 10:52:51.315: %LINK-3-UPDOWN: Interface Serial1/0, changed state to up *Jun 8 10:52:51.315: %ENTITY_ALARM-6-INFO: CLEAR INFO Se1/0 Physical Port Administrative State Down *Jun 8 10:52:52.319: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up
Para comprobar que tenemos conectividad entre las subredes locales usamos el comando ping.
R1#ping 192.168.12.2 *Type escape sequence to abort. *Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds: !!!!! *Success rate is 100 percent (5/5), round-trip min/avg/max = 164/217/300 ms R3#ping 192.168.23.2 *Type escape sequence to abort. *Sending 5, 100-byte ICMP Echos to 192.168.23.2, timeout is 2 seconds: !!!!! *Success rate is 100 percent (5/5), round-trip min/avg/max = 140/192/220 ms
5. CONFIGURAR EIGRP
Con la intención de mantener conectividad entre redes remotas, configuramos EIGRP (un protocolo de routing propietario de Cisco) para poder enrutar entre todas las redes del diagrama. Añadiremos todas las subredes conectadas a cada router al Sistema Autónomo 1 y deshabilitaremos la sumarización de redes automática para que todas las subredes sean visibles desde todos los puntos.
R1(config)#router eigrp 1 R1(config-router)#no auto-summary R1(config-router)#network 172.16.0.0 R1(config-router)#network 192.168.12.0 *Jun 8 11:34:40.299: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacency R2(config)#router eigrp 1 R2(config-router)#no auto-summary R2(config-router)#network 192.168.12.0 *Jun 8 11:34:40.003: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.12.1 (FastEthernet0/0) R2(config-router)# network 192.168.23.0 *Jun 8 11:34:46.963: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.23.3 (Serial1/0) is up: new adjacency R3(config)#router eigrp 1 R3(config-router)#no auto-summary R3(config-router)#network 172.16.0.0 R3(config-router)#network 192.168.23.0 *Jun 8 11:34:46.851: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.23.2 (Serial1/0) is up: new adjacency
Ahora ya deberíamos tener conectividad total por IP. Lo probaremos con el siguiente script TCL en R1.
R1#tclsh
R1(tcl)#foreach address {
+>(tcl)#172.16.1.1
+>(tcl)#192.168.12.1
+>(tcl)#192.168.12.2
+>(tcl)#192.168.23.2
+>(tcl)#172.16.3.1
+>(tcl)#192.168.23.3
+>(tcl)#} { ping $address }
6. CREAR POLÍTICAS IKE
Para implementar una VPN con IPsec, en primer lugar hay que implementar los parámetros «Internet Key Exchange» (IKE), utilizados para validar las políticas entre pares.
IKE es un protocolo que define el método de intercambio de claves sobre IP en una primera fase de negociación segura. De esta forma, los pares intercambian las políticas IPsec para la autenticación y la encriptación del tráfico de datos.
La política IKE controla la autenticación, el algoritmo de encriptación y el método de intercambio de claves usado por las propuestas IKE, siendo enviados y recibidos por los extremos IPsec. La política IPsec se usa para encriptar tráfico de datos enviado a través de un túnel VPN.
Para poder empezar a trabajar, hay que habilitar IKE. En algunas IOS está habilitado por defecto, pero por si acaso ejecutaremos el comando correspondiente.
R1(config)#crypto isakmp enable
Para permitir la negociación, en primer lugar hay que crear una política ISAKMP (Internet Security Association and Key Management Protocol) y configurar la asociación entre los pares que participan en la política ISAKMP. Ésta política define la autenticación, los algoritmos de encriptación y la función hash utilizada para enviar tráfico de control entre los dos nodos de la VPN.
Para iniciar las política ISAKMP introducimos el siguiente comando en modo configuración global.
R1(config)#crypto isakmp policy 10
Si a continuación introducimos el parámetro ‘?’ podemos ver todos los parámetros IKE disponibles. Al conjunto de parámetros que se utilizan para definir los requerimientos de seguridad de una comunicación en una dirección particular (entrante o saliente), se le llama «Asociación de Seguridad» (SA).
La elección de un algoritmo de encriptación controlará la confidencialidad del canal de control entre los dos nodos. El algoritmo hash controla la integridad de los datos. El tipo de autenticación se asegura de que, en efecto, el paquete fue enviado y firmado por el par remoto.
El grupo Diffie-Hellman se usa para crear una clave secreta compartida por los pares que nunca haya sido enviada a través de la red.
Vamos a configurar una autenticación de claves pre-compartidas. Utilizaremos encryptación AES 256 (es decir una clave de 256 bits y un tamaño de bloque de 16 bytes) y SHA como algoritmo hash, además de Diffie-Hellman grupo 5 (1536 bits) para esta política IKE.
Le daremos a esta Asociación de Seguridad un tiempo de vida de 3600 segundos (una hora). Se trata del tiempo máximo en el que una política de seguridad se utiliza sin necesidad de negociarla de nuevo. Obviamente, esta configuración hay que aplicarla a los dos nodos en los que crearemos la VPN.
R1(config)#crypto isakmp policy 10 R1(config-isakmp)#authentication pre-share R1(config-isakmp)#encryption aes 256 R1(config-isakmp)#hash sha R1(config-isakmp)#group 5 R1(config-isakmp)#lifetime 3600 R3(config)#crypto isakmp policy 10 R3(config-isakmp)#authentication pre-share R3(config-isakmp)#encryption aes 256 R3(config-isakmp)#hash sha R3(config-isakmp)#group 5 R3(config-isakmp)#lifetime 3600
Aunque sólo necesitamos configurar una política aquí, podemos configurar mútliples políticas IKE. Los diferentes números de prioridad están relacionados con la seguridad. Cuanto menor sea el número, más segura es la política. Los routers comprobarán y verificarán qué políticas de seguridad con compatibles con sus pares, comenzando con la política de menor número.
Podemos verificar nuestra política IKE con el comando show crypto isakmp policy.
7. CONFIGURAR CLAVES PRECONPARTIDAS.
Una vez elegido nuestro método de autenticación, tenemos que configurar una clave en cada router que se corresponda con el otro nodo de la VPN. Las claves utilizadas deben coincidir para que la autenticación sea satisfactoria y para que la relación IKE entre pares se complete.
Por simplicidad, utilizaremos la clave «sssi». Obviamente, para cualquier otro caso se debería utilizar una clave más compleja. Usaremos el comando crypto isakmp key sssi address junto con las direcciones IP de las interfaces físicas de los nodos del extremo opuesto.
R1(config)#crypto isakmp key sssi address 192.168.23.3 R3(config)#crypto isakmp key sssi address 192.168.12.1
8. CONFIGURAR EL IPSEC TRANSFORM SET Y LOS LIFETIMES.
El IPsec transform set es otro parámetro de configuración cifrada que negocian los routers para formar Asociaciones de Seguridad. De la misma forma que las políticas ISAKMP, también pueden existir múltiples transform sets en un router. Los routers compararán sus transform sets con el par remoto hasta encontrar uno que coincida.
Crearemos un transform set IPsec usando la sintaxis «crypto ipsec transform set». Utilizaremos el caracter ‘?’ para descubrir los parámetros disponibles.
IKE está formado por una cabecera de autenticación «Authentication Header» (AH) o por una cabecera de autenticación más encriptación que se conoce como «Encapsulating Security Payload» (ESP). Una Asociación de Seguridad puede ser AH o ESP, pero no ambas. IPsec ofrece dos modos de operación según utilice AH o ESP para proteger los datos sobre IP. Se conocen como «modo de transporte» (si usamos AH) o «modo túnel» (si usamos ESP). En esta ocasión vamos a decantarnos por ESP.
Así pues, ejecutamos el comando en ambos routers.
R1(config)#crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac R3(config)#crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac
Podemos especificar nuestro tiempo de seguridad asociado un vez creado el transform-set. A continuación cambiaremos, en R1 y R3, nuestro límite de tiempo a 30 minutos.
R1(config)#crypto ipsec security-association lifetime seconds 1800 R3(config)#crypto ipsec security-association lifetime seconds 1800
9. DEFINIR EL TRÁFICO QUE NOS INTERESA.
Ahora que todas las opciones de encriptación están claras, definiremos listas de acceso extendidas para decirle al router qué tráfico debe encriptar. En este caso, un paquete al que se le permite, mediante una lista de acceso usada para definir tráfico IPsec, será encriptado si la sesión IPsec ha sido configurada correctamente. Sin embargo, un paquete denegado por alguna de estas listas de acceso no se tirará, sino que será enviado sin encriptar.
Como en todas las listas de acceso, existe un «deny» implícito al final, que en este caso implica que la acción por defecto es no encriptar tráfico. Si no hay una asociación de seguridad correctamente configurada, entonces tampoco se encriptará el tráfico, sino que será enviado sin encriptar.
En este escenario, el tráfico que vamos a encriptar es tráfico procedente de la dirección de loopback de R1 hasta la dirección de loopback de R3, o viceversa. Las listas de acceso se usan en las interfaces de salida de los nodos terminales de la VPN, por lo que debemos configurarlas acorde a esto. La configuración de la lista de acceso de R1 debe ser exactamente el espejo de la de R3 para que funcione correctamente.
R1(config)#access-list 101 permit ip 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255 R3(config)#access-list 101 permit ip 172.16.3.0 0.0.0.255 172.16.1.0 0.0.0.255
Como se puede observar, las máscaras en las listas de acceso se escriben como máscaras invertidas, siendo en realidad redes /24 como hemos indicado al comienzo de la memoria.
10- CREAR Y APLICAR CRYPTO MAPS
Ahora que hemos creado estos pequeños módulos de configuración, podemos llevarlos todos a un crypto map. Un crypto map es una asignación que asocia el tráfico que coincide con una lista de acceso (como la definida anteriormente) a un par de nodos y a diversas políticas IKE y opciones de IPsec. Estos mapas de cifrado pueden tener múltiples sentencias, por lo que podríamos obtener tráfico que coincide con una cierta lista de acceso siendo encriptado y enviado a otro par IPsec, y por otro lado obtener otro tráfico que coincide con una lista de acceso diferente siendo encriptada hacia otro nodo diferente.
Una vez que un mapa de cifrado haya sido creado, puede ser aplicado a una o más interfaces, pero siempre debería aplicarse a las interfaces enfrentadas con la interfaz de su par IPsec.
Para crear un mapa de cifrado, usaremos el comando «crypto map» en modo configuración global, al que añadiremos un nombre y un número de secuencia, e introduciremos la configuración deseada asociada a ese número de secuencia. Muchas sentencias de los mapas de cifrado pueden pertenecer al mismo crypto map, y en ese caso serían evaluados en orden numérido ascendente. También introduciremos el tipo de cifrado. En cuanto a esto último, si usamos el tipo «ipsec-isakmp» significa que se usará IKE para establecer asociaciones de seguridad con IPsec, al contrario de lo que ocurriría en caso de seleccionar el tipo «ipsecmanual».
Vamos a llamar al crypto map «MAPA1» y utilizaremos el número de secuencia 10. Cuando entremos en el modo de configuración de mapas de cifrado en R1 nos aparecerá una advertencia, indicando que el peer debe estar completamente configurado antes de que el mapa de cifrado sea considerado válido y pueda ser aplicado activamente.
R1(config)#crypto map MAPA1 10 ipsec-isakmp
Ahora usaremos el comando «match address» junto al número de la lista de acceso creada para especificar qué lista de acceso definirá el tráfico a encriptar.
R1(config-crypto-map)#match address 101
El comando «set» nos ofrece muchas posibilidades para trabajar con un mapa de cifrado. Vamos a utilizar el carácter de ayuda ‘?’ para conocerlas.
Algunos de estos comandos son imprescindibles, como «set ip», «set peer» o «set hostname». Los aplicaremos a la interfaz del nodo del otro extremo de la VPN. Además seleccionaremos el número del transform set definido anteriormente.
También seleccionaremos el comando «set pfs claves» (perfect forwarding secrecy type) cuya clave está directamente relacionada con el tipo de módulo Diffie-Hellman seleccionado. Desde este modo de configuración también podemos modificar el tiempo de vida de la Asociación de Seguridad. La configuración nos ha quedado así:
R1(config-crypto-map)#set peer 192.168.23.3 R1(config-crypto-map)#set pfs group5 R1(config-crypto-map)#set transform-set 50 R1(config-crypto-map)#set security-association lifetime seconds 900 R3(config)#crypto map MAPA1 10 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. R3(config-crypto-map)#match address 101 R3(config-crypto-map)#set peer 192.168.12.1 R3(config-crypto-map)#set pfs group5 R3(config-crypto-map)#set transform-set 50 R3(config-crypto-map)#set security-association lifetime seconds 900
Ahora que los mapas de cifrado han sido creados, el último paso en el proceso de creación VPN’s nodo a nodo es aplicar los mapas a las interfaces. Esto lo conseguimos entrando en modo configuración de interfaz e introduciendo el comando «crypto map nombre». Es necesario comprender que las asociaciones de seguridad no se establecerán hasta que el mapa de cifrado sea activado al reconocer tráfico que le interesa.
No crearemos dicho tráfico aún, porque tendremos que permitir algunos comandos de depuración en próximos pasos.
De momento, el router generará una notificación indicando que se ha activado el cifrado en dichas interfaces.
R1(config)#interface fastEthernet 0/0 R1(config-if)#crypto map MAPA1 *Jun 8 21:07:24.167: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON R3(config)#interface serial 1/0 R3(config-if)#crypto map MAPA1 *Jun 8 21:08:38.295: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
11. VERIFICAR CONFIGURACIÓN
En el paso 6 usamos el comando «show crypto isakmp policy» para mostrar las políticas ISAKMP configuradas en el router. De forma similar, el comando «show crypto ipsec transform set»
muestra por pantalla las políticas IPsec configuradas en los transform sets.
A continuación usaremos el comando «show crypto map» para mostrar los mapas de cifrado que
se han aplicado al router.
Esta información no cambiará aunque haya tráfico «interesante» cruzando a través de la conexión.
12. VERIFICAR OPERACIÓN IPSEC.
Si usamos el comando «show crypto isakmp sa», éste nos revelará que no existen asociaciones de seguridad IKE todavía. Esta información de salida se verá modificada en cuanto se comience a enviar tráfico «interesante».
Si ahora usamos el comando «show crypto ipsec sa», este comando nos mostrará las asociaciones de seguridad en desuso entre R1 y R3. Podemos fijarnos en la ausencia, tanto de paquetes enviados a través como de asociaciones de seguridad. Esto último se muestra hacia la parte inferior de la salida en ambos routers.
13. INTERPRETAR EVENTOS DE DEPURACION.
En términos de la comunicación real entre los puntos extremos de la VPN, ISAKMP establece normas estrictas en cuanto a cómo puede ser una asociación de seguridad establecida.
La fase 1 de IKE (ISAKMP) negociará el canal seguro entre los nodos, autenticará a su vecino si tiene la clave secreta correcta, y autenticará el nodo remoto a través del canal seguro. La fase 1 de IKE utiliza el «modo principal», que consta de seis mensajes en tres intercambios de eventos.
El resultado es una asociación de seguridad ISAKMP bidireccional. Los intercambios son de entrada/salida, por lo que cada evento se guarda en la depuración como un evento de entrada desde cada router local hasta el router remoto.
La fase 2 de IKE (IPSec) negociará el tunel IPsec entre los dos nodos finales, autenticará los pares y encriptará el tráfico de datos entre ellos a través del tunel cifrado. La fase 2 de IKE usa el proceso llamado «modo rápido» para llevar a cabo su intercambio para establecer dos asociaciones de seguridad unidireccionales.
A continuación en R1 habilitaremos dos comandos de depuración: «debug crypto isakmp» y «debug crypto ipsec».
R1#debug crypto isakmp *Crypto ISAKMP debugging is on R1#debug crypto ipsec *Crypto IPSEC debugging is on
Ahora enviaremos un ping extendido desde la dirección de loopback de R1 hasta la dirección de loopback de R3 y veremos la depuración de la salida de ambos routers. Veremos tanto la negociación ISAKMP como el establecimiento de la asociación de seguridad IPsec.
R1# ping Protocol [ip]: Target IP address: 172.16.3.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 172.16.1.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, String, Record, Timestamp, Verbose [none]: Sweep range of sizes [n]:
En medio de una salida bastante extensa, el resultado obtenido ha sido el siguiente.
*Type escape sequence to abort. *Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds: *Packet sent with a source address of 172.16.1.1 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 228/273/296 ms
Ya podemos cancelar la instrucción de depuración.
R1#undebug all All possible debugging has been turned off
Y ahora sí que se pueden ver datos al introducir los comandos de cifrado.
Podemos observar que esta vez sí que se han encriptado paquetes, y que se han formado varias asociaciones de seguridad.
14. CONFIGURACIONES FINALES
Las configuraciones finales se pueden observar a continuación mediante el uso de la instrucción «show running-config».
____________________________________________________________________ R1#show running-config Building configuration... Current configuration : 2114 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! no aaa new-model ! resource policy ! ip subnet-zero ip cef ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 lifetime 3600 crypto isakmp key sssi address 192.168.23.3 ! crypto ipsec security-association lifetime seconds 1800 ! crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac ! crypto map MAPA1 10 ipsec-isakmp set peer 192.168.23.3 set security-association lifetime seconds 900 set transform-set 50 set pfs group5 match address 101 ! interface Loopback0 ip address 172.16.1.1 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.12.1 255.255.255.0 duplex auto speed auto crypto map MAPA1 ! ! router eigrp 1 network 172.16.0.0 network 192.168.12.0 no auto-summary ! ip classless no ip http server no ip http secure-server ! logging alarm informational access-list 101 permit ip 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255 ! gatekeeper shutdown ! line con 0 stopbits 1 line aux 0 line vty 0 4 ! end ____________________________________________________________________ R2#sh run Building configuration... Current configuration : 1589 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R2 ! boot-start-marker boot-end-marker ! no aaa new-model ! resource policy ! ip subnet-zero ip cef ! interface FastEthernet0/0 ip address 192.168.12.2 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.23.2 255.255.255.0 serial restart-delay 0 clock rate 64000 no dce-terminal-timing-enable ! router eigrp 1 network 192.168.12.0 network 192.168.23.0 no auto-summary ! ip classless no ip http server no ip http secure-server ! logging alarm informational ! control-plane ! gatekeeper shutdown ! line con 0 stopbits 1 line aux 0 line vty 0 4 ! end ____________________________________________________________________ R3#sh run Building configuration... Current configuration : 2024 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R3 ! boot-start-marker boot-end-marker ! no aaa new-model ! resource policy ! ip subnet-zero ip cef ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 lifetime 3600 crypto isakmp key sssi address 192.168.12.1 ! crypto ipsec security-association lifetime seconds 1800 ! crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac ! crypto map MAPA1 10 ipsec-isakmp set peer 192.168.12.1 set security-association lifetime seconds 900 set transform-set 50 set pfs group5 match address 101 ! interface Loopback0 ip address 172.16.3.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.23.3 255.255.255.0 serial restart-delay 0 no dce-terminal-timing-enable crypto map MAPA1 ! router eigrp 1 network 172.16.0.0 network 192.168.23.0 no auto-summary ! ip classless no ip http server no ip http secure-server ! logging alarm informational access-list 101 permit ip 172.16.3.0 0.0.0.255 172.16.1.0 0.0.0.255 ! control-plane ! gatekeeper shutdown ! line con 0 stopbits 1 line aux 0 line vty 0 4 ! end
WebNet Architect 