Ya tenéis disponible para descargaros el segundo capítulo de la serie de tutoriales de redes de sergiomadrigal.com.
En este capítulo abordo la implantación en una red CORE de un proveedor de servicios de un protocolo de enrutamiento dinámico, en este caso OSPF, cuya única finalidad será la de publicar las direcciones IP de las interfaces loopback de los dispositivos que van a componer la red BGP.
Esto se realiza de esta forma como parte de las buenas prácticas a la hora de configurar iBGP.
Así mismo configuro la redistribución de los dos procesos OSPF iniciales que publican las redes LAN de Madrid y Valencia con el núcleo BGP proporcionando así la estructura de enrutamiento dinámico necesaria para que ambos entornos, LAN de Valencia y LAN de Madrid sean accesibles entre sí.
Si tenéis cualquier duda o consulta disponéis de los comentarios tanto en el vídeo como en el blog.
Más allá de las configuraciones en sí mismas que podréis revisar accediendo al enlace, me parece realmente interesante mencionar el siguiente párrafo:
El comando network es el que se utiliza para definir en todos los casos qué interfaces del dispositivo participan del proceso de enrutamiento. Los efectos prácticos del comando son 3
1. Identifica las interfaces a través de las cuáles se publica información del protocolo de enrutamiento hacia los dispositivos vecinos.
2. Identifica las interfaces a través de las cuáles se recibe información del protocolo de enrutamiento publicada por los dispositivos vecinos.
3. La red o subred a la que está asociada la interfaz va a ser incluida en el proceso del protocolo de enrutamiento.
Queda bastante clara la explicación y lo que no es el comando network: no publica las redes que define sino que activa las interfaces que la dupla red / máscara incluye y son las redes asociadas a esas interfaces las que se terminarán publicando.
Os recomiendo que le echéis un vistazo al artículo al completo porque no tiene desperdicio.
Hoy os traigo el primer capítulo de esta serie de laboratorios de routing encaminados a explicar de una forma más práctica cómo configurar equipos Cisco con protocolos de enrutamiento dinámico.
En esta primera entrega os muestro la topología que voy a utilizar, las distintas direcciones IP de los equipos a configurar y una primera parte en la que configuraré OSPF y BGP comprobando así mismo su funcionamiento.
A lo largo de los siguientes episodios buscaré desarrollar por completo la topología para finalmente proporcionaros los archivos del laboratorio en GNS3 para que podáis jugar con ellos cuanto os plazca.
El objetivo del laboratorio de redes es de disponer, para finales de este año, de todo un diseño de red complejo.
Pero como por algún sitio hemos de empezar, hoy nos dedicaremos a configurar la conexión entre dos routers Cisco.
En este ejemplo hemos empleado dos imágenes de un Cisco 3725 [ c3725-adventerprisek9-mz.124-25d ].
Deberemos añadir en las ranuras de configuración de interfaces las correspondientes que necesitamos antes de encender ambos equipos. Como necesitamos al menos un puerto serie por cada uno de los dispositivos, configuraremos convenientemente el dispositivo tal y como muestra la figura.
Una vez iniciados los dos equipos bastará con que accedamos por consola a ambos y configuremos las interfaces serie convenientemente.
Accederemos por consola al router 1 (R1):
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int serial 1/0
R1(config-if)#ip address 192.168.0.1 255.255.255.0
R1(config-if)#no shutdown R1(config-if)#clock rate 64000
Una vez configurado el router 1, pasaremos a configurar el router 2:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int serial 1/0
R2(config-if)#ip add 192.168.0.2 255.255.255.0
R2(config-if)#no shut
Es importante tener muy presente que una conexión serie es una conexión síncrona lo que explica la necesidad de definir un «clock rate» (tiempo de reloj) para sincronizar el equipo DCE, que será el que marque el sincronismo con el equipo DTE, que será el que esté a la espera de recibirlo. La decisión de que R1 sea el DCE es totalmente aleatoria y este mismo diseño podría haberse realizado siendo R2 el equipo DCE.
De esta manera, los dos routers serán capaces de comunicarse sin problemas al haber establecido una conexión serie completa:
R1#ping 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/21/28 ms
R2#ping 192.168.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/32 ms
Una de las cosas que más pueden interesar a un desarrollador web es montar su propio entorno de desarrollo en su propia casa.
El primer paso será instalar y configurar las máquinas que van a proporcionar los servicios que el desarrollador necesite, esto es: un servidor web (Apache, IIS), módulos de ejecución de código dinámico (PHP, PERL, .NET), y bases de datos (MySQL, PostgreSQL, SQLite).
Una vez tengamos los servicios funcionando hay un punto importante a tener en cuenta: estos servicios sólo serán accesibles a través de nuestra red local y los equipos que estén conectados a ella.
¿Y sí queremos hacerlos accesibles desde el exterior?
Para ello necesitaremos configurar nuestros equipos de red convenientemente.
Por lo general, en una red convencional de un hogar disponemos de un dispositivo que nos facilita la conexión a Internet. Este equipo es el que hace de frontera entre nuestra red local (LAN) y la red exterior (WAN). Estos dispositivos normalmente llevan por defecto configurado el servicio NAT.
Esto implica que en el exterior nuestros equipos, todos, tienen una misma y única dirección IP que los identifique. La IP pública.
Para dirigir el tráfico HTTP (puerto 80) hacia la máquina local que está prestando los servicios, debemos realizar lo siguiente:
1. Configura los Cortafuegos (Firewall) software que tengas instalado en la máquina para que permitan las peticiones al puerto 80. Esto parece trivial y obvio pero muchos de los problemas de conectividad vienen provocados por el dichoso firewall de Windows.
2. En el router de casa, configura la redirección de puertos (NAT o PAT) para que se produzca la redirección automática entre cualquier IP del exterior que consulte nuestra IP pública en el puerto 80 y la IP privada de nuestra máquina en ese mismo puerto.
3. Comprueba que el puerto está abierto: [http://www.yougetsignal.com/tools/open-ports/] Ten presente que esta prueba la debes realizar poniendo siempre la IP pública, que es la que va a ser accesible desde el exterior.
Por lo general, salvo que tengas contratado un servicio especial, tu dirección IP pública no es estática y varía con el tiempo. Esto se debe a que los proveedores de servicio disponen de un número limitado de direcciones IP y las van reasignando conforme se van empleando.
Para evitar tener que estar constantemente comprobando qué dirección IP tienes [www.cualesmiip.com], existen servicios gratuitos como DynDNS [http://dyn.com/dns/] que te permiten asociar tu IP pública a un nombre preestablecido y de esa forma sólo tener que memorizar ese nombre.
Ante cualquier anomalía de red un técnico debe actuar de forma concisa y rápida buscando aislar por completo la fuente de error.
En la mayoría de los casos el primer paso será comprobar el alcance de la anomalía y qué servicios o equipos están inaccesibles debido a ella.
Para poder obtener esta información de forma rápida y más o menos precisa todo técnico de redes dispone de dos herramientas básicas para ello: el ping y el traceroute.
Ping
PING’ el acrónimo de Packet Internet Groper, el que puede significar «Buscador o rastreador de paquetes en redes» es una utilidad que envía paquetes ICMP de solicitud y respuesta y cuya finalidad es comprobar que el equipo destino está activo y disponible. También se puede emplear para obtener la latencia (o tiempo de respuesta RTT) entre dos equipos para tener una noción del retardo existente en la conexión. [fuente: Wikipedia]
Esta utilidad suele venir instalada en la práctica totalidad de sistemas operativos/equipos de red y de ahí que ante cualquier situación problemática con una red podamos hacer uso de ella.
Para poder emplearla bajo sistemas Microsoft Windows deberemos primero lanzar una ventana de MS-DOS:
Una vez en ella bastará con que empleemos el comando: ping -equipo-, siendo equipo la dirección IP o el nombre de la máquina (siempre que dispongamos de su traducción DNS correspondiente):
Si el resultado es satisfactorio la respuesta nos dirá además el tiempo de respuesta o latencia y el TTL (Time-to-live). Este último parámetro indica el número de saltos que el paquete ha realizado hasta llegar a destino, pero es un número que depende de otros factores como el tipo de conexión y que explicaremos más adelante.
Si, por el contrario, el equipo no es accesible, la respuesta obtenida será la siguiente.
De este modo con una única utilidad podremos obtener información acerca de la disponibilidad de determinado equipo y, por ende, de determinado servicio.
Traceroute
Traceroute es una utilidad de diagnóstico que permite seguir la pista de los paquetes que vienen desde un host (punto de red). Se obtiene además una estadística del RTT o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de la comunicación. [fuente: Wikipedia]
En este caso lo que se realizan son llamadas a cada uno de los saltos que realiza el paquete y, por tanto, se nos informa del camino (traza la ruta) que sigue el paquete.
Mediante esta utilidad podemos comprender de forma más coherente el camino que siguen los paquetes e identificar problemas de enrutamiento, balanceo, filtado, etc.
En los sistemas MS Windows la aplicación a emplear es tracert. El procedimiento a seguir es similar, deberemos abrir una ventana de MS DOS y lanzar la aplicación: tracert -equipo-
En la respuesta veremos reflejados todos y cada uno de los saltos que realiza el equipo
Si observamos, algunas líneas muestran * en lugar de valores. Esto se debe a que en ese salto nuestro equipo no ha recibido respuesta del equipo destino: hay varias razones para ello pero entre otras el equipo puede tener deshabilitadas las respuestas por motivos de seguridad.
Generalmente si realizamos esta consulta dentro de nuestra red local deberíamos poder ver todas las respuestas.
Con estas dos utilidades, un técnico de redes puede en cuestión de minutos aislar casi por completo la fuente de error de la red y de este modo enfocar todos sus esfuerzos en resolver el punto de fallo. En entornos donde existen una gran cantidad de equipos de red funcionando resulta fundamental discriminar la mayor cantidad de equipos para poder comenzar con el proceso de análisis con un número de variables reducido.
Cuando nos enfrentamos ante la realidad de tener que proporcionar las medidas de seguridad necesarias para preservar la integridad de una red de comunicaciones es fundamental tener muy claros y definidos los conceptos básicos que subyacen a la securización de estas redes.
Confidencialidad, Integridad y Disponibilidad.
Existen tres puntos que debemos asegurar:
Confidencialidad: Sólo los usuarios o sistemas autorizados deben poder ver información sensible o clasificada. Encriptar los datos y separar las redes (datos, management) son un buen primer paso.
Integridad: Los cambios en la información deben ser realizados sólo por usuarios o sistemas autorizados. La corrupción de datos provoca un fallo importante en la seguridad. Existen mecanismos de hashing (resumen) que proporcionan respuesta a esta necesidad asegurando que la información no ha sido modificada durante su transporte.
Disponibilidad: Mantenimiento del estado normal de funcionamiento de los sistemas y la información. Ataques como los DoS (Denial of Service) buscan tumbar sistemas para que la información no esté disponible. Esto puede afectar muy negativamente al normal desarrollo de la actividad de la empresa.
Análisis de seguridad – Conceptos clave.
Activo: Cualquier cosa que es valiosa para una organización.
Vulnerabilidad: Debilidad explotable en un sistema o en su diseño.
Riesgo: Daño potencial a un activo.
Contramedida: Acción que de alguna manera mitiga el riesgo potencial.
El valor de un activo depende de muchos factores. La relación coste-beneficio se obtendrá teniendo en cuenta el valor del activo y el coste de su protección.
Vulnerabilidades
Una lista de posibles vulnerabilidades
Errores en política de seguridad.
Errores de diseño.
Debilidad de protocolos.
Errores de configuración.
Vulnerabilidad de software o hardware.
Factores humanos.
Software malicioso.
Acceso físico a los recursos de red.
Contramedidas
Administrativas: Políticas de seguridad, procedimientos, guías y estándares.
Físicas: Seguridad física, vigilancia.
Lógicas: Contraseñas, firewalls, IPS, Listas de acceso, conexiones seguras vía VPN, etc.
Atacantes potenciales
El perfil de los atacantes ha variado mucho desde que Internet y las redes de comunicaciones iniciaran sus pasos hace ya unos cuantos años. Se ha pasado de un atacante que buscaba notoriedad o el simple hecho de conseguir acceso a algo para lo que no disponía del mismo a empresas y organizaciones dedicadas al espionaje y al robo de información relevante (financiera, política, etc.). Así, grupos terroristas, agencias gubernamentales, estados, hackers, empleados disgustados, competidores, etc., pueden ser potenciales atacantes de nuestras redes.
Métodos básicos de ataque
Reconocimiento: Se trata de un técnica que busca descubrir información sobre la red atacada. Suele ser el primer paso que se da y en el que se obtienen parámetros básicos de la red: direccionamiento, hosts, tipo de tráfico, medidas de seguridad, etc.
Ingeniería social: Su objetivo es el usuario final de forma que obtengan información de él. El Phising, un enlace que parece el real pero que no lo es y que proporciona información al atacante y el Pharming, redirigir al usuario de una página válida a una que no lo es, son métodos de ingeniería social muy extendidos.
Escala de privilegios: Ir ganando privilegios de acceso a determinados servicios o sistemas.
Puertas traseras: Tanto el software como el hardware pueden tener fallos de diseño que permitan a un individuo acceder sin permiso a determinadas partes. Así mismo, terceras aplicaciones (Troyanos) abren puertas para que los atacantes accedan a los sistemas.
Debemos, pues, centrar nuestros esfuerzos en evitar que esos métodos puedan llevarse a cabo con éxito.
Una de las primeras cosas que debemos conocer cuando nos desenvolvemos en entornos de redes son las subredes.
Breve introducción.
En uno de los primeros capítulos sobre Redes, os explicaba el concepto de dirección IP y el de Clase de dirección. Por resumir un poco nos encontramos que cuando las redes de computadores se diseñaron se concibieron tres grandes grupos de IPs. Las de clase A, pocas, pero que serían capaces de albergar un número grande direcciones, las de clase B, en mayor número pero con menor número de direcciones y las de Clase C, las más extendidas, que dispondrían de un número bastante reducido de direcciones.
Con la popularización de las redes y la llegada de Internet pronto se observó que ese modelo era incompatible con el crecimiento de los equipos y las redes puesto que se asignaban grupos con un número fijo de direcciones (A,B,C) independientemente de la necesidad que tuviera cada empresa. Sin embargo, al estar ya establecido se antojaba complejo reestructurarlo. Por ello se decidió introducir un nuevo concepto, el de subredes.
Subnetting o el aprovechamiento máximo.
La idea se fundamenta en un nuevo concepto: la máscara de subred.
Este número, que al igual que las direcciones IP está compuesto de 4 grupos de números entre 0 y 255, es el patrón que se superpone a la dirección IP y nos indica qué parte es considerada «dirección de red» y qué parte es considerada «dirección del host».
Aclaremos un poco esto antes:
Supongamos que se nos asigna un número de dirección IP como el siguiente:
128.1.0.0
Esta dirección es de Clase B por lo que tiene asociadas 65.534 direcciones posibles: de la 128.1.0.1 a la 128.1.255.254 (recordad que ni la acabada en o, que es la dirección de red, ni la acabada en .255, la dirección de broadcast, pueden emplearse).
En este ejemplo queda bastante claro que la parte de dirección de red es: 128.1 mientras que la parte de dirección de host son los dos últimos octetos.
Pero qué sucede si no necesitamos más de 65.000 direcciones pero las 254 que nos ofrece la Clase C no son suficientes: aquí es donde nace el subnetting y el concepto de máscara de red.
De lo que se trata es de «alargar» la dirección de red aumentando así el número de posibles redes disminuyendo el número de direcciones de host asociadas.
Para ello añadiremos a la dirección de red la máscara: 128.1.0.0 255.255.128.0
La máscara de subred es, como he comentado antes, un patrón que se superpone a la dirección de red y que discrimina la parte de dirección de red de la parte de dirección de host. Para ello, en binario, si la máscara tiene un 1, el bit de la dirección de red se mantiene en su estado, si la máscara tiene un 0, el bit de la dirección de red pasa a 0 (operación binaria AND).
¿Qué hemos conseguido?
Al añadir esta máscara de subred nos encontramos con que pasamos de las 65.534 direcciones de host a la mitad: 32.767
¿Cómo es posible?
En el ejemplo inicial tanto la dirección 128.1.1.150 como la dirección 128.1.220.140 pertenecían al mismo rango: 128.1.0.0
Aplicando la máscara de su red, sin embargo, vemos que no es así:
En el caso de la dirección 128.1.1.150 255.255.128.0 , con una AND binaria tenemos que pertenece a la red: 128.1.0.0
En el caso de la dirección 128.1.220.140 255.255.128.0, obtenemos sin embargo que pertenece a la red: 128.1.128.0
Otras formas de mostrar la máscara de subred.
Comúnmente la máscara de subred no se muestra completa sino que se añade a la dirección de red como el número de 1 consecutivos que tiene la misma en binario.
En nuestro ejemplo, nuestra máscara 255.255.128.0 tiene 17 1 consecutivos por lo que la forma de representar la dirección sería: 128.1.0.0/17
Una de las herramientas que considero más interesantes a través de la red es el Escritorio Remoto.
Existen bastantes opciones para poder acceder a nuestro PC a través de Internet y poder así gestionar su funcionamiento de forma remota.
La más sencilla para los usuarios de sistemas operativos de Microsoft (Windows XP, Windows Vista, Windows 7 o Windows 8) es el acceso mediante la aplicación nativa «Remote Desktop» (RDP).
Mediante esta simple herramienta podremos, desde cualquier PC con conexión a Internet, conectarnos e iniciar sesión en nuestro ordenador.
No obstante, para ponerlo en marcha hay que realizar una serie de pasos previos que os quiero detallar brevemente.
Abriendo paso.
La mayoría de usuarios de Internet disponemos de un router que hace las tareas de modem en nuestra casa. Este equipo por una parte se encarga de ser la interfaz entre nuestra red Ethernet LAN y el acceso a Internet (ADSL, DOCSIS, etc.).
Generalmente estos equipos están configurados de manera que el tráfico desde nuestra red a Internet está permitido (y así podemos navegar sin problemas) pero todo el tráfico cuyo origen es externo está filtrado.
Esto es una medida de seguridad básica que evita problemas mayores. No obstante, para nuestro fin supone un obstáculo.
En la siguiente imagen os muestro cómo está, de forma esquemática, montada mi red de casa. Veréis que es algo muy simple. Lo que tenemos que hacer para empezar es configurar el equipo de acceso a Internet para que permita el flujo de tráfico entre Internet y nuestro PC en los puertos que emplea el protocolo RDP.
Para ello debemos partir de los siguientes supuestos:
Nuestro PC dispone de una IP configurada manualmente. Si lo configuramos mediante DCHP existe la posibilidad de que la configuración IP varíe y las reglas que vamos a introducir en el router son fijas e unívocas.
Tenemos acceso a la configuración PAT (Port Access Translation) de nuestro router. Existen equipos a los que no tenemos acceso o desconocemos cómo hacerlo. Os recomiendo que busquéis tutoriales específicos para vuestro equipo.
Disponemos de las versiones de Microsoft Windows que admiten Escritorio Remoto.
Una vez tenido en cuenta lo anterior debemos configurar el router para que permita el tráfico entre cualquier IP externa y nuestra IP local del PC (a partir de ahora IP_Local) en el puerto: 3389. Si necesitamos que sea otro puerto podremos cambiarlo de dos maneras:
Realizando una redirección de puertos en el propio router: cuando la petición se realice al puerto XX que el router la dirija a la IP_LOCAL:3389.
Cambiando la configuración del registro de Microsoft Windows indicando el puerto de escucha.
Con esta tarea completada con éxito tendremos vía libre para configurar nuestro sistema operativo.
Para ello deberemos seguir los siguientes pasos.
Configurando el Escritorio Remoto en Windows
Accederemos a la parte de Sistemas dentro de nuestro Panel de Control
Una vez allí buscaremos la «Configuración de Acceso Remoto»
Finalmente seleccionaremos en la ventana que nos aparece la opción de permitir conexiones desde ordenadores que utilicen cualquier versión de RDP.
Un último detalle importantísimo: el firewall de Windows. Aunque pensemos que tenemos vía libre, nuestro querido Microsoft Windows viene por defecto con su propio Firewall activado. Una de dos, o bien lo desactiváis (poco recomendado si no confiáis en la configuración de vuestra red) o bien añadís una regla por la que acepte las conexiones entrantes al puerto del RDP.
Con esto podréis acceder desde cualquier PC conectado a Internet a vuestra estación de trabajo e iniciar sesión en ella.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRejectRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.