Migración-de-servidor-OpenVPN-desde-Debian-Stretch-a-Buster.md

@@ -26,7 +26,7 @@ El servidor OpenVPN en producción se encuentra en un host independiente (conten
 
 Lo único que es necesario respaldar del contenedor a destruir para recuperar en el nuevo, son las claves criptográficas del servidor y de los clientes. Esto con el objetivo de que la migración sea invisible para los usuarios. Bien podrían generarse llaves nuevas para todos los usuarios y distribuirlas a sus propietarios para que reconfiguren sus clientes.
 
-Adicionalmente al respaldo, tal como se comentaba en la introducción, será necesario reestructurar el árbol de directorios para hacerlp compatible con la nueva estructura. Vamos a ello.
+Adicionalmente al respaldo, tal como se comentaba en la introducción, será necesario reestructurar el árbol de directorios para hacerlo compatible con la nueva estructura. Vamos a ello.
 
 
 ### Respaldo y reestructuración de claves
@@ -153,7 +153,7 @@ Ejecutando la nueva versión del role (que emplea Easy-RSA 3.X en lugar de la 2.
 
 > Es importante destacar que en ambos casos los archivos `.zip` son generados automáticamente por el role para cada usuario a partir de sus `.crt`, `.key`, `.ovpn` más el `ca.crt` y `ta.key` del servidor.
 
-A simple vista se observa que el mayor cambio de la nueva estructura, es el aumento de segmentación por tipo de archivo uitilizando nuevos directorios. Para adaptar esto bastará simplemente con crear los nuevos directorios y mover los archivos a sus nuevas ubicaciones.
+A simple vista se observa que el mayor cambio de la nueva estructura, es el aumento de segmentación por tipo de archivo utilizando nuevos directorios. Para adaptar esto bastará simplemente con crear los nuevos directorios y mover los archivos a sus nuevas ubicaciones.
 
 Sin embargo, hay un cambio fundamental que tal vez no es tan perceptible: ahora los certificados `.pem` no se nombran con una secuencia hexadecimal de 2 dígitos sino de 32. Además, esos nombres son referenciados en el archivo `index.txt`, por lo que también será necesario actualizarlo
 
@@ -275,7 +275,7 @@ Concluída la reestructuración, el resultado final luce así:
         └── ta.key
 ```
 
-> Podemos probar que todo resultó correctamente, sobreescribiendo el contendido de  `/etc/openvpn` del servidor de *staging* con el de `~/reestructura` y comprobar que un cliente puede conectarse satisfactoriamente a este servidor utilizando sus llaves de producción
+> Podemos probar que todo resultó correctamente, sobrescribiendo el contendido de  `/etc/openvpn` del servidor de *staging* con el de `~/reestructura` y comprobar que un cliente puede conectarse satisfactoriamente a este servidor utilizando sus llaves de producción
 
 Con todo listo, solo queda recrear el nuevo servidor sobre un nuevo template de Debian Buster. De momento utilizaremos la [v2.0.0-udelarinterior.rc0](https://github.com/UdelaRInterior/Stouts.openvpn/tree/v2.0.0-udelarinterior.rc0) de nuestro role (mientras la proposiciones no sean fusionadas en el *upstream*) y los *playbook* desde la rama correspondiente de ***config*** para atender la tarea de migración de OpenVPN.