Entendiendo La Cabecera IP en 21 segundos

Aunque ya estamos a puertas de usar la IPv6, faltará un poquito para que esto se extienda, así que seguiremos estudiando por unos años más el viejo y robusto IPv4.
Porque todos hemos oído hablar de este protocolo pero no muchos nos hemos dignado en indagar en su interior.
#################################################################################

0                                   15 16                                   31
.____________________________________________________________________________.___
| 4-bit  | 4-bit   |      8-bit       |              16-bit                  | |
|version |long.cab.|tipo de serv.(TOS)|  longitud total en bytes             | |
|________|_________|__________________|______________________________________| |
|           16-bit                    | 3-bit |         13-bit               | |
|       identificacion                | flags |   offset de fragmentos       | |
|_____________________________________|_______|______________________________|20 bytes
|     8-bit        |     8-bit        |             16-bit                   | |
|time-to-live(TTL) |  protocolo       |      chequeo cabecera                | |
|__________________|__________________|______________________________________| |
|                             32-bit                                         | |
|                        direccion IP origen                                 | |
|____________________________________________________________________________| |
|                             32-bit                                         | |
|                        direccion IP destino                                | |
|____________________________________________________________________________|_|_
|                           opciones                                         |
/                        (si las hubiere)                                    /
|____________________________________________________________________________|
|                                                                            |
|                           DATOS                                            |
|                                                                            |
/                                                                            /
|                                                                            |
|____________________________________________________________________________|

##################################################################################

-Version: hoy dia suele ser la 4 si es que es ipv4
-Longitud de cabecera: el limite es 60bytes (tb sirve para especificar si hay opciones)
-TOS: flags para darle luz o no a los datagramas: minimize delay, maximize throughput,
maximize reliability, y minimize monetary cost
-Longitud total: siendo un campo de 16 bits se deduce que el tamaño máximo de
un datagrama IP seria 65535. Aunque esto se suele fragmentar.
-Identificacion: un numero que identifica el paquete enviado (incremental)
-Flags
-Offset fragmentos: para cuando se fragmenta el datagrama.
-TTL: el tiempo de vida del datagrama. Para que no ande vagando eternamente
-Protocolo: TCP, UDP, IGMP, ICMP
-Chequeo cabecera: para la validacion de que los datos son correctos
-Direccion origen: Ip de origen
-Direccion destino: IP de destino
-Opciones: valores opcionales, seguridad, timestamp, registro de rutas...

Resumido para ser entendido, captado y retenido en tan solo 21 segundos.

Saludos Cordiales;


Fuente: http://es.wikipedia.org/wiki/Cabecera_IP

Creando máquinas virtuales desde consola en servidor

Estimados;
Hoy presento un tema que me parece muy interesante y que me propongo a compartirlo. Se trata de optimizar recursos de hardware físico implementando máquinas virtuales dentro de nuestro servidor host.

Ha estas alturas todos sabemos que es una máquina virtual, softwares que emulan por hardware, etc, así que no detallaré los conceptos.

Ahora nos proponemos a aprovechar al máximo los recursos de nuestra PC para poder crear dentro de ella varias máquinas virtuales que se encarguen de gestionar diferentes servicios como si tuvieramos tantos servidores físicos como máquinas virtuales dispongamos. Esto es muy apreciable porque la carga que gestiona una máquina virtual no influye en el rendimiento de las otras y sólo depende de la potencia del equipo físico en el que se hospedan las mismas. Así que si deseamos tener varias máquinas virtuales gestionando diferentes servicios les recomiendo que la PC sea de muy buenas características tanto en procesador como en memoria RAM.

Bien, existen muchos softwares que sirven para nuestro fin como VMWare; VirtualPC, Qemu, KVM, OpenVZ, Xen, Virtualbox, todos ellos con sus ventajas y desventajas que tampoco detallaré en este tutorial.

Voy a usar virtualbox para tal fin ya que no pide mucho equipo para poder trabajar a comparación de VMWare.

La particularidad del presente trabajo es que todo lo haremos desde línea de comandos ya que suponemos que el SO host no tiene interfaz gráfica y sólo a se a instalado lo mínimo para que inicie el servidor.

Empecemos:

1. Instalando Virtualbox desde consola:

primero descargamos virtualbox. En mi caso yo uso Debian Squeeze 64 bits
zatoo@pruebas:~# wget http://download.virtualbox.org/virtualbox/4.1.6/virtualbox-4.1_4.1.6-74713~Debian~squeeze_amd64.deb

luego instalamos:

zatoo@pruebas:~# dpkg -i virtualbox-4.1_4.1.6-74713~Debian~squeeze_amd64.deb

Resolvemos las dependencias y listo, ya tenemos instalado virtualbox en nuestro servidor. Reiniciamos y listo.

luego instalamos el paquete extension_pack de virtualbox:

zatoo@pruebas:~# wget http://download.virtualbox.org/virtualbox/4.0.6/Oracle_VM_VirtualBox_Extension_Pack-4.0.6-71344.vbox-extpack && VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.0.6-71344.vbox-extpack

2. Creando máquinas virtuales desde línea de comandos

Consultando con el archivo de ayuda de virtualbox (man virtualbox) explica clara y detalladamente todos los comandos que maneja virtualbox.

Vamos a crear una máquina virtual que sea servidor web y que se llame www.mipc.com

zatoo@pruebas:~# VBoxManage createvm --name "www.mipc.com" --register

luego le asignaremos memoria RAM de 128 y le diremos que booteará desde el dvd virtual, le asignaremos su interfaz de red en modo bridge y utilizará la interfaz eth0 del SO host.

zatoo@pruebas:~# VBoxManage modifyvm "www.mipc.com" --memory 128 --acpi on --boot1 dvd --nic1 bridged --bridgeadapter1 eth0

luego crearemos un disco duro virtual donde instalaremos el SO hueped cuyo nombre será www_mipc_com.vdi y tendrá un tamaño máximo de 8gb incrementándose dinámicamente:

zatoo@pruebas:~# VBoxManage createhd --filename www_mipc_com.vdi --size 8000

luego creamos los controladores que manejarán al dvd y al disco duro virtual de la máquina virtual www.mipc.com:

zatoo@pruebas:~# VBoxManage storagect1 "ww.mipc.com" --name "IDE Controller" --add ide

luego asociamos el disco duro creado www_mipc_com.vdi a la máquina virtual creada www.mipc.com:

zatoo@pruebas:~# VBoxManage storageattach "ww.mipc.com" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium www_mipc_com.vdi

y también asociamos una imagen del SO que se quiere instalar(la imagen es de debian6.0.3.iso que se encuentra el /root) al dvd virtual para poder instalarlo en la máquina virtual www.mipc.com:

zatoo@pruebas:~# VBoxManage storageattach "www.mipc.com" --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /root/debian-6.0.3.1-amd64-CD-1.iso

Y con esto ya podemos iniciar la instalación del SO debian huésped en el SO host.

zatoo@pruebas:~# VBoxHeadless --startvm www.mipc.com

Ésto por default iniciará la máquina virtual en segundo plano en el puerto TCP 3389; así que desde cualquier cliente de sesiones remotas como el mstsc.exe (escritorio remoto de windows) o el grdesktop de debian podemos ingresar a la máquina virtual colocando la IP del servidor físico real y el puerto 3389 en donde está escuchando la máquina virtual: Así como en la figura:

Una vez instalado el SO huésped en la máquina virtual huésped dentro del servidor vamos a modificar el orden de booteo de la mencionada máquina para que cuando inicie ya no lo haga desde el cd sino directamente desde hard disk:

zatoo@pruebas:~# VBoxManage modifyvm "www.mipc.com" --acpi on --boot1 disk

Ahora, si queremos instalar más de una máquina virtual tendremos que seguir los mismos pasos anteriormente descritos. La diferencia radica a la hora de iniciar la máquina virtual. Como la primera máquina se encuentra levantada y conectada a través del puerto 3389 TCP, la nueva máquina virtual tendría que escuchar en un puerto diferente, por lo que el comando para que inicie en un puerto diferente por ejemplo el puerto 20000 TCP sería:

zatoo@pruebas:~# VBoxHeadless --startvm www.mipc.com -e "TCP/Ports=20000"

entonces cuando iniciemos sesión desde un cliente de escritorio remoto tendríamos que colocar IP:20000

Ahora, cuando ejecutamos el comando anterior iniciamos la máquina virtual pero vemos que la consola se queda ahí y no lo pasa a segundo plano, y si hacemos Ctrl C para escapar, la máquina virtual iniciada se apaga. Entonces para evitar esto y poder iniciar varias sesiones si estar abriendo varias terminales igresamos lo sgte:

zatoo@pruebas:~# nohup VBoxHeadless --startvm www.mipc.com -e "TCP/Ports=20000" --vrdp on &

Con esto hemos podido iniciar una máquina virtual en un entorno donde no hay interfaz gráfica debido a su condición de servidor donde lo que se requiere es iniciar con lo más mínimo y así tener los recursos disponibles para lo que verdaderamente importa.

Espero que esto les sirva porque ya en adelante empezaremos a implementar servicios como DNS, Web, Correo, LDAP, SAMBA, Mensajeria Instantánea con Openfire, etc y lo haremos en estas máquinas virtuales que hemos creado.

Características del Servidor Físico Real:

- Placa Intel DG41PR

- Procesador Intel Core 2 Quad 2.66 GHZ

- Memoria RAM 4GB 800MHZ

- Disco Duro 250 GB Sata

- Quemador DVD

- Fuente de 450 Watts uATX

Fuente: http://www.virtualbox.org/manual/ch08.html

OpenSSL: Autogestionando nuestros propios certificados

Estimados; ahora vamos a ver como podemos gestionar certificados digitales con la finalidad de proveer de seguridad a nuestros futuros servicios que vayamos habilitando ya sea web, Base de datos, correo, Mensajería Instantánea, controlador de dominio, etc.
Debemos tener en claro conceptos como: entidad certificadora CA; petición de certificado; llave o key y certificado; conceptos que no voy a dar ya que hay definiciones muy buenas, claras y sencillas andando por san google. Ejm: http://es.wikipedia.org/wiki/Autoridad_de_certificación.
En el ámbito de seguridad existe una herramienta que usa algoritmos específicos para crear certificados digitales únicos para cada petición de certificado, esto quiere decir que es imposible que dos certificados generados puedan contener la misma clave con la que fue generada. Esta herramienta se llama OpenSSL que nació de la descontinuación de SSLeay porque sus creadores pasaron a chambear a diferentes empresas de seguridad pero dejaron el código fuente a la comunidad para que lo explote.

Para empezar necesitamos una CA y ya que no tenemos platita para comprar alguna comercial porque todo esto es una enseñanza, nosotros seremos nuestra propia CA. Debemos entonces generarnos nuestros propios certificados de nuestra propia CA no oficial. La desventaja de esto es que ningún navegador nos reconocerá como tal y nos pedirá confirmar cada vez ya que nuestro certificado no es reconocido o no se encuentra en su base de datos.

Instalaremos OpenSSL en nuestro debian (en mi caso es squeeze de 64bits):

root@pruebas:~# aptitude install openssl

Luego creamos una carpeta personalizada donde pondremos nuestros certificados y las llaves. En mi caso:
root@pruebas:~# mkdir EntidadCA

Luego dentro de ella creamos el archivo openssl.conf que es donde se guardarán las configuraciones personalizadas para nuestro caso:
root@pruebas:~# cd EntidadCA/ && touch openssl.conf

Y dentro de openssl.conf copiamos este contenido para que lo personalicen a su conveniencia:
###Esto es una personalización hecha por mì: JPC del archivo original ###ubicado en /etc/openssl/openssl.cnf

dir            = .     # variable que establece el directorio de trabajo
[ ca ]
default_ca     = CA_default
[ CA_default ]
serial         = $dir/serial             # archivo que guarda el siguiente número de serie
database       = $dir/index.txt          # archvio que guarda la bd de certificados
new_certs_dir =  $dir/certificados       # dir que guarda los certificados generados
certificate    = $dir/CACert.pem         # nombre del archivo del certificado raíz
private_key    = $dir/privado/CAkey.pem    # llave privada del certificado raíz
default_md     = md5                     # algoritmo de dispersión usado
preserve  = no  #Indica si se preserva o no el orden de los campos del DN cuando se pasa a los certs.
nameopt        = default_ca    # esta opcion y la siguiente permiten mostrar detalles del certificado
certopt        = default_ca
policy         = policy_match    # indica el nombre de la seccion donde se especifica que campos son obligatorios, opcionales y cuales deben ser iguales al certificado raíz
# seccion de politicas para la emision de certificados
[ policy_match ]
countryName                    = match           # match, obligatorio
stateOrProvinceName            = match
organizationName               = match
organizationalUnitName         = optional        # optional, campo opcional
commonName                     = supplied        # supplied, debe estar en la petición
emailAddress                   = optional
# seccion que indica   como los certificados deben ser creados
[ req ]
default_bits         = 1024            # tamaño de la llave, si no se indica 512
default_keyfile      = key.pem         # nombre de la llave privada
default_md           = md5             # algoritmo de dispersión a utilizar
string_mask          = nombstr         # caracteres permitidos en la mascara de la llave
distinguished_name =   req_distinguished_name # seccion para el nombre distinguido (DN)
req_extensions     = v3_req # seccion con mas extensiones que se añaden a la peticion del certificado
# seccion del nombre distinguido, el valor es el prompt que se vera en pantalla. datos del propietario del certificado. esta seccion define el contenido de datos de id que el certificado llevara.
[ req_distinguished_name ]
0.organizationName             = Nombre de la organizacion Ejemplo: Mi Empresa S.A.A
organizationalUnitName         = Departamento o division
emailAddress                   = Correo electronico
emailAddress_max               = 40
localityName                   = Ciudad o distrito Ejemplo: LIMA
stateOrProvinceName            = Estado o provincia Ejemplo: PERU
countryName                    = Codigo del pais (dos letras) Ejemplo: PE
countryName_min                = 2
countryName_max                = 2
commonName                     = Nombre comun (hostname o IP) Ejemplo: midominio.com
commonName_max                 = 64
# si en la linea de comandos se indica la opcion -x509, las siguientes extensiones tambien aplican
[ v3_ca ]
# indica que se trata de un certificado CA raíz con autoridad para firmar o revocar otros certificados
basicConstraints         = CA:TRUE
# especifica bajo que metodo identificar a la llave publica que sera certificada
subjectKeyIdentifier     = hash
# especifica como identifcar la llave publica
authorityKeyIdentifier = keyid:always,issuer:always
# extensiones de la opcion req
[ v3_req ]
basicConstraints               = CA:FALSE # los certificados firmados no son CA
subjectKeyIdentifier           = hash
# *************************************************************************************

Luego creamos una carpeta donde guardar los certificados creados y otra donde guardar las llaves creadas privadas.
root@pruebas:~# mkdir certificados privado && echo '01' > serial && touch index.txt
El primer archivo 'serial' simplemente contiene el siguiente número de serie de nuestros certificados, ya que apenas vamos a crear el primero su número de serie será 01, después de crearlo se actualizará a 02 y asi sucesivamente.'index.txt' será la base de datos propiamente en base al número de serie.
Quedàndonos así:

root@pruebas:~/EntidadCA# ls -l
total 16
drwxr-xr-x 2     root root   4096 nov 14 02:26 certificados
- rw-r--r--    1    root root       0    nov 14 02:26 index.txt
 -rw-r--r--    1    root root    3841 nov 14 01:58 openssl.conf
drwxr-xr-x 2     root root   4096 nov 14 02:26 privado
- rw-r--r--    1    root root      3    nov 14 02:26 serial


Creando Una CA (recuerden cambiar los datos por los suyos)

root@pruebas:~/EntidadCA# openssl req -new -x509 -extensions v3_ca -keyout privado/CAkey.pem -out CAcert.pem -days 365 -config ./openssl.conf
(Ojo!: al principio nos pedirà una pass phrase: que no es otra cosa que una frase cualquiera que nosotros elijamos; por ejm. 4rr1b4 P3rU)
Generating a 1024 bit RSA private key
...++++++
..........................++++++
writing new private key to 'privado/CAkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Nombre de la organizacion Ejemplo: Mi Empresa S.A.A []:MIPC S.A.C
Departamento o division []:Departamento TI
Correo electronico []:admin@mipc.com
Ciudad o distrito Ejemplo: LIMA []:LIMA
Estado o provincia Ejemplo: PERU []:PERU
Codigo del pais (dos letras) Ejemplo: PE []:PE
Nombre comun (hostname o IP) Ejemplo: midominio.com []:mipc.com

y pasamos a explicar que significa cada paso:
a. req -new -x509   ---> crear un certificado nuevo autofirmado con el standar x509 (http://es.wikipedia.org/wiki/X.509)

b. -extensions v3_ca ---> crear un certificado raíz CA (como lo configuramos en el openssl.conf)

c.  -keyout  ---> nombre y donde guardará la llave privada (en este caso se guarda en privados

d. -out   ---> nombre del certificado raíz CA

e. -days 365 ---> el certificado será válido por 365 días (1 año)

f.  -config ---> archivo de configuración a utilizar (el que describimos openssl.conf

Lo anterior da por resultado dos archivos:
   Un certificado raíz CA (CAcert.pem)
   Una llave privada (privado/CAkey.pem) (La extensión "pem" es de Privacy Enhanced Message)

Solicitando un firmado de certificado

Si llegamos a este punto entonces ya nos hemos convertido en una entidad certificadora, claro sin más autoridad que para nuestro propio dominio, ahora crearemos una peticiòn de que nos firmen nuestro certificado para nuestro servicio.
root@pruebas:~/EntidadCA# openssl req -new -nodes -out solicitud.pem -config ./openssl.conf

Generating a 1024 bit RSA private key
..............................++++++
................................++++++
writing new private key to 'key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Nombre de la organizacion Ejemplo: Mi Empresa S.A.A []:MIPC S.A.C
Departamento o division []:Departamento TI
Correo electronico []:admin@mipc.com
Ciudad o distrito Ejemplo: LIMA []:LIMA
Estado o provincia Ejemplo: PERU []:PERU
Codigo del pais (dos letras) Ejemplo: PE []:PE
Nombre comun (hostname o IP) Ejemplo: midominio.com []:mipc.com

Llegado a este punto abremos creado la peticion "solicitud.pem" de firma de nuestro certificado el cual usaremos con nuestro CA para crear el certificado que estamos pidiendo.

Firmando nuestra petición de Certificado.

Por último firmaremos la solicitud que hicimos en el paso previo, para firmarlo necesitaremos indicar la contraseña que autentifique que
somos la CA y que que por serlo tenemos la autoridad de autorizar (firmar) certificados. (Para nuestro propio uso).

root@pruebas:~/EntidadCA# openssl ca -out cert-firmado.pem -config ./openssl.conf -days 365 -infiles solicitud.pem
(ojo! nos pedirá la misma pass phrase que colocamos antes. ejm: 4rr1b4 P3rU
Using configuration from ./openssl.conf
Enter pass phrase for ./privado/CAkey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
organizationName      :PRINTABLE:'MIPC S.A.C'
organizationalUnitName:PRINTABLE:'Departamento TI'
emailAddress          :IA5STRING:'admin@mipc.com'
localityName          :PRINTABLE:'LIMA'
stateOrProvinceName   :PRINTABLE:'PERU'
countryName           :PRINTABLE:'PE'
commonName            :PRINTABLE:'mipc.com'
Certificate is to be certified until Nov 14 05:12:33 2012 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Como ven en el gràfico, se ha creado satisfactoriamente el certificado autofirmado para nuestro dominio.

root@pruebas:~/EntidadCA# cat cert-firmado.pem
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: O=MIPC S.A.C, OU=Departamento TI/emailAddress=admin@mipc.com, L=LIMA, ST=PERU, C=PE, CN=mipc.com
        Validity
            Not Before: Nov 15 05:12:33 2011 GMT
            Not After : Nov 14 05:12:33 2012 GMT
        Subject: C=PE, ST=PERU, O=MIPC S.A.C, OU=Departamento TI, CN=mipc.com/emailAddress=admin@mipc.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:a5:00:94:13:3e:52:64:7b:17:76:0c:11:4b:5b:
                    b9:c8:55:96:34:9f:18:6c:31:69:23:29:e6:b4:15:
                    38:ca:69:de:78:6a:bc:d8:9c:d6:11:28:b0:1e:ae:
                    85:0c:40:59:36:ce:8c:ff:5c:af:00:e1:cd:d6:53:
                    ca:e3:d3:e8:a7:1b:05:bb:a5:db:7a:01:c7:b0:29:
                    2b:ba:29:a2:24:cb:6e:b1:8b:57:e0:0a:d1:b4:53:
                    47:50:60:8b:d9:3e:49:4c:cf:8a:64:fc:ea:d2:6e:
                    e4:3e:1b:55:53:8e:0c:9f:7f:14:d7:d7:61:30:83:
                    53:38:3e:92:e9:ee:e9:75:03
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
        57:0b:ce:d3:57:73:6e:58:36:a8:ea:be:3a:5b:ad:1a:36:3c:
        23:28:09:e2:f7:cb:4a:f7:42:d0:f3:25:78:76:8e:78:a3:2d:
        87:3b:9e:e8:6e:8c:77:76:61:62:ca:ca:9e:bd:57:e0:ac:71:
        15:ab:37:b1:8b:bf:fa:35:66:f4:d5:76:38:52:48:34:51:14:
        94:e3:a2:c0:e9:f8:3d:68:d6:3a:5d:66:25:93:7c:ee:b2:7f:
        3a:0c:dd:a1:a8:91:50:9b:ee:e2:1e:28:83:65:a1:83:af:df:
        90:89:d1:ef:2e:c9:6c:6a:81:25:a4:3b:58:e4:b7:fe:66:fb:
        94:3c
-----BEGIN CERTIFICATE-----
MIICeTCCAeICAQEwDQYJKoZIhvcNAQEEBQAwgYwxEzARBgNVBAoTCk1JUEMgUy5B
LkMxGDAWBgNVBAsTD0RlcGFydGFtZW50byBUSTEdMBsGCSqGSIb3DQEJARYOYWRt
aW5AbWlwYy5jb20xDTALBgNVBAcTBExJTUExDTALBgNVBAgTBFBFUlUxCzAJBgNV
BAYTAlBFMREwDwYDVQQDEwhtaXBjLmNvbTAeFw0xMTExMTUwNTEyMzNaFw0xMjEx
MTQwNTEyMzNaMH0xCzAJBgNVBAYTAlBFMQ0wCwYDVQQIEwRQRVJVMRMwEQYDVQQK
EwpNSVBDIFMuQS5DMRgwFgYDVQQLEw9EZXBhcnRhbWVudG8gVEkxETAPBgNVBAMT
CG1pcGMuY29tMR0wGwYJKoZIhvcNAQkBFg5hZG1pbkBtaXBjLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApQCUEz5SZHsXdgwRS1u5yFWWNJ8YbDFpIynm
tBU4ymneeGq82JzWESiwHq6FDEBZNs6M/1yvAOHN1lPK49PopxsFu6XbegHHsCkr
uimiJMtusYtX4ArRtFNHUGCL2T5JTM+KZPzq0m7kPhtVU44Mn38U19dhMINTOD6S
6e7pdQMCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBXC87TV3NuWDao6r46W60aNjwj
KAni98tK90LQ8yV4do54oy2HO57obox3dmFiysqevVfgrHEVqzexi7/6NWb01XY4
Ukg0URSU46LA6fg9aNY6XWYlk3zusn86DN2hqJFQm+7iHiiDZaGDr9+QidHvLsls
aoElpDtY5Lf+ZvuUPA==
-----END CERTIFICATE-----
root@pruebas:~/EntidadCA#

Entonces ahora ya disponemos de CACert.pem que lo podemos importar desde los navegadores de las pcs de los usuarios de nuestra red que administramos cosa que asì el navegador no estarà mostrando ese molestoso mensaje que nos indica que no es una conexiòn segura. Y disponemos de cert-firmado.pem que junto a CACert.pem lo podemos configurar en nuestros servidores que administremos y asì les abremos dotado de seguridad aunque sea de manera local.

Reforzando conceptos - Parte II: Modelo TCP/IP

Estimados, siguiendo el "remember" que me propuse en: Reforzando conceptos - Parte I: Modelo OSI / ISO, es que les traigo esta segunda entrega muy resumida y en criollo (como se dice aquí en Perú) para que se entienda y así poder tener los conceptos claros.
Recuerden que la práctica debe ser respalda por una sólida base teórica y no quedar como "empíricos amateurs".

Empecemos

La familia de protocolos TCP / IP está estructurada como una jerarquía de cinco niveles. A veces se refiere colectivamente como una pila de protocolos. Este esquema arquitectónico ofrece las siguientes ventajas:
- Cada capa está diseñada para un propósito específico y existe tanto en el envío y recepción que se dá entre hosts.
- Cada capa está diseñada para que una capa específica en un host envía o recibe exactamente el mismo objeto enviado o recibido por sus respectivo proceso en otro host.
- Cada capa en un host actúa con independencia de otras capas del mismo host, y de acuerdo con la misma capa en otros sistemas.

Para tener una idea comparativa entre TCP/IP y OSI les dejo el siguiente gráfico:

Figura 1: Modelo TCP/IP

CAPAS DEL MODELO TCP/IP	CARACTERÍSTICAS
APPLICATION LAYER (CAPA DE APLICACIÓN)	Involucra las capas Aplicación, Presentación y Sesión del Modelo OSI. Consiste en acceder a los programas y servicios de red por el usuario. Es responsable de definir la forma en que las redes representan los datos. Un gateway funciona en esta capa.
TRANSPORT LAYER (CAPA DE TRANSPORTE)	Gestiona la transferencia de datos utilizando protocolos  de transporte reconocidas y no reconocidas. Esta capa también gestiona las conexiones entre las aplicaciones.
INTERNET LAYER (CAPA DE INTERNET)	Gestiona los datos y direcciones y entrega entre redes. Así como los datos de la fragmentación de la capa de Interfaz de red. Un router funciona en esta capa.
NETWORK INTERFACE LAYER (CAPA DE INTERFAZ DE RED)	Administra la entrega de los datos en la capa de Hardware. Esta capa provee la detección de errores y fragmentación de paquetes. Un “bridge” funciona en esta capa.
HARDWARE LAYER	Describe el equipamiento de la red, incluyendo las señales eléctricas características como el voltaje y la corriente. Un repetidor funciona en esta capa.

Deacuerdo a la descripción, se puede apreciar que el modelo TCP / IP es un formato reducido del Modelo OSI, ya que ha mezclado algunas capas de este último.

Espero les haya quedado claro este ligero resumen. Lo que quisiera lograr es que se sepa qué involucra cada capa y qué función desempeña.

Reforzando conceptos - Parte I: Modelo OSI / ISO

Muchos conceptos se han quedado en el olvido o simplemente se pasan por alto al momento de entrar en el mundo de las redes y servidores en general lo que tenga que ver con la teleinformática. Algunos empiezan a manera de hobbie, por curiosidad, por casualidad, como algunos efectivamente recibieron instrucciones y guías que decidieron enfocarse por este camino. Uno de esos conceptos pasados por alto es: El Modelo OSI, muchos sabemos como levantar un servidor, armar una red con seguridad perimetral, etc, pero si nos preguntan: y en que capa del modelo OSI trabaja el protocolo UDP; o que en capa se encuentra el servicio HTTP, FTP, POP, o por que capa viaja la trama que enviamos de host a host, etc. no sabemos responder, respondemos otra cosa, o simplemente nos quedamos mudos. Es por ello que he decidido hacer una pausa y "refrescar la memoria" porque estoy seguro que más de uno lo ha escuchado, lo ha leído, o por lo menos ha oído hablar del tema.

Empecemos
Network Model: Representa una estructura común o protocolo que involucra la comunicación entre sistemas. Estos modelos son divididos en capas.
El Modelo OSI (Open Systems Interconnection) nació en 1980 de manos de la International Organization for Standarization (ISO) con la finalidad de brindar funcionalidad a las necesidades de comunicación entre los equipos de las diferentes empresas fabricantes que hasta ese entonces era difícil unirlas.
Así fue concebido en 7 capas que muestro en el siguiente gráfico:

Figura 1: Estructura en capas del Modelo OSI

Figura 2: Resumen de capas

Espero les haya quedado claro los conceptos de esto que es muy importante. Posteriormente prepararé la parte 2 que se trata del Modelo TCP/IP, lo compararemos con el Modelo OSI y veremos las principales diferencias.


Lectura Recomendada: The Solaris - TCP/IP Network Administration