viernes, 28 de julio de 2017

Error "server refused our key" cuando se utilizan llaves generadas con puttygen

- Luego de copiar la llave pública usando el botón "save public key" y subirla al servidor GNU/Linux, se genera el error "server refused our key" al tratar de autenticarse usando las llaves.

- Solución:

* Abrir puttygen nuevamente, ir a File / Load private key
* Copiar la llave pública (ctrl+A, ctrl+C) desde el recuadro que dice "Public Key for pasting into OpenSSH authorized_keys file"
* Pegar el texto del recuador en el archivo "authorized_keys" en el servidor GNU/Linux
* También es importante que el archivo authorized_keys y el directorio .ssh tengan los siguientes permisos:

chmod 600 ~/.ssh/autorized_keys
chmod 700 ~/.ssh

-  Luego de esto la autenticación debe funcionar. 

domingo, 9 de julio de 2017

Certificación VCP-NV, experiencia y recomendaciones.

Mi experiencia con VCP-NV

Recientemente aprobé el exámen VCP-NV de VMware. Este es un resúmen de mi experiencia y los recursos utilizados:

Recursos utilizados:

- Libro oficial de VMware Press: VCP6-NV Official Cert Guide (Exam #2V0-641). Tengo acceso al libro en formato digital (premium kit) y aunque el libro es para la versión anterior, la mayor parte del material sigue siendo relevante con excepción de las partes donde se habla de NSX-MH por ejemplo.
* Es importante leer al menos dos veces (y entender) los capítulos de switches lógicos, routers y los "packet walks".

- Guía de diseño de NSX: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf
* Esta guía se mete un poco más a profundidad, pero es importante repasar al menos los primeros cuatro capítulos.

- Guia de instalación de NSX: https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.2/nsx_62_install.pdf
* Es importante entender la secuencia de instalación en detalle, al menos repasar hasta la página 73, que cubre todo el proceso de instalación del producto.

- Guía de administración de NSX: https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.2/nsx_62_admin.pdf
En lo personal no hice una lectura sistemática, pero puede ser un buen material de referencia, especialmente los capítulos 1, 3, 6, 9, 10, 17, 21, 24.

- Laboratorios: http://labs.hol.vmware.com/HOL/catalogs/catalog/681
* Es fundamental estar familiarizado con la plataforma para pasar el exámen. Recomendaría intentar hacer un lab por cada uno de los tópicos, eso incluye, instalación, Logical Switches, Logical Routing (routing y L2 Bridges), Distributed Firewall, Edges (acá van VPNs, Load Balancer, Firewall, Routing).
* En lo personal utilicé mayormente los labs de HOL (1725 en especial) de VMware que son gratis y brindan una buena plataforma para practicar. Para la parte de instalación, tuve acceso a un lab en la nube y con eso pude familiarizarme con el proceso, pero si no se tiene acceso a esto, es posible utilizar el HOL 1725 y crear un cluster nuevo, para prepararlo para NSX por ejemplo. También es posible eliminar el registro entre NSX y vCenter para practiar ese procedimiento. Al final, si algo se daña es cuestión de crear un lab nuevo y listo.
* Es importante conocer las GUIs y los elementos de las mismas.

- Guía de Networking de VMware: https://docs.vmware.com/en/VMware-vSphere/6.0/vsphere-esxi-vcenter-server-602-networking-guide.pdf
* Hay que estar familiarizado con los conceptos de vDS y Standard Switch, diferencias entre los mismos, cómo se configura cada uno y en qué parte de la GUI. Recomendaría leer y comprender bien los capítulos del 1-5,7-9. En particular los detalles del vDS, SS y las políticas.
* Yo no leí todo este material (lo anterior es una referencia), pero utilicé el libro "Networking for vSphere Administrators" y labs para familiarizarme con la GUI y los features.

- Topics del examen: https://mylearn.vmware.com/mgrReg/plan.cfm?plan=95141&ui=www_cert
* Es importante revisar los topics y asegurarse de que se haya cubierto todo lo que piden. En mi experiencia, puedo decir que el libro de certificación oficial cubre bien los temas, pero hay que complementar con los materiales mencionados.

- Material adicional:
* https://blogs.vmware.com/management/2014/05/vcac-nsx-dynamically-configuring-application-specific-network-services.html
* Lab de vRealize Automation y NSX en HOL (HOL-1721-USE-2 -- Módulo 2). Es bueno hacer este lab al menos 2 veces. Hay que estar familiarizado con los conceptos de los "network profiles" que se utilizan.
* Videos : http://vmzone.com/study-guide/vcp-nv-nsx-study-guide/
Estos videos son algo viejos, pero pueden servir como referencia. No los vi todos, pero me fueron útiles en la parte de vRealize Automation (vCAC).
* Libro VPNs illustrated: En mi humilde opinión, el topic de "IPSec VPNs" en particular no viene bien explicado ni en el libro, ni en las guias, por lo que tuve que profundizar un poco leyendo este otro libro.

- Es importante saber los conceptos de Data Security, Flow Monitoring, Trace Flow, Activity Monitoring, cómo se usa cada uno, opciones de la GUI y demás. No pasen por alto ninguno de los objetivos del study guide.


- Exámenes de práctica de Pearson: http://www.pearsonitcertification.com/store/vcp6-nv-official-cert-guide-exam-2v0-641-9780789754806
Si compran la edición premium del libro van a tener acceso a 4 exámenes de práctica. Estos pueden servir como parámetro para identificar los temas donde haga falta profundizar más.

Se ve como si fuese mucho material, pero creo que es algo que se puede cubrir en 4 meses (o menos), dependiendo de la dedicación.

Finalmente, puedo decir que el tipo de preguntas es en su mayoría "justo", es decir, si se estudió a conciencia se puede responder bien, siempre hay que leer bien cada pregunta. Hay ocasiones en que la respuesta viene más por descarte que por otra cosa, no se frustren con eso, simplemente marquen las que no sepan (para revisarlas luego) y tengan buen manejo del tiempo. Son 77 preguntas en 120 minutos y es bueno dejar al menos 20 minutos al final del exámen para una revisión final. No se queden pegados en una sola pregunta por mucho tiempo. Es bueno concentrarse en una pregunta a la vez y olvidar un poco el "after exam" (que si paso, que si no, etc...), eso a veces provoca ansiedad y no permite concentrase bien. En lo personal no veo nada de malo con hacer un exámen 2 o 3 veces, siempre y cuando se aprenda. La certificación es un "by-product", lo importante es el crecimiento personal y profesional que se obtiene en el viaje. Suerte!

domingo, 18 de junio de 2017

Usando vmware hands on labs para probar un túnel IPSec en NSX

NOTAS:




1.   Se asume familiaridad con el entorno de VMware NSX, vSphere y edición de textos en GNU/Linux
2. Esta es una configuración con fines ilustrativos, no se asume responsabilidad alguna por su aplicación en ambientes de producción.


1. Acceder a VMware hol: labs.hol.vmware.com

     * Si no tiene cuenta, debe crear una, es gratis.

     * Si ya tiene cuenta, vaya a "All Labs" y coloque 1725 en la barra de búsqueda.

     * Enroll y luego Start para dar inicio al laboratorio

     * NOTA: en la parte superior derecha hay un botón de "Extend" que permite usar el lab por más de los 90 minutos iniciales.


2. Digrama que vamos a utilizar



VM_A-----LS_A-----EdgeA---------LS_Internet-------EdgeB-------------VM_B


IPs:


VM_A: 172.1.1.10/24

EdgeA IP Interna: 172.1.1.1/24

EdgeA IP Uplink: 15.15.15.1/24

EdgeB IP Uplink: 15.15.15.2/24

EdgeB IP Interna: 172.2.2.1/24

VM_B: 172.2.2.10


3. Preparar Infraestructura:


3.1 Clonar dos veces la VM llamada web-01a.corp.local, la primeva VM se va a llamar VM_A, la segunda VM_B.


3.2 Crear los switches lógicos: LS_1, LS_2 y LS_Internet (LS = Logical Switch)


3.3 Conectar las interfaces LAN de VM_A al LS_1 y la de VM_B al LS_2


3.4 Encender VM_A y VM_B


3.5 - Cambiar la IP de VM_A:


      - Acceder a la consola de VM_A

      - Ejecutar el comando "ip a", para detectar el nombre  de la interface de red, en mi caso aparece la loopback y eth1. NOTA: Abra un notepad y tome nota de la MAC asociada a eth1

      - Configurar la IP de eth1

            * cd /etc/sysconfig/network-scripts

            * cp ifcfg-eth0 ifcfg-eth1

            * vi ifcfg-eth1

                 * Dentro de vi, modificar lo que diga eth0 y dejarlo como eth1

                 * Cambiar la IP a 172.1.1.10 y el Gateway y DNS a 172.1.1.1 (Edge_A Interna)


                 * Cambiar la MAC para que coincida con el output de "ip a" para eth1


3.6  Cambiar la IP de VM_B: Repetir "3.5" para VM_B, en este caso use las IPs y la MAC correspondientes.


3.7 Crear los Edges:

     - Cree el Edge_A con las siguientes especificaciones:

          - Habilite SSH, Default Firewall Rule Action: Allow

          - Password: VMware1!Vmware1! (el password del edge debe ser de 12 dígitos al menos)

          - Interface interna: 172.1.1.1/24, conectada a LS_1

          - Interface externa: 15.15.15.1/24 conectada a LS_Internet

     - Cree el Edge_B con las siguientes especificaciones:

          - Habilite SSH, Default Firewall Rule Action: Allow

          - Password: VMware1!Vmware1! (el password del edge debe ser de 12 dígitos al menos)

          - Interface interna: 172.2.2.1/24, conectada a LS_1

          - Interface externa: 15.15.15.2/24 conectada a LS_Internet


3.8 Configure IPSec VPN en ambos Edges:


     - Vaya al Edge / Management / VPN

     - Habilite IPSec VPN

     - Agregue un nuevo VPN

     - Ejemplo de la config del lado A:




     * Publique los cambios


     - Ejemplo de config del lado B:





     * Publique los cambios


4.0  Verifique el status del tunel haciendo click en: "Show IPSec Statistic":

     - El status del tunel es "UP":





4. Pruebe la conectividad desde VM_A hasta VM_B, debería funcionar sin problemas.


5. Errores que tuve durante mi lab:


5.1 Para ver los logs del edge pueden ingresar al edge via CLI con el usuario "admin" y el password que configuraron (VMware1!Vmware1! en mi caso).   Una vez dentro de la consola, el comando "show log" despliega los logs del Edge, por defecto los logs se leen dentro de un "less" de GNU/linux, por lo que presionando G mayúscula podemos ir al final del archivo de logs.


5.2 NO_PROPOSAL_CHOSEN:




Cuando se habilita el tunel, el primer paso es enviar nuestro security proposal al otro lado, si hay algún parámetro diferente es porque la configuración de alguno de los dos lados tiene algún parámetro distinto. Vea las imágenes del punto 3.9, todo coincide. En mi caso, tenía DH5 del lado A y DH14 del lado B


5.3 INVALID_ID_INFORMATION



Esto sucede porque el "Local ID" del lado A no coincide con el "Peer ID" del lado B o viceversa. Si bien es cierto, en los IDs podemos utilizar lo que queramos, los valores tienen que coincidir a ambos lados del tunel.


Ya que tienen ese lab configurado, perfectamente lo pueden usar para probar OSPF o BGP, sólamente deshabilitan IPSec, configuran su protocolo de enrrutamiento y lo prueban. En mi caso, eso será para otro post.


      

domingo, 23 de abril de 2017

less GNU/Linux -- búsqueda case insensitive

Para que la búsqueda en less no discrimine entre mayúsculas y minúsculas se debe digitar "- i" y luego hacer la búsqueda.

sábado, 18 de marzo de 2017

Because Server Graphical Shell has been uninstalled, no Internet browser is available to display this document.


Because Server Graphical Shell has been uninstalled, no Internet browser is available to display this document.

Solución:

Add Roles and Features
Features
User Interfaces and Infrastructure: Habilitar Destkop Experience y Server Graphical Shell

domingo, 12 de marzo de 2017

Verificar que una llave privada pertenezca a un certificado

Con los siguientes comandos de openssl es posible obtener un hash  (del inglés "picadillo") md5 para determinar si la llave privada y el certificado van juntos:

openssl x509 -noout -modulus -in certificate.crt | openssl md5

(stdin)= d41d8cd98f00b204e9800998ecf8427e


openssl rsa -noout -modulus -in private.key | openssl md5


(stdin)= d41d8cd98f00b204e9800998ecf8427e


Pd. Si les interesa el tema del openssl, en el siguiente link hay un libro gratis y muy bueno:

https://www.feistyduck.com/books/openssl-cookbook/

Saludos hnos latinoamericanos!

domingo, 26 de junio de 2016

Marionnet - Simulador de redes open source - minitutorial para iniciar.



Se puede descargar una imagen de virtual box desde el link en la página de marionnet:


https://www.marionnet.org/site/index.php/en/documentation/quick-start

Nota: Es un archivo de 3 GB por lo que se recomienda descargarlo con algún gestor de descargas. En mi caso, utilicé "flareget"

Config inicial:

1. Se importa el appliance en virtual box
* el password del usuario user es user
* el password del usuario root es root
2. Se cambia  a usuario root con el comando: su -
3. Se cambia el idioma con el comando: dpkg-reconfigure locales
* Se debe quitar la opción de francia y dejarlo en inglés.
4. Se cambia la configuración del teclado con el comando: dpkg-reconfigure keyboard-configuration

5. Se reinicia la máquina virtual
6. Cuando inicia de nuevo, hacemos doble click en el ícono de "marionnet" en el escritorio.

7. Se crea un nuevo proyecto en "project"
8. Para agregar un switch hacemos click en el menú de switches (lado izquierdo) y seleccionamos"add":














* De igual forma agregamos al menos 2 computadoras

9. Se configuran las IPs, direcciones de broadcast y máscaras de subred para las dos máquinas que se agregaron. Esto se puede hacer en la línea de comandos de las VMs. o en la sección de interfaces, como se muestra en la siguiente imagen.:



10. Se selecciona la opción de cable "straight"  y se conenta la máquina m1 al puerto 1 del switch y la máquina m2 al puerto 2 del switch




 11 . Se accesa a la consola de la máquina m1 y debería ser posible hacer ping a la máquina m2.






























Provecho!