Categoría: Sistemas

  • Proyecto: Operación HAWKINS

    Proyecto: Operación HAWKINS

    Diseño de una infraestructura empresarial con VLSM y servicios de red

    1. Introducción

    Audio presentación

    El Centro de Investigación Avanzada de Hawkins es una organización ficticia inspirada en la serie Stranger Things. Tras varios incidentes en sus instalaciones, la dirección ha decidido sustituir su red improvisada por una infraestructura profesional, segmentada, documentada y preparada para crecer.

    El centro está formado por tres ubicaciones:

    • Sede Central de Hawkins: oficinas, laboratorios, seguridad, servidores y zona de visitantes.
    • Estación de Campo Starcourt: pequeño centro remoto de observación y comunicaciones.
    • Búnker NINA: instalación aislada en la que se realizan pruebas especialmente sensibles.

    Vuestro equipo ha sido contratado como consultora de sistemas y redes. Tendréis que analizar las necesidades de la organización, diseñar el direccionamiento mediante VLSM, construir una maqueta funcional y desplegar varios servicios de red.

    No se valorará únicamente que los equipos puedan comunicarse. La empresa exige una solución lógica, segura, ampliable, comprobada y correctamente documentada.


    2. Modalidad de trabajo

    • Trabajo individual o en parejas, según indique el profesor.
    • Herramienta principal recomendada: Cisco Packet Tracer.
    • Red IPv4 asignada a todo el proyecto: 172.20.0.0/16.
    • Todos los cálculos de subnetting deberán realizarse manualmente y explicarse además de mostrar las tablas completas.
    • En Packet Tracer no es necesario colocar físicamente todos los dispositivos indicados. Se representará cada red con un número reducido de equipos, pero el direccionamiento deberá admitir la cantidad real solicitada.
    • No es necesario realizar la configuración en los routers y switch, aunque si debe estar bien explicado en la documentación.

    3. Objetivos de aprendizaje

    Al terminar el proyecto, el alumnado deberá ser capaz de:

    1. Analizar las necesidades de una infraestructura con varias sedes.
    2. Crear subredes de distinto tamaño mediante VLSM.
    3. Calcular direcciones de red, broadcast, rangos utilizables y máscaras.
    4. Organizar departamentos mediante redes o VLAN independientes.
    5. Configurar direccionamiento estático y dinámico.
    6. Permitir la comunicación entre redes mediante routing.
    7. Aplicar reglas básicas de segmentación y control de acceso.
    8. Verificar el funcionamiento mediante pruebas reproducibles.
    9. Elaborar documentación técnica en Markdown.

    4. Historia del proyecto

    La infraestructura antigua utilizaba una única red para empleados, cámaras, servidores y visitantes. Esto ha provocado direcciones duplicadas, dificultad para localizar averías y acceso de usuarios no autorizados a recursos internos.

    La nueva red recibirá el nombre HAWKNET. Cada departamento deberá disponer de su propia subred. Las tres sedes estarán conectadas mediante enlaces WAN y compartirán determinados servicios alojados en la sede central.

    La dirección establece cuatro prioridades:

    • separar el tráfico de los departamentos;
    • garantizar que los nombres internos se resuelvan mediante DNS;
    • proporcionar configuración automática a los puestos de usuario;
    • proteger los laboratorios y la red de gestión frente a visitantes y dispositivos IoT.

    5. Topología general requerida

    La maqueta deberá contener, como mínimo:

    • un router o dispositivo de capa 3 en cada sede;
    • switches suficientes para representar la segmentación solicitada;
    • un switch principal en la sede central;
    • enlaces troncales cuando se utilicen VLAN;
    • un enlace entre la sede central y Starcourt;
    • un enlace entre la sede central y el búnker NINA;
    • servidores centralizados en Hawkins;
    • al menos un equipo cliente representativo en cada subred;
    • una nube o router ISP que represente Internet;
    • puntos de acceso inalámbricos para empleados y visitantes.

    El diseño exacto queda a criterio del equipo, pero todas las decisiones deberán justificarse.


    6. Necesidades de direccionamiento

    Se utilizará la red 172.20.0.0/16. A partir de ella debéis crear todas las subredes necesarias mediante VLSM.

    Las cantidades representan la capacidad que debe soportar cada red, no el número de dispositivos que hay que insertar en Packet Tracer.

    6.1. Sede Central de Hawkins

    Red o departamentoDispositivos actualesCrecimiento mínimo previsto
    Sensores, puertas y dispositivos IoT85020 %
    Wi-Fi de visitantes42020 %
    Personal administrativo19020 %
    Laboratorio de Energía11020 %
    Videovigilancia y seguridad física7520 %
    Investigadores6020 %
    Centro de Operaciones4220 %
    Servidores internos2620 %
    Telefonía IP2420 %
    Administración de red1220 %

    6.2. Estación de Campo Starcourt

    Red o departamentoDispositivos actualesCrecimiento mínimo previsto
    Personal de operaciones4820 %
    Sensores y cámaras3020 %
    Invitados1820 %
    Administración de red620 %

    6.3. Búnker NINA

    Red o departamentoDispositivos actualesCrecimiento mínimo previsto
    Laboratorio restringido2820 %
    Seguridad1420 %
    Servidores locales620 %
    Administración de red520 %

    6.4. Enlaces entre routers

    Debéis reservar una subred independiente para cada uno de estos enlaces:

    • Hawkins ↔ Starcourt.
    • Hawkins ↔ NINA.
    • Hawkins ↔ ISP.

    Cada enlace solo necesita las direcciones imprescindibles para sus dos extremos. Deberéis decidir si usar /30 o /31 y comprobar si la opción elegida es compatible con el simulador y los dispositivos utilizados.


    7. Normas para realizar el VLSM

    1. Calculad la capacidad necesaria sumando el crecimiento del 20 % y redondeando siempre hacia arriba.
    2. Recordad incluir las direcciones que vayan a consumir puertas de enlace, servidores u otros dispositivos de infraestructura.
    3. Ordenad las redes desde la que necesita más direcciones hasta la que necesita menos.
    4. Asignad a cada red el bloque más pequeño que cubra su necesidad.
    5. No pueden existir subredes solapadas.
    6. No debe desperdiciarse un bloque excesivamente grande sin una justificación técnica.
    7. La primera dirección utilizable de cada LAN se asignará, salvo justificación, a su puerta de enlace.
    8. Los servidores, routers, switches gestionables e impresoras usarán direcciones estáticas.
    9. Los clientes de usuario recibirán su configuración mediante DHCP.

    Para cada subred debéis mostrar el razonamiento utilizado. No será suficiente entregar una tabla generada automáticamente.


    8. Tabla obligatoria de direccionamiento

    La documentación incluirá una tabla como la siguiente, completada para todas las redes:

    SedeRed/VLANNecesidad con crecimientoPrefijoMáscara decimalDirección de redPrimer hostÚltimo hostBroadcastGateway
    HawkinsIoT

    También se añadirá una segunda tabla para los dispositivos configurados:

    DispositivoInterfazDirección IPMáscara/prefijoGatewayDNSAsignación
    SRV-DNS-01Fa0Estática

    9. VLAN y segmentación

    En la sede central cada departamento deberá estar separado mediante una VLAN o interfaz física diferente. Si se utilizan VLAN, debéis:

    • asignar un identificador y un nombre descriptivo a cada VLAN;
    • configurar los puertos de acceso;
    • utilizar una VLAN de gestión distinta de la VLAN nativa;
    • documentar qué puertos pertenecen a cada VLAN.

    Los identificadores de VLAN son libres, pero deben seguir un criterio coherente. Por ejemplo, se pueden agrupar por sede o por tipo de servicio.


    10. Routing entre sedes

    Todos los routers deberán conocer las redes remotas. El equipo elegirá una de estas opciones:

    El fallo de una ruta no podrá ocultarse añadiendo rutas innecesarias o utilizando una única red sin segmentación.


    11. Servicios obligatorios

    La red de servidores y las redes de administración no utilizarán DHCP para sus dispositivos principales.

    11.2. DNS

    El dominio interno será:

    hawkins.lab

    El DNS deberá contener, al menos, estos registros:

    11.3. Servidor web e intranet

    El servidor web mostrará una página sencilla con:

    • nombre y logotipo ficticio de la organización;
    • estado de las tres sedes;
    • mensaje de bienvenida;
    • nombre de los integrantes del equipo;
    • fecha de la última comprobación.

    La web pública de pruebas podrá ser accesible desde todas las redes. La intranet solo deberá ser accesible desde redes internas autorizadas.


    12. Requisitos básicos de seguridad

    La segmentación debe traducirse en reglas de acceso. Se configurarán ACL u otro mecanismo equivalente para cumplir, como mínimo, estas políticas:

    1. La red de visitantes solo puede acceder al DNS necesario, al portal web y a Internet.
    2. Los visitantes no pueden iniciar conexiones hacia las redes internas.
    3. La red IoT no puede acceder a Administración de red ni a los equipos de investigadores.
    4. Solo Administración de red puede gestionar routers y switches mediante SSH.
    5. Telnet deberá permanecer deshabilitado.
    6. El laboratorio NINA no será accesible desde redes de invitados.
    7. Seguridad podrá consultar las cámaras y sensores de las tres sedes.
    8. Los servidores DNS, DHCP y correo deberán ser accesibles únicamente desde las redes que necesiten cada servicio.

    Las reglas se colocarán lo más cerca posible del origen o destino y se documentará el motivo de cada una.


    13. Acceso a Internet y NAT

    La sede central se conectará a un router ISP. Debéis configurar:

    • una ruta por defecto hacia el ISP;
    • NAT/PAT para que las redes privadas autorizadas puedan salir a Internet;
    • un servidor externo de prueba, por ejemplo www.vecna-news.net, situado en una red que no pertenezca a 172.20.0.0/16;
    • bloqueo de salida para las redes que, según vuestra política, no deban acceder a Internet.

    No es necesario publicar servidores internos mediante NAT estático, aunque puede realizarse como ampliación.


    14. Nombres y configuración de dispositivos

    Los nombres deberán permitir identificar su ubicación y función. Ejemplos:

    RTR-HAW-01
    RTR-STAR-01
    RTR-NINA-01
    SW-HAW-CORE-01
    SW-HAW-LAB-01
    SRV-HAW-DNS-01
    PC-STAR-OPS-01

    15. Fases de realización

    Fase 1. Análisis

    1. Leed el caso completo.
    2. Identificad las sedes, departamentos, servidores y enlaces.
    3. Dibujad un primer esquema lógico.
    4. Decidid qué servicios serán centrales y cuáles serán locales.
    5. Anotad las restricciones de seguridad.

    Fase 2. Cálculo VLSM

    1. Calculad el número de hosts con crecimiento.
    2. Ordenad las redes de mayor a menor.
    3. Determinad el prefijo mínimo de cada una.
    4. Asignad los bloques dentro de 172.20.0.0/16.
    5. Calculad red, primer host, último host y broadcast.
    6. Comprobad que no existen solapamientos.
    7. Reservad espacio para futuras ampliaciones.

    Fase 3. Construcción de la topología

    1. Colocad routers, switches, servidores y clientes.
    2. Cablead correctamente los dispositivos.
    3. Asignad nombres a todos los equipos.
    4. Cread VLAN y configurad puertos.
    5. Configurad puertas de enlace.

    Fase 4. Direccionamiento y routing

    1. Configurad interfaces y subinterfaces.
    2. Asignad direcciones estáticas a infraestructura.
    3. Configurad rutas estáticas u OSPF.

    Fase 5. Pruebas y documentación

    1. Ejecutad el plan de pruebas.
    2. Corregid los fallos encontrados.
    3. Capturad evidencias relevantes.
    4. Completad el README.md.
    5. Revisad que otra persona pueda comprender y reproducir el proyecto.

    No se considerará demostrada una política si únicamente se prueba el caso permitido. Cuando corresponda, deberán probarse tanto el acceso correcto como su bloqueo.


    17. Entregables

    La entrega contendrá una carpeta comprimida con esta estructura orientativa:

    operacion-hawkins/
    ├── README.md
    ├── packet-tracer/
    │   └── hawknet.pkt
    ├── configuraciones/
    │   ├── RTR-HAW-01.txt
    │   ├── RTR-STAR-01.txt
    │   └── RTR-NINA-01.txt
    ├── diagramas/
    │   ├── topologia-logica.png
    │   └── topologia-fisica.png
    

    El archivo principal se llamará exactamente README.md y utilizará Markdown. Más adelante, cuando se haya trabajado Git, el mismo proyecto deberá poder incorporarse a un repositorio sin reorganizar toda la documentación.


    18. Contenido obligatorio del README.md

    1. Portada: título, integrantes, curso y fecha.
    2. Resumen ejecutivo del proyecto.
    3. Descripción de las tres sedes.
    4. Requisitos detectados.
    5. Diagrama lógico de red.
    6. Explicación paso a paso del cálculo VLSM.
    7. Tabla completa de direccionamiento.
    8. Tabla de VLAN.
    9. Inventario y función de los dispositivos.
    10. Explicación del routing seleccionado.
    11. Reglas de seguridad y ACL aplicadas.
    12. Configuración de NAT/PAT.
    13. Plan de pruebas y resultados.
    14. Problemas encontrados y soluciones.
    15. Conclusiones y posibles mejoras.
    16. Fuentes consultadas.

    Las capturas deben estar recortadas, ser legibles y llevar un pequeño texto explicativo. No se admitirán decenas de capturas sin contexto ni configuraciones pegadas sin explicación.


    19. Condiciones de aceptación

    El proyecto se considerará funcional cuando:

    • todas las subredes estén calculadas correctamente;
    • no haya direcciones duplicadas ni bloques solapados;
    • la comunicación entre sedes funcione;
    • los nombres internos se resuelvan mediante DNS;
    • los servicios obligatorios sean accesibles desde las redes autorizadas;
    • los accesos prohibidos sean realmente bloqueados;
    • el acceso exterior utilice NAT/PAT;
    • las pruebas estén documentadas;
    • el archivo de Packet Tracer se abra sin errores;
    • el README permita entender el trabajo sin una explicación oral adicional.

    Un proyecto en el que “todo puede comunicarse con todo” no cumplirá los requisitos de segmentación y seguridad.


    Las ampliaciones solo puntuarán si la parte obligatoria funciona y están correctamente explicadas.


    20. Penalizaciones importantes

    • Subredes solapadas o uso incorrecto de red/broadcast.
    • Archivo .pkt que no abre o que no coincide con la documentación.
    • Capturas de pantalla ajenas o configuraciones copiadas que el equipo no pueda explicar.
    • Uso de una sola red para evitar el trabajo de VLSM.

    21. Defensa del proyecto

    El profesor podrá seleccionar al azar cualquier dispositivo o prueba. El equipo tendrá que:

    Todos los integrantes deben conocer el proyecto completo. La división de tareas no exime de comprender el trabajo de la otra persona.


    23. Pregunta final de reflexión

    Incluid al final del README una respuesta razonada a estas cuestiones:

    • ¿Qué ventajas ofrece VLSM frente a utilizar la misma máscara en todas las redes?
    • ¿Qué ocurriría si empleados, servidores, cámaras y visitantes compartieran la misma red?
    • ¿Qué servicio causaría un impacto mayor si dejara de funcionar: DHCP, DNS o routing? Justificad la respuesta según vuestra infraestructura.
    • ¿Qué parte del diseño cambiaríais si la empresa duplicara su tamaño?

    Misión

    La red de Hawkins no debe limitarse a “tener pings”. Debe ser una infraestructura organizada, útil y defendible. Vuestro objetivo es demostrar que podéis convertir las necesidades de una organización en un diseño IP correcto, desplegar los servicios básicos y verificar que cada usuario accede únicamente a los recursos que necesita.

  • Proyecto: despliegue, ampliación y documentación de un servidor web con Ubuntu

    Proyecto: despliegue, ampliación y documentación de un servidor web con Ubuntu

    1. Presentación de la actividad

    Audio de introducción

    En esta actividad vas a desplegar y configurar un servidor web con Ubuntu siguiendo tres recursos proporcionados por el profesor. El objetivo no es limitarse a copiar comandos y realizar capturas de pantalla. Deberás comprender lo que haces, comprobar que cada elemento funciona y crear una documentación técnica que permita a otra persona repetir el proceso.

    El trabajo se desarrollará en tres partes consecutivas:

    1. Montaje del servidor web con Ubuntu.
    2. Ampliación UFW
    3. Configuración de Apache mediante archivos .htaccess.

    Cada parte amplía la anterior. Al terminar tendrás un único servidor funcional y un único documento técnico que describa todo el proyecto desde la preparación del entorno hasta las pruebas finales.

    2. Recursos obligatorios

    Debes seguir los tres recursos en el orden indicado. Puedes consultar otras fuentes para resolver problemas o ampliar las explicaciones, pero deberás citarlas en el apartado de referencias.

    3. Objetivos de aprendizaje

    Al finalizar la actividad deberás ser capaz de:

    • Preparar un sistema Ubuntu para funcionar como servidor.
    • Instalar, configurar y comprobar los servicios solicitados.
    • Identificar la función de los principales archivos, directorios, módulos, usuarios, permisos y puertos utilizados.
    • Aplicar configuraciones de Apache y comprobar sus efectos.
    • Interpretar los resultados de comandos de diagnóstico.
    • Detectar errores frecuentes y documentar su solución.
    • Valorar los riesgos de seguridad de una configuración.
    • Redactar documentación técnica clara y reproducible utilizando Markdown.
    • Organizar evidencias sin convertir el documento en una sucesión de capturas.
    • Preparar el proyecto para publicarlo posteriormente en un repositorio Git.

    4. Resultado que debes conseguir

    Debes disponer de un servidor Ubuntu desde el que se puedan demostrar las configuraciones solicitadas en las tres partes. Además, entregarás una documentación técnica completa en un archivo llamado exactamente:

    README.md

    La extensión correcta es .md, no .me. El archivo se escribirá con sintaxis Markdown.

    La documentación debe ser una ampliación razonada de los materiales. Esto significa que no debes copiar literalmente las explicaciones del profesor. Tienes que describir el proceso con tus propias palabras, explicar qué hace cada elemento importante y aportar pruebas de funcionamiento.

    5. Modalidad de realización

    • La actividad será individual, salvo que el profesor indique expresamente otra modalidad.
    • Cada estudiante deberá utilizar su propia máquina virtual o servidor asignado.
    • No se compartirán archivos README.md, capturas ni textos entre compañeros.
    • Sí se permite ayudar a localizar un error, siempre que cada estudiante comprenda y documente su propia solución.

    6. Preparación antes de comenzar

    Antes de modificar el servidor, anota en tu documentación:

    • Sistema de virtualización o equipo empleado.
    • Versión de Ubuntu.
    • Nombre de host.
    • Dirección IP del servidor.
    • Tipo de red de la máquina virtual: NAT, puente, red interna u otra.
    • Recursos asignados: CPU, memoria RAM y disco.
    • Dirección IP o nombre del equipo cliente desde el que realizarás las pruebas.

    Incluye una tabla similar a esta, completada con tus datos reales:

    ElementoConfiguración utilizada
    Sistema operativoUbuntu Server …
    Nombre del servidor
    Dirección IP
    CPU y RAM
    Disco
    Tipo de red
    Equipo cliente

    Recomendación previa

    Si trabajas con una máquina virtual, crea una instantánea antes de comenzar cada parte. Así podrás volver al estado anterior si una configuración deja el servidor inaccesible. Anota en el README.md cuándo has creado esas instantáneas.

    Protección de datos

    No incluyas en la entrega:

    • Contraseñas reales.
    • Claves privadas.
    • Tokens o credenciales.
    • Cookies o sesiones del Campus Virtual.
    • Direcciones públicas o datos personales que no sean necesarios.

    Oculta estos datos en las capturas. Utiliza valores de ejemplo cuando expliques credenciales.

    7. Parte 1: montaje del servidor web con Ubuntu

    Sigue el recurso de la parte 1 y documenta el proceso. Tu explicación deberá incluir, como mínimo, los siguientes bloques cuando aparezcan en el procedimiento realizado:

    7.1 Preparación del sistema

    Documenta la actualización del sistema y cualquier paquete previo necesario.

    Para cada comando importante:

    1. Escríbelo en un bloque de código.
    2. Explica qué hace.
    3. Describe las opciones o parámetros utilizados.
    4. Indica el resultado esperado.
    5. Añade una comprobación objetiva.

    Ejemplo del nivel de explicación esperado:

    sudo systemctl status apache2

    Este comando consulta el estado del servicio Apache. En la salida se debe comprobar que aparece como activo y en ejecución. No es suficiente con escribir «funciona»: hay que indicar qué dato de la salida permite afirmarlo.

    7.2 Instalación y prueba de Apache

    Debes explicar:

    • Qué es Apache y qué función cumple en el proyecto.
    • Qué paquete se instala.
    • Cómo se inicia, detiene, reinicia y consulta el servicio.
    • Qué directorio contiene inicialmente el sitio web.
    • Qué puerto utiliza HTTP.
    • Cómo accedes desde el equipo cliente.
    • Cómo compruebas el servicio desde terminal y desde navegador.

    Incluye una página web propia de prueba. No entregues únicamente la página predeterminada de Apache. La página debe mostrar, al menos, tu nombre, el título del proyecto y una indicación de que el servidor está operativo.

    7.3 Acceso remoto y transferencia de archivos

    Documenta los métodos de acceso o transferencia indicados en el recurso. Explica:

    • Qué servicio o programa interviene.
    • Qué puerto utiliza.
    • Qué usuario empleas y a qué directorio puede acceder.
    • Qué permisos has configurado.
    • Cómo has transferido o editado un archivo del sitio.
    • Cómo has verificado que el cambio aparece en el navegador.

    Si se utiliza FTP, añade una breve valoración de seguridad: diferencia entre FTP sin cifrar y alternativas como SFTP. No publiques credenciales reales.

    7.4 PHP

    Si el procedimiento incluye PHP, documenta:

    • Paquetes instalados y función de cada uno.
    • Versión instalada.
    • Integración con Apache.
    • Creación y ejecución de una página PHP de prueba.
    • Diferencia entre ejecutar PHP desde el servidor web y desde la terminal.

    Si utilizas una página con phpinfo(), elimínala o restríngele el acceso al finalizar, ya que puede mostrar información sensible del servidor. Explica esta decisión en el documento.

    7.5 Acceso mediante SSH o Visual Studio Code

    Si realizas este apartado, incluye:

    • Herramientas empleadas.
    • Configuración de la conexión sin mostrar contraseñas o claves privadas.
    • Directorio remoto abierto.
    • Prueba de edición de un archivo.
    • Evidencia del resultado servido por Apache.

    7.6 Comprobación de la parte 1

    Antes de continuar, verifica al menos:

    • El servidor responde a través de la red.
    • Apache está activo.
    • La página propia se carga desde el cliente.
    • Los archivos se encuentran en el directorio correcto.
    • PHP funciona, si forma parte del procedimiento.
    • El acceso remoto o la transferencia funciona, si se ha configurado.

    Incluye una tabla de pruebas:

    PruebaComando o acciónResultado esperadoResultado obtenidoEstado
    Estado de Apachesystemctl status apache2Servicio activoSuperada/No superada
    Acceso webAbrir http://IP_SERVIDORCarga la web propia
    Prueba de PHPAbrir la URL de pruebaPHP genera la respuesta

    8. Parte 2: ampliación del Campus Virtual

    Accede al recurso de la parte 2 con tu cuenta del Campus Virtual y realiza todos los pasos en el orden indicado.

    Como este bloque amplía el servidor de la parte 1, comienza explicando:

    • Qué nueva necesidad resuelve.
    • Qué servicio, componente o configuración añade.
    • Qué requisitos de la parte 1 necesita.
    • Qué cambios producirá en el servidor.

    Documentación obligatoria de cada paso

    Para cada acción relevante de la guía del campus incluye:

    1. Objetivo del paso. Qué se pretende conseguir.
    2. Comando o configuración. Escrito con el lenguaje correcto en un bloque de código.
    3. Explicación. Qué hace y por qué es necesario.
    4. Archivo afectado. Ruta completa y fragmento modificado, si corresponde.
    5. Comprobación. Comando, petición, acceso desde navegador o prueba equivalente.
    6. Resultado. Qué ocurrió realmente en tu servidor.
    7. Incidencia. Error encontrado y solución aplicada, si la hubo.

    No copies el texto completo del Campus Virtual. Reescribe el procedimiento con tus propias palabras y conserva únicamente los comandos, rutas y fragmentos de configuración necesarios.

    Comprobación de la parte 2

    Crea una tabla con todas las pruebas solicitadas por la guía. Debe quedar claro qué evidencia demuestra que la ampliación funciona y cómo podría repetirla otra persona.

    9. Parte 3: configuración de .htaccess en Apache

    Realiza la práctica de la parte 3 sobre el servidor ya configurado. Antes de empezar, crea una copia de seguridad de los archivos que vayas a modificar y documenta cómo podrías restaurarlos.

    9.1 Activación de .htaccess

    Explica:

    • Qué es un archivo .htaccess.
    • En qué directorios puede actuar.
    • Qué función cumple la directiva AllowOverride.
    • Qué diferencia existe entre AllowOverride None y AllowOverride All.
    • Qué archivo de Apache has modificado.
    • Cómo has validado la configuración antes de reiniciar o recargar el servicio.
    • Cómo has comprobado que Apache continúa funcionando.

    9.2 Autenticación básica

    Configura una zona restringida y documenta:

    • Directorio protegido.
    • Creación del archivo de usuarios.
    • Directivas de autenticación utilizadas.
    • Prueba sin autenticar, con credenciales incorrectas y con credenciales correctas.
    • Código de estado HTTP o comportamiento observado en cada caso.

    No muestres la contraseña. Investiga y explica por qué la autenticación básica debería utilizarse junto con HTTPS y por qué es preferible guardar .htpasswd fuera del directorio público cuando sea posible.

    9.3 Páginas de error personalizadas

    Crea páginas propias para los errores solicitados, por ejemplo 403 y 404. Las páginas deberán tener un diseño mínimo coherente con tu sitio.

    Comprueba cada error provocándolo de forma controlada e indica:

    • URL o acción de prueba.
    • Código esperado.
    • Código recibido.
    • Página mostrada.

    9.4 Cabeceras de seguridad

    Aplica las cabeceras propuestas en la práctica y crea una tabla como esta:

    CabeceraValor aplicadoRiesgo que ayuda a reducirMétodo de comprobación
    X-Frame-Options
    X-Content-Type-Options
    Referrer-Policy
    Permissions-Policy

    Comprueba las cabeceras con las herramientas de desarrollo del navegador o con una petición de terminal, no solo mediante una captura del archivo de configuración.

    Si el recurso incluye una cabecera considerada antigua o desaconsejada por navegadores actuales, indícalo en tu análisis y explica qué mecanismo moderno se utiliza en su lugar. Esta observación deberá estar respaldada por una fuente técnica.

    9.5 Redirecciones

    Configura y prueba las redirecciones solicitadas. Explica la diferencia entre una redirección permanente y una temporal, incluyendo:

    • Código de estado.
    • Efecto para el navegador.
    • Posible efecto en caché.
    • Uso habitual.
    • Implicaciones generales para buscadores.

    Incluye una prueba donde se puedan observar la respuesta y el destino final.

    9.6 Reescritura de URLs

    Si la guía utiliza mod_rewrite, explica:

    • Qué problema resuelve.
    • Diferencia entre redirección y reescritura interna.
    • Módulo necesario.
    • Significado de la regla aplicada.
    • URL escrita por el usuario y recurso procesado realmente.

    Debes demostrar el funcionamiento con al menos un ejemplo propio diferente del ejemplo literal de la guía.

    9.7 Resto de configuraciones del recurso

    Completa también las configuraciones adicionales incluidas en la guía, como control de indexación, protección u ocultación de recursos, caché o compresión, cuando aparezcan en el procedimiento. Para cada una explica el objetivo, la configuración aplicada, la prueba realizada y su resultado.

    9.8 Comprobación de la parte 3

    Prepara una tabla final de pruebas que incluya, como mínimo:

    • Acceso a la zona restringida.
    • Error 403.
    • Error 404.
    • Cabeceras de seguridad.
    • Redirección temporal.
    • Redirección permanente.
    • Reescritura de URL.
    • Resto de funcionalidades realizadas.

    10. Ampliaciones técnicas obligatorias

    Tu trabajo no debe ser una reproducción literal de los enlaces. Añade las siguientes ampliaciones:

    Ampliación A: mapa del sistema

    Incluye un diagrama Mermaid que muestre, al menos, el equipo cliente, el servidor Ubuntu, Apache y los componentes principales instalados. Ejemplo de sintaxis:

    flowchart LR
        A[Cliente] -->|HTTP| B[Apache en Ubuntu]
        B --> C[Sitio web]
        B --> D[PHP]

    Adapta el diagrama a tu instalación real. No copies el ejemplo sin modificarlo.

    Ampliación B: relación de puertos y servicios

    Incluye una tabla con los servicios utilizados, sus puertos, protocolo de transporte, finalidad y estado final. Si un puerto no debe quedar accesible, explícalo.

    Ampliación C: seguridad

    Identifica al menos cinco riesgos o decisiones de seguridad observados durante las tres partes. Para cada uno indica:

    • Riesgo.
    • Configuración relacionada.
    • Consecuencia posible.
    • Medida de mejora.
    • Prioridad: baja, media o alta.

    Ampliación D: diagnóstico

    Incluye una pequeña guía de resolución de problemas con un mínimo de cinco incidencias. Pueden ser errores que hayas encontrado o errores razonables que hayas reproducido de forma segura.

    SíntomaPosible causaComprobaciónSolución
    Apache no arrancaError de sintaxis
    La web no responde desde el cliente

    Ampliación E: comandos de comprobación

    Crea una sección de consulta rápida con los comandos que permitan comprobar el estado del servidor. No basta con enumerarlos: añade una frase que explique qué verifica cada uno.

    11. Estructura obligatoria del README.md

    El documento deberá contener, como mínimo, esta estructura:

    # Despliegue y ampliación de un servidor web con Ubuntu
    
    ## 1. Autor y datos de la práctica
    ## 2. Resumen del proyecto
    ## 3. Objetivos
    ## 4. Entorno y requisitos
    ## 5. Esquema de la infraestructura
    ## 6. Parte 1: montaje del servidor web
    ## 7. Parte 2: ampliación del Campus Virtual
    ## 8. Parte 3: configuración de .htaccess
    ## 9. Pruebas finales
    ## 10. Problemas encontrados y soluciones
    ## 11. Análisis de seguridad
    ## 12. Conclusiones
    ## 13. Referencias

    Puedes añadir subsecciones, pero no eliminar las anteriores.

    12. Requisitos de formato Markdown

    En el README.md deberás utilizar correctamente:

    • Títulos y subtítulos con #, ## y ###.
    • Párrafos breves y explicativos.
    • Listas numeradas y no numeradas.
    • Tablas.
    • Enlaces con texto descriptivo.
    • Imágenes con texto alternativo.
    • Bloques de código indicando el lenguaje: bash, apache, html, php, etc.
    • Código corto entre comillas invertidas.
    • Avisos o notas mediante citas >.
    • Al menos un diagrama Mermaid.
    • Índice con enlaces internos si el documento es largo.

    No utilices capturas para mostrar texto que puede copiarse, como comandos o configuraciones. Escríbelo en bloques de código y reserva las imágenes para demostrar resultados visuales relevantes.

    13. Capturas y evidencias

    Guarda las imágenes en una carpeta llamada img y utiliza nombres descriptivos:

    img/01-apache-activo.png
    img/02-web-desde-cliente.png
    img/03-zona-restringida.png
    img/04-error-404.png

    Insértalas con rutas relativas:

    ![Apache activo en el servidor](img/01-apache-activo.png)

    Cada evidencia debe cumplir estas condiciones:

    • Tener relación directa con una prueba.
    • Ser legible.
    • Mostrar solo la información necesaria.
    • Tener una explicación antes o después de la imagen.
    • Ocultar contraseñas, tokens y otros datos sensibles.
    • No repetir varias capturas que demuestren exactamente lo mismo.

    14. Organización de la entrega

    La carpeta deberá tener una estructura similar a esta:

    apellido-nombre-servidor-web/
    ├── README.md
    ├── img/
    │   ├── 01-apache-activo.png
    │   ├── 02-web-desde-cliente.png
    │   └── ...
    ├── web/
    │   ├── index.html
    │   ├── 403.html
    │   ├── 404.html
    │   └── ...
    └── config/
        ├── htaccess.txt
        └── ...

    Los archivos de configuración se entregarán como copia para su revisión. Si un archivo debe llamarse .htaccess en el servidor, puedes conservar ese nombre dentro de la entrega o añadir una copia legible como htaccess.txt. Nunca incluyas archivos de contraseñas reales como .htpasswd.

    15. Entrega actual mediante ZIP

    Como todavía no hemos trabajado Git, en esta primera entrega comprime la carpeta completa en un archivo ZIP con este nombre:

    apellido-nombre-servidor-web.zip

    Antes de subirlo, descomprímelo en una carpeta temporal y comprueba que:

    • Existe README.md en la raíz.
    • El documento se abre correctamente.
    • Las imágenes se muestran usando rutas relativas.
    • Se incluyen los archivos web y las configuraciones necesarias.
    • No hay contraseñas ni datos sensibles.
    • No se incluyen discos virtuales, imágenes ISO, copias completas de la máquina virtual ni carpetas innecesarias.

    Sube el ZIP al espacio de entrega indicado por el profesor.

    16. Publicación posterior en Git

    La entrega mediante ZIP es provisional. Cuando estudiemos Git y GitHub, deberás publicar esta misma actividad en un repositorio.

    Por este motivo, organiza desde ahora el trabajo como si ya fuera un repositorio:

    • Un único README.md principal en la raíz.
    • Carpetas con nombres simples, sin espacios ni tildes.
    • Rutas relativas para imágenes y enlaces internos.
    • Archivos ordenados y con nombres descriptivos.
    • Ninguna contraseña o credencial guardada.
    • Un archivo .gitignore cuando aprendamos Git, si el proyecto lo necesita.

    Más adelante se valorará la evolución del documento mediante commits. No será válido crear el repositorio al final y subir todo sin mostrar el proceso de mejora cuando se explique esa parte de la asignatura.

    17. Defensa y comprobación por parte del profesor

    El profesor podrá solicitar que el estudiante:

    • Explique cualquier comando incluido.
    • Localice un archivo de configuración.
    • Reinicie o recargue un servicio.
    • Demuestre una de las pruebas.
    • Modifique una regla sencilla.
    • Interprete un error.
    • Justifique una decisión de seguridad.

    Una configuración que funciona pero que el estudiante no puede explicar se considerará incompleta.

    18. Criterios de evaluación

    CriterioPeso
    Parte 1: instalación, configuración y pruebas20 %
    Parte 2: realización, explicación y pruebas15 %
    Parte 3: .htaccess, seguridad y pruebas25 %
    Ampliaciones técnicas y capacidad de análisis15 %
    Calidad del README.md y uso de Markdown15 %
    Organización, evidencias, referencias y entrega10 %
    Total100 %

    Para obtener una valoración alta

    El documento debe permitir reproducir el proyecto, explicar el propósito de las configuraciones, incluir pruebas objetivas, analizar riesgos y mostrar capacidad para resolver problemas.

    Penalizaciones importantes

    Podrán reducir la calificación:

    • Copiar y pegar los recursos sin elaborar explicaciones propias.
    • Incluir comandos que no se han ejecutado o resultados inventados.
    • Presentar capturas sin explicación.
    • No demostrar el funcionamiento de una parte.
    • Utilizar rutas absolutas locales para las imágenes del README.md.
    • Entregar enlaces o imágenes rotos.
    • Exponer contraseñas o credenciales.
    • No respetar la estructura de la entrega.

    La ausencia de una de las tres partes impedirá considerar el proyecto completo.

    19. Lista de comprobación final del estudiante

    Antes de entregar, confirma cada punto:

    • He completado las tres partes.
    • Mi archivo principal se llama README.md.
    • He escrito las explicaciones con mis propias palabras.
    • Puedo explicar todos los comandos que aparecen.
    • He indicado mi entorno y configuración de red.
    • He incluido un diagrama Mermaid adaptado a mi instalación.
    • He realizado y documentado pruebas objetivas.
    • He añadido las ampliaciones técnicas obligatorias.
    • He documentado al menos cinco problemas o casos de diagnóstico.
    • He analizado al menos cinco aspectos de seguridad.
    • Las imágenes tienen nombres descriptivos y rutas relativas.
    • No he incluido contraseñas, claves ni datos sensibles.
    • Las referencias utilizadas aparecen citadas.
    • He comprobado el ZIP después de descomprimirlo.
    • La estructura está preparada para convertirla posteriormente en un repositorio Git.

    20. Idea clave de la actividad

    El resultado no es solo un servidor que funciona. El verdadero producto de este proyecto es una documentación técnica que demuestre qué has construido, por qué lo has configurado así, cómo sabes que funciona y cómo podría mantenerlo o reproducirlo otra pe

  • Crear un entorno DEV tipo XAMPP/MAMP con Docker

    Crear un entorno DEV tipo XAMPP/MAMP con Docker

    Objetivo del proyecto

    En esta práctica vamos a crear un entorno de desarrollo web usando Docker. El objetivo es tener un sistema parecido a XAMPP o MAMP, pero más profesional, portable y fácil de reconstruir.

    El entorno permitirá trabajar con:

    • Apache
    • PHP
    • Extensiones comunes de PHP
    • MySQL
    • phpMyAdmin
    • Mailpit para probar correos
    • Redis como servicio adicional opcional
    • Una carpeta local donde guardaremos todos nuestros proyectos web

    Todos los contenedores tendrán el prefijo:

    DEV_

    De esta forma podremos identificarlos fácilmente dentro de Docker.


    1. ¿Qué vamos a construir?

    El sistema tendrá esta estructura:

    Carpeta local del alumno


    +-----------------------------+
    | Carpeta DEVLOCAL |
    | |
    | proyecto1/ |
    | proyecto2/ |
    | pruebas/ |
    | _docker/ |
    +-------------+---------------+


    +-----------------------------+
    | Docker Compose |
    +-------------+---------------+


    +-----------------------------+
    | DEV_apache_php |
    | DEV_mysql |
    | DEV_phpmyadmin |
    | DEV_mailpit |
    | DEV_redis |
    +-----------------------------+

    El alumno podrá crear una carpeta con un proyecto PHP y verlo desde el navegador.

    Por ejemplo:

    http://localhost:8080/pruebas/

    2. Requisitos previos

    Cada alumno necesitará:

    • Un ordenador con Windows, Ubuntu o macOS.
    • Docker instalado.
    • Un editor de código, por ejemplo VS Code.
    • Terminal o consola.
    • Navegador web.

    Docker Compose se usará para definir y levantar varios contenedores a la vez. Docker lo describe como una herramienta para definir y ejecutar aplicaciones multicontenedor.


    3. Instalación de Docker en Windows

    En Windows se recomienda usar Docker Desktop.

    Docker Desktop para Windows incluye Docker Engine, Docker CLI y Docker Compose. La documentación oficial indica que Docker Desktop puede usar WSL 2 como motor de ejecución en Windows.

    Pasos recomendados

    1. Instalar o activar WSL 2.
    2. Instalar Docker Desktop para Windows.
    3. Reiniciar el equipo si lo solicita.
    4. Abrir Docker Desktop.
    5. Comprobar que Docker está funcionando.

    Desde PowerShell o Terminal de Windows:

    docker --version
    docker compose version

    Si ambos comandos responden con una versión, Docker está funcionando correctamente.

    Carpeta recomendada en Windows

    Para evitar problemas con permisos o sincronización, se recomienda crear la carpeta directamente en C:\.

    mkdir C:\DEVLOCAL

    No es recomendable usar carpetas dentro de OneDrive para este tipo de práctica.


    4. Instalación de Docker en Ubuntu

    En Ubuntu se puede instalar Docker Engine directamente desde los repositorios oficiales de Docker. La documentación oficial recomienda configurar primero el repositorio apt de Docker y después instalar Docker Engine y sus plugins.

    Actualizar paquetes

    sudo apt update
    sudo apt upgrade -y

    Instalar dependencias

    sudo apt install -y ca-certificates curl gnupg

    Crear carpeta para claves

    sudo install -m 0755 -d /etc/apt/keyrings

    Descargar clave oficial de Docker

    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
    sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

    Dar permisos a la clave

    sudo chmod a+r /etc/apt/keyrings/docker.gpg

    Añadir repositorio oficial

    echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
    https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

    Instalar Docker

    sudo apt update
    sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

    Comprobar instalación

    docker --version
    docker compose version

    Permitir usar Docker sin sudo

    sudo usermod -aG docker $USER

    Después de este comando, el alumno debe cerrar sesión y volver a entrar.

    Carpeta recomendada en Ubuntu

    mkdir -p ~/DEVLOCAL

    5. Instalación de Docker en macOS

    En macOS se recomienda instalar Docker Desktop para Mac. La documentación oficial diferencia entre Mac con chip Intel y Mac con Apple Silicon, por lo que hay que descargar la versión adecuada.

    Pasos recomendados

    1. Descargar Docker Desktop para Mac.
    2. Elegir la versión correcta:
      • Mac Intel.
      • Mac Apple Silicon.
    3. Instalar la aplicación.
    4. Abrir Docker Desktop.
    5. Esperar a que Docker arranque completamente.
    6. Comprobar desde Terminal:
    docker --version
    docker compose version

    Carpeta recomendada en macOS

    En el caso de este ejemplo usaremos:

    /Users/antoniooteroveiga/DEVLOCAL

    Para otro usuario sería algo similar a:

    /Users/nombre_usuario/DEVLOCAL

    6. Crear la estructura del proyecto

    La estructura será la misma en Windows, Ubuntu y macOS.

    Windows

    Desde PowerShell:

    mkdir C:\DEVLOCAL
    mkdir C:\DEVLOCAL\_docker
    mkdir C:\DEVLOCAL\_docker\php
    mkdir C:\DEVLOCAL\_docker\apache
    mkdir C:\DEVLOCAL\pruebas

    Ubuntu

    Desde Terminal:

    mkdir -p ~/DEVLOCAL/_docker/php
    mkdir -p ~/DEVLOCAL/_docker/apache
    mkdir -p ~/DEVLOCAL/pruebas

    macOS

    Desde Terminal:

    mkdir -p /Users/antoniooteroveiga/DEVLOCAL/_docker/php
    mkdir -p /Users/antoniooteroveiga/DEVLOCAL/_docker/apache
    mkdir -p /Users/antoniooteroveiga/DEVLOCAL/pruebas

    La estructura final será:

    DEVLOCAL/
    ├── _docker/
    │ ├── docker-compose.yml
    │ ├── inicio.sh
    │ ├── inicio.bat
    │ ├── php/
    │ │ ├── Dockerfile
    │ │ ├── php.ini
    │ │ └── msmtprc
    │ └── apache/
    │ └── 000-default.conf
    └── pruebas/
    └── index.php

    7. Crear el archivo docker-compose.yml

    Este archivo define todos los servicios del entorno.

    Debe estar dentro de:

    DEVLOCAL/_docker/docker-compose.yml

    Contenido:

    services:

    apache_php:
    build:
    context: .
    dockerfile: php/Dockerfile
    container_name: DEV_apache_php
    restart: unless-stopped
    ports:
    - "8080:80"
    volumes:
    - ../:/var/www/html
    - ./apache/000-default.conf:/etc/apache2/sites-available/000-default.conf
    - ./php/php.ini:/usr/local/etc/php/conf.d/dev-custom.ini
    - ./php/msmtprc:/etc/msmtprc
    depends_on:
    - mysql
    - mailpit
    networks:
    - DEV_network

    mysql:
    image: mysql:8.4
    container_name: DEV_mysql
    restart: unless-stopped
    ports:
    - "3307:3306"
    environment:
    MYSQL_ROOT_PASSWORD: root
    MYSQL_DATABASE: devdb
    MYSQL_USER: devuser
    MYSQL_PASSWORD: devpass
    volumes:
    - DEV_mysql_data:/var/lib/mysql
    networks:
    - DEV_network

    phpmyadmin:
    image: phpmyadmin:latest
    container_name: DEV_phpmyadmin
    restart: unless-stopped
    ports:
    - "8081:80"
    environment:
    PMA_HOST: mysql
    PMA_PORT: 3306
    PMA_USER: root
    PMA_PASSWORD: root
    UPLOAD_LIMIT: 256M
    depends_on:
    - mysql
    networks:
    - DEV_network

    mailpit:
    image: axllent/mailpit:latest
    container_name: DEV_mailpit
    restart: unless-stopped
    ports:
    - "8025:8025"
    - "1025:1025"
    networks:
    - DEV_network

    redis:
    image: redis:latest
    container_name: DEV_redis
    restart: unless-stopped
    ports:
    - "6379:6379"
    networks:
    - DEV_network

    volumes:
    DEV_mysql_data:

    networks:
    DEV_network:
    name: DEV_network

    8. Crear el archivo Dockerfile

    Este archivo construirá nuestro contenedor de Apache con PHP.

    Debe estar en:

    DEVLOCAL/_docker/php/Dockerfile

    Contenido:

    FROM php:8.3-apache

    RUN apt-get update && apt-get install -y \
    git \
    unzip \
    zip \
    curl \
    msmtp \
    msmtp-mta \
    libzip-dev \
    libpng-dev \
    libjpeg-dev \
    libfreetype6-dev \
    libicu-dev \
    libonig-dev \
    libxml2-dev \
    libssl-dev \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install \
    mysqli \
    pdo \
    pdo_mysql \
    zip \
    gd \
    intl \
    mbstring \
    bcmath \
    soap \
    opcache \
    && a2enmod rewrite headers expires \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

    COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

    WORKDIR /var/www/html

    Con esto tendremos disponibles muchas extensiones habituales de PHP:

    • mysqli
    • pdo_mysql
    • gd
    • zip
    • intl
    • mbstring
    • bcmath
    • soap
    • opcache

    También tendremos instalado Composer, muy útil para proyectos PHP modernos.


    9. Crear el archivo php.ini

    Debe estar en:

    DEVLOCAL/_docker/php/php.ini

    Contenido:

    display_errors = On
    display_startup_errors = On
    error_reporting = E_ALL

    upload_max_filesize = 256M
    post_max_size = 256M
    memory_limit = 512M
    max_execution_time = 300
    max_input_vars = 5000

    date.timezone = Europe/Madrid

    opcache.enable = 1
    opcache.enable_cli = 1

    sendmail_path = "/usr/bin/msmtp -t"

    Este archivo ajusta PHP para un entorno de desarrollo.

    No es una configuración pensada para producción. En producción no deberíamos mostrar errores directamente al usuario.


    10. Crear el archivo msmtprc

    Este archivo permitirá enviar correos desde PHP hacia Mailpit.

    Debe estar en:

    DEVLOCAL/_docker/php/msmtprc

    Contenido:

    defaults
    auth off
    tls off

    account mailpit
    host mailpit
    port 1025
    from devlocal@example.test

    account default : mailpit

    Mailpit capturará los correos y podremos verlos desde el navegador.


    11. Crear la configuración de Apache

    Debe estar en:

    DEVLOCAL/_docker/apache/000-default.conf

    Contenido:

    <VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    <Directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/dev_error.log
    CustomLog ${APACHE_LOG_DIR}/dev_access.log combined
    </VirtualHost>

    La directiva importante es:

    AllowOverride All

    Esto permite usar archivos .htaccess, necesarios en muchos proyectos PHP, como WordPress, Laravel o aplicaciones con URLs amigables.


    12. Crear una página de prueba

    Creamos el archivo:

    DEVLOCAL/pruebas/index.php

    Contenido:

    <?php

    echo "<h1>Entorno DEV funcionando</h1>";
    echo "<p>Apache y PHP están funcionando correctamente.</p>";

    echo "<h2>Información de PHP</h2>";
    phpinfo();

    13. Levantar el entorno manualmente

    Windows

    Desde PowerShell:

    cd C:\DEVLOCAL\_docker
    docker compose up -d --build

    Ubuntu

    Desde Terminal:

    cd ~/DEVLOCAL/_docker
    docker compose up -d --build

    macOS

    Desde Terminal:

    cd /Users/antoniooteroveiga/DEVLOCAL/_docker
    docker compose up -d --build

    14. Comprobar los contenedores

    Ejecutamos:

    docker ps

    Deberíamos ver contenedores parecidos a estos:

    DEV_apache_php
    DEV_mysql
    DEV_phpmyadmin
    DEV_mailpit
    DEV_redis

    15. Acceder al entorno desde el navegador

    Apache + PHP

    http://localhost:8080

    Proyecto de pruebas

    http://localhost:8080/pruebas/

    phpMyAdmin

    http://localhost:8081

    Datos de acceso:

    Servidor: mysql
    Usuario: root
    Contraseña: root

    También podemos usar:

    Servidor: mysql
    Usuario: devuser
    Contraseña: devpass

    Mailpit

    http://localhost:8025

    MySQL desde el equipo anfitrión

    Para conectarse desde DBeaver, DataGrip, VS Code o MySQL Workbench:

    Host: localhost
    Puerto: 3307
    Usuario: devuser
    Contraseña: devpass
    Base de datos: devdb

    MySQL desde PHP

    Desde código PHP, el host no será localhost, sino el nombre del servicio Docker:

    Host: mysql
    Puerto: 3306
    Usuario: devuser
    Contraseña: devpass
    Base de datos: devdb

    16. Probar conexión con MySQL desde PHP

    Creamos el archivo:

    DEVLOCAL/pruebas/mysql.php

    Contenido:

    <?php

    $host = "mysql";
    $db = "devdb";
    $user = "devuser";
    $pass = "devpass";

    $conexion = new mysqli($host, $user, $pass, $db);

    if ($conexion->connect_error) {
    die("Error de conexión: " . $conexion->connect_error);
    }

    echo "<h1>Conexión correcta con MySQL</h1>";
    echo "<p>La base de datos devdb está disponible.</p>";

    $conexion->close();

    Abrimos en el navegador:

    http://localhost:8080/pruebas/mysql.php

    Si todo está correcto, veremos un mensaje confirmando la conexión.


    17. Probar envío de correo con Mailpit

    Creamos el archivo:

    DEVLOCAL/pruebas/mail.php

    Contenido:

    <?php

    $destino = "alumno@example.test";
    $asunto = "Prueba desde PHP";
    $mensaje = "Este correo ha sido enviado desde PHP y capturado por Mailpit.";
    $cabeceras = "From: devlocal@example.test";

    if (mail($destino, $asunto, $mensaje, $cabeceras)) {
    echo "<h1>Correo enviado correctamente</h1>";
    echo "<p>Abre Mailpit para verlo.</p>";
    } else {
    echo "<h1>Error al enviar el correo</h1>";
    }

    Abrimos:

    http://localhost:8080/pruebas/mail.php

    Después entramos en Mailpit:

    http://localhost:8025

    Ahí debería aparecer el correo capturado.


    18. Crear script de inicio para Ubuntu y macOS

    Creamos el archivo:

    DEVLOCAL/_docker/inicio.sh

    Contenido:

    #!/bin/bash

    clear

    echo "=============================================="
    echo " ENTORNO DEVLOCAL - DOCKER PHP MYSQL"
    echo "=============================================="
    echo ""

    DEV_PATH="$(cd "$(dirname "$0")" && pwd)"

    cd "$DEV_PATH" || exit 1

    echo "Levantando contenedores DEV..."
    echo ""

    docker compose up -d

    echo ""
    echo "Esperando a que los servicios arranquen..."
    sleep 3

    echo ""
    echo "=============================================="
    echo " CONTENEDORES ACTIVOS"
    echo "=============================================="
    echo ""

    docker ps --filter "name=DEV_"

    echo ""
    echo "=============================================="
    echo " INFORMACION DE CONEXION"
    echo "=============================================="
    echo ""

    echo "Servidor Apache + PHP:"
    echo " URL principal: http://localhost:8080"
    echo " Carpeta web: Carpeta DEVLOCAL del alumno"
    echo ""

    echo "Proyecto de prueba:"
    echo " http://localhost:8080/pruebas/"
    echo ""

    echo "phpMyAdmin:"
    echo " URL: http://localhost:8081"
    echo " Servidor: mysql"
    echo " Usuario root: root"
    echo " Password root: root"
    echo ""

    echo "MySQL desde PHP:"
    echo " Host: mysql"
    echo " Puerto: 3306"
    echo " Base de datos: devdb"
    echo " Usuario: devuser"
    echo " Password: devpass"
    echo ""

    echo "MySQL desde el equipo:"
    echo " Host: localhost"
    echo " Puerto: 3307"
    echo " Base de datos: devdb"
    echo " Usuario: devuser"
    echo " Password: devpass"
    echo ""

    echo "Mailpit:"
    echo " Panel web: http://localhost:8025"
    echo " SMTP interno: mailpit:1025"
    echo ""

    echo "Redis:"
    echo " Host desde Docker: redis"
    echo " Host desde equipo: localhost"
    echo " Puerto: 6379"
    echo ""

    echo "=============================================="
    echo " COMANDOS UTILES"
    echo "=============================================="
    echo ""

    echo "Parar entorno:"
    echo " docker compose down"
    echo ""

    echo "Ver logs:"
    echo " docker compose logs -f"
    echo ""

    echo "Entrar al contenedor PHP:"
    echo " docker exec -it DEV_apache_php bash"
    echo ""

    echo "Entrar a MySQL:"
    echo " docker exec -it DEV_mysql mysql -u root -p"
    echo ""

    echo "=============================================="
    echo " ENTORNO DEV LISTO"
    echo "=============================================="
    echo ""

    Damos permisos de ejecución:

    chmod +x inicio.sh

    Lo ejecutamos:

    ./inicio.sh

    19. Crear script de inicio para Windows

    Creamos el archivo:

    DEVLOCAL/_docker/inicio.bat

    Contenido:

    @echo off
    cls

    echo ==============================================
    echo ENTORNO DEVLOCAL - DOCKER PHP MYSQL
    echo ==============================================
    echo.

    cd /d "%~dp0"

    echo Levantando contenedores DEV...
    echo.

    docker compose up -d

    echo.
    echo Esperando a que los servicios arranquen...
    timeout /t 3 > nul

    echo.
    echo ==============================================
    echo CONTENEDORES ACTIVOS
    echo ==============================================
    echo.

    docker ps --filter "name=DEV_"

    echo.
    echo ==============================================
    echo INFORMACION DE CONEXION
    echo ==============================================
    echo.

    echo Servidor Apache + PHP:
    echo URL principal: http://localhost:8080
    echo Carpeta web: Carpeta DEVLOCAL del alumno
    echo.

    echo Proyecto de prueba:
    echo http://localhost:8080/pruebas/
    echo.

    echo phpMyAdmin:
    echo URL: http://localhost:8081
    echo Servidor: mysql
    echo Usuario root: root
    echo Password root: root
    echo.

    echo MySQL desde PHP:
    echo Host: mysql
    echo Puerto: 3306
    echo Base de datos: devdb
    echo Usuario: devuser
    echo Password: devpass
    echo.

    echo MySQL desde Windows:
    echo Host: localhost
    echo Puerto: 3307
    echo Base de datos: devdb
    echo Usuario: devuser
    echo Password: devpass
    echo.

    echo Mailpit:
    echo Panel web: http://localhost:8025
    echo SMTP interno: mailpit:1025
    echo.

    echo Redis:
    echo Host desde Docker: redis
    echo Host desde Windows: localhost
    echo Puerto: 6379
    echo.

    echo ==============================================
    echo COMANDOS UTILES
    echo ==============================================
    echo.

    echo Parar entorno:
    echo docker compose down
    echo.

    echo Ver logs:
    echo docker compose logs -f
    echo.

    echo Entrar al contenedor PHP:
    echo docker exec -it DEV_apache_php bash
    echo.

    echo Entrar a MySQL:
    echo docker exec -it DEV_mysql mysql -u root -p
    echo.

    echo ==============================================
    echo ENTORNO DEV LISTO
    echo ==============================================
    echo.

    pause

    Para ejecutarlo, el alumno puede hacer doble clic sobre inicio.bat o ejecutarlo desde PowerShell.


    20. Script para parar el entorno

    Ubuntu y macOS

    Creamos:

    DEVLOCAL/_docker/parar.sh

    Contenido:

    #!/bin/bash

    cd "$(dirname "$0")" || exit 1

    echo "Parando entorno DEV..."
    docker compose down

    echo "Entorno detenido."

    Permisos:

    chmod +x parar.sh

    Ejecución:

    ./parar.sh

    Windows

    Creamos:

    DEVLOCAL/_docker/parar.bat

    Contenido:

    @echo off
    cls

    cd /d "%~dp0"

    echo Parando entorno DEV...
    docker compose down

    echo.
    echo Entorno detenido.
    pause

    21. Comandos básicos que debe conocer el alumno

    Levantar contenedores

    docker compose up -d

    Levantar y reconstruir

    docker compose up -d --build

    Parar contenedores

    docker compose down

    Ver contenedores activos

    docker ps

    Ver todos los contenedores

    docker ps -a

    Ver logs

    docker compose logs -f

    Ver logs de un servicio concreto

    docker compose logs -f apache_php

    Entrar al contenedor de PHP

    docker exec -it DEV_apache_php bash

    Entrar al contenedor de MySQL

    docker exec -it DEV_mysql mysql -u root -p

    Contraseña:

    root

    22. Crear varios proyectos web

    El alumno puede crear diferentes carpetas dentro de DEVLOCAL.

    Por ejemplo:

    DEVLOCAL/
    ├── pruebas/
    ├── tienda/
    ├── blog/
    ├── reservas/
    └── ejercicios_php/

    Cada proyecto se abrirá desde el navegador así:

    http://localhost:8080/pruebas/
    http://localhost:8080/tienda/
    http://localhost:8080/blog/
    http://localhost:8080/reservas/
    http://localhost:8080/ejercicios_php/

    23. Ejercicio práctico

    Parte 1: Comprobar PHP

    Crear una carpeta llamada:

    alumno_php

    Dentro crear un archivo:

    index.php

    Con este contenido:

    <?php

    $nombre = "Alumno";
    $curso = "Desarrollo Web con PHP";

    echo "<h1>Hola, $nombre</h1>";
    echo "<p>Estamos trabajando en el curso de $curso.</p>";

    Abrir:

    http://localhost:8080/alumno_php/

    Parte 2: Comprobar MySQL

    Crear un archivo:

    conexion.php

    Contenido:

    <?php

    $conexion = new mysqli("mysql", "devuser", "devpass", "devdb");

    if ($conexion->connect_error) {
    die("Error: " . $conexion->connect_error);
    }

    echo "Conexión correcta con MySQL";

    Abrir:

    http://localhost:8080/alumno_php/conexion.php

    Parte 3: Crear una tabla desde phpMyAdmin

    Entrar en:

    http://localhost:8081

    Seleccionar la base de datos:

    devdb

    Crear una tabla llamada:

    alumnos

    Con estos campos:

    CampoTipoExtra
    idINTAUTO_INCREMENT, PRIMARY KEY
    nombreVARCHAR(100)
    emailVARCHAR(150)
    fecha_altaDATETIME

    SQL:

    CREATE TABLE alumnos (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL,
    email VARCHAR(150) NOT NULL,
    fecha_alta DATETIME DEFAULT CURRENT_TIMESTAMP
    );

    Insertar datos:

    INSERT INTO alumnos (nombre, email) VALUES
    ('Ana', 'ana@example.test'),
    ('Luis', 'luis@example.test'),
    ('Marta', 'marta@example.test');

    Parte 4: Leer datos desde PHP

    Crear:

    listar.php

    Contenido:

    <?php

    $conexion = new mysqli("mysql", "devuser", "devpass", "devdb");

    if ($conexion->connect_error) {
    die("Error: " . $conexion->connect_error);
    }

    $resultado = $conexion->query("SELECT * FROM alumnos");

    echo "<h1>Listado de alumnos</h1>";

    echo "<table border='1' cellpadding='8'>";
    echo "<tr>";
    echo "<th>ID</th>";
    echo "<th>Nombre</th>";
    echo "<th>Email</th>";
    echo "<th>Fecha de alta</th>";
    echo "</tr>";

    while ($fila = $resultado->fetch_assoc()) {
    echo "<tr>";
    echo "<td>" . $fila["id"] . "</td>";
    echo "<td>" . $fila["nombre"] . "</td>";
    echo "<td>" . $fila["email"] . "</td>";
    echo "<td>" . $fila["fecha_alta"] . "</td>";
    echo "</tr>";
    }

    echo "</table>";

    $conexion->close();

    Abrir:

    http://localhost:8080/alumno_php/listar.php

    24. Preguntas de reflexión para el alumno

    1. ¿Qué diferencia hay entre instalar Apache, PHP y MySQL directamente en el sistema y hacerlo con Docker?
    2. ¿Qué ventaja tiene que todos los servicios estén definidos en un archivo docker-compose.yml?
    3. ¿Por qué PHP se conecta a MySQL usando el host mysql y no localhost?
    4. ¿Qué es un volumen en Docker?
    5. ¿Dónde se guardan los datos de MySQL en este proyecto?
    6. ¿Qué pasaría si ejecutamos docker compose down -v?
    7. ¿Para qué sirve phpMyAdmin?
    8. ¿Para qué sirve Mailpit?
    9. ¿Por qué no deberíamos usar contraseñas como root o devpass en producción?
    10. ¿Qué diferencia hay entre un entorno de desarrollo y un entorno de producción?

    25. Problemas frecuentes

    Docker no arranca en Windows

    Posibles causas:

    • Docker Desktop no está abierto.
    • WSL 2 no está instalado o activado.
    • La virtualización está desactivada en BIOS/UEFI.
    • El equipo necesita reiniciarse.

    Docker recomienda usar el backend WSL 2 en Windows para Docker Desktop.


    El puerto 8080 ya está ocupado

    Puede ocurrir si otro servicio ya está usando ese puerto.

    Solución: cambiar en docker-compose.yml:

    ports:
    - "8080:80"

    Por ejemplo:

    ports:
    - "8090:80"

    Después habría que entrar por:

    http://localhost:8090

    El puerto 3307 ya está ocupado

    Cambiar:

    ports:
    - "3307:3306"

    Por ejemplo:

    ports:
    - "3308:3306"

    No aparecen los cambios en PHP

    Probar a recargar el navegador con:

    Ctrl + F5

    También se puede reiniciar el contenedor:

    docker compose restart apache_php

    Error de permisos en Ubuntu

    Si Docker pide sudo, puede faltar añadir el usuario al grupo docker.

    sudo usermod -aG docker $USER

    Después hay que cerrar sesión y volver a entrar.


    phpMyAdmin no conecta

    Comprobar que MySQL está activo:

    docker ps

    También se pueden ver los logs:

    docker compose logs -f mysql

    26. Cómo borrar todo y empezar de nuevo

    Para parar los contenedores:

    docker compose down

    Para parar y borrar también los datos de MySQL:

    docker compose down -v

    Cuidado: este comando borra el volumen de MySQL. Si hay bases de datos creadas, se perderán.


    29. Ampliaciones posibles

    Cuando el entorno básico funcione, se pueden añadir mejoras:

    • Crear dominios locales como tienda.localhost.
    • Añadir HTTPS local.
    • Añadir un contenedor de Node.js.
    • Añadir un contenedor específico para Laravel.
    • Crear plantillas para WordPress.
    • Añadir copias de seguridad automáticas de MySQL.
    • Crear un script para exportar e importar bases de datos.
    • Crear varios entornos: desarrollo, pruebas y producción.

    30. Conclusión

    Con esta práctica hemos creado un entorno de desarrollo web completo usando Docker. El resultado es similar a XAMPP o MAMP, pero con una ventaja importante: todo el entorno queda definido mediante archivos.

    Esto permite:

    • Repetir la instalación en diferentes sistemas operativos.
    • Compartir el entorno con otros compañeros.
    • Evitar conflictos con instalaciones locales.
    • Trabajar con varios servicios a la vez.
    • Preparar al alumno para entornos profesionales basados en contenedores.

    Docker Compose facilita levantar todos los servicios con un solo comando, lo que lo convierte en una herramienta especialmente útil para desarrollo web moderno.

    Script Cerrar

    Además del script inicio, vamos a crear un script llamado cerrar. Este script no solamente permite apagar el entorno, sino también eliminarlo de diferentes formas según lo que necesitemos. Esto es importante porque no siempre queremos borrar los datos. A veces solo queremos detener los contenedores, y otras veces queremos empezar desde cero.


    Diferencia entre las opciones

    OpciónComando¿Borra contenedores?¿Borra datos MySQL?¿Borra imágenes?
    Parardocker compose stopNoNoNo
    Eliminar contenedoresdocker compose downNoNo
    Eliminar con volúmenesdocker compose down -vNo
    Destruir completodocker compose down -v --rmi local

    docker compose stop

    Detiene los contenedores, pero no los elimina.

    Es como apagar una máquina virtual.


    docker compose down

    Detiene y elimina los contenedores, pero mantiene los volúmenes.

    Es decir, si teníamos una base de datos MySQL con datos, normalmente se conservará.


    docker compose down -v

    Detiene y elimina los contenedores, y también borra los volúmenes.

    En este proyecto significa que se borrarán los datos de MySQL.


    docker compose down -v --rmi local

    Además de eliminar contenedores y volúmenes, elimina imágenes locales creadas por el proyecto.

    En nuestro caso, puede borrar la imagen personalizada de Apache + PHP, por lo que en el siguiente arranque habrá que reconstruirla con:

    docker compose up -d --build

    Recomendación para uso diario

    Para el día a día, lo normal es usar la opción:

    1) Parar contenedores

    o:

    2) Parar y eliminar contenedores

    La opción 3 y 4 solo deberían usarse cuando queramos empezar desde cero.

    Especialmente la opción 3:

    docker compose down -v

    porque borra los datos de MySQL.

    Script para Ubuntu y macOS: cerrar.sh

    Crear el archivo:

    nano /Users/antoniooteroveiga/DEVLOCAL/_docker/cerrar.sh

    Contenido:

    #!/bin/bash

    clear

    echo "=============================================="
    echo " CERRAR ENTORNO DEVLOCAL"
    echo "=============================================="
    echo ""

    DEV_PATH="$(cd "$(dirname "$0")" && pwd)"
    cd "$DEV_PATH" || exit 1

    echo "Este script permite cerrar o destruir el entorno Docker DEV."
    echo ""
    echo "Elige una opcion:"
    echo ""
    echo " 1) Parar contenedores"
    echo " Equivale a: docker compose stop"
    echo ""
    echo " 2) Parar y eliminar contenedores"
    echo " Equivale a: docker compose down"
    echo ""
    echo " 3) Parar, eliminar contenedores y borrar volumenes"
    echo " Equivale a: docker compose down -v"
    echo " AVISO: se borraran las bases de datos de MySQL."
    echo ""
    echo " 4) Parar, eliminar contenedores, volumenes e imagenes del proyecto"
    echo " Equivale a: docker compose down -v --rmi local"
    echo " AVISO: se borraran las bases de datos y las imagenes creadas localmente."
    echo ""
    echo " 5) Ver contenedores DEV activos"
    echo ""
    echo " 6) Cancelar"
    echo ""

    read -p "Selecciona una opcion [1-6]: " opcion

    echo ""

    case "$opcion" in

    1)
    echo "Parando contenedores..."
    docker compose stop
    echo ""
    echo "Contenedores detenidos."
    ;;

    2)
    echo "Parando y eliminando contenedores..."
    docker compose down
    echo ""
    echo "Contenedores eliminados. Los volumenes se conservan."
    ;;

    3)
    echo "ATENCION: esta opcion borrara los volumenes."
    echo "Esto eliminara los datos persistentes de MySQL."
    echo ""
    read -p "Escribe BORRAR para confirmar: " confirmacion

    if [ "$confirmacion" = "BORRAR" ]; then
    echo ""
    echo "Eliminando contenedores y volumenes..."
    docker compose down -v
    echo ""
    echo "Entorno eliminado con volumenes."
    else
    echo ""
    echo "Operacion cancelada. No se ha borrado nada."
    fi
    ;;

    4)
    echo "ATENCION: esta opcion borrara contenedores, volumenes e imagenes locales."
    echo "Esto eliminara los datos de MySQL y obligara a reconstruir la imagen PHP."
    echo ""
    read -p "Escribe DESTRUIR para confirmar: " confirmacion

    if [ "$confirmacion" = "DESTRUIR" ]; then
    echo ""
    echo "Eliminando contenedores, volumenes e imagenes locales..."
    docker compose down -v --rmi local
    echo ""
    echo "Entorno destruido."
    else
    echo ""
    echo "Operacion cancelada. No se ha borrado nada."
    fi
    ;;

    5)
    echo "Mostrando contenedores DEV..."
    echo ""
    docker ps -a --filter "name=DEV_"
    ;;

    6)
    echo "Operacion cancelada."
    ;;

    *)
    echo "Opcion no valida."
    ;;

    esac

    echo ""
    echo "=============================================="
    echo " PROCESO FINALIZADO"
    echo "=============================================="
    echo ""

    Dar permisos de ejecución:

    chmod +x /Users/antoniooteroveiga/DEVLOCAL/_docker/cerrar.sh

    Ejecutarlo:

    cd /Users/antoniooteroveiga/DEVLOCAL/_docker
    ./cerrar.sh

    Versión más portable

    Si quieres que funcione sin depender de tu usuario concreto, es mejor decirles que creen el archivo dentro de _docker y que lo ejecuten desde ahí.

    cd ~/DEVLOCAL/_docker
    nano cerrar.sh
    chmod +x cerrar.sh
    ./cerrar.sh

    El script ya detecta automáticamente la carpeta donde está, gracias a esta línea:

    DEV_PATH="$(cd "$(dirname "$0")" && pwd)"

    Por eso vale tanto para Ubuntu como para macOS.


    Script para Windows: cerrar.bat

    Crear el archivo:

    C:\DEVLOCAL\_docker\cerrar.bat

    Contenido:

    @echo off
    cls

    cd /d "%~dp0"

    :menu
    cls
    echo ==============================================
    echo CERRAR ENTORNO DEVLOCAL
    echo ==============================================
    echo.
    echo Este script permite cerrar o destruir el entorno Docker DEV.
    echo.
    echo Elige una opcion:
    echo.
    echo 1) Parar contenedores
    echo Equivale a: docker compose stop
    echo.
    echo 2) Parar y eliminar contenedores
    echo Equivale a: docker compose down
    echo.
    echo 3) Parar, eliminar contenedores y borrar volumenes
    echo Equivale a: docker compose down -v
    echo AVISO: se borraran las bases de datos de MySQL.
    echo.
    echo 4) Parar, eliminar contenedores, volumenes e imagenes del proyecto
    echo Equivale a: docker compose down -v --rmi local
    echo AVISO: se borraran las bases de datos y las imagenes creadas localmente.
    echo.
    echo 5) Ver contenedores DEV activos
    echo.
    echo 6) Cancelar
    echo.

    set /p opcion=Selecciona una opcion [1-6]:

    if "%opcion%"=="1" goto parar
    if "%opcion%"=="2" goto eliminar
    if "%opcion%"=="3" goto volumenes
    if "%opcion%"=="4" goto destruir
    if "%opcion%"=="5" goto ver
    if "%opcion%"=="6" goto cancelar

    echo.
    echo Opcion no valida.
    pause
    goto menu

    :parar
    cls
    echo Parando contenedores...
    echo.
    docker compose stop
    echo.
    echo Contenedores detenidos.
    pause
    goto fin

    :eliminar
    cls
    echo Parando y eliminando contenedores...
    echo.
    docker compose down
    echo.
    echo Contenedores eliminados. Los volumenes se conservan.
    pause
    goto fin

    :volumenes
    cls
    echo ATENCION: esta opcion borrara los volumenes.
    echo Esto eliminara los datos persistentes de MySQL.
    echo.
    set /p confirmacion=Escribe BORRAR para confirmar:

    if "%confirmacion%"=="BORRAR" (
    echo.
    echo Eliminando contenedores y volumenes...
    docker compose down -v
    echo.
    echo Entorno eliminado con volumenes.
    ) else (
    echo.
    echo Operacion cancelada. No se ha borrado nada.
    )

    pause
    goto fin

    :destruir
    cls
    echo ATENCION: esta opcion borrara contenedores, volumenes e imagenes locales.
    echo Esto eliminara los datos de MySQL y obligara a reconstruir la imagen PHP.
    echo.
    set /p confirmacion=Escribe DESTRUIR para confirmar:

    if "%confirmacion%"=="DESTRUIR" (
    echo.
    echo Eliminando contenedores, volumenes e imagenes locales...
    docker compose down -v --rmi local
    echo.
    echo Entorno destruido.
    ) else (
    echo.
    echo Operacion cancelada. No se ha borrado nada.
    )

    pause
    goto fin

    :ver
    cls
    echo Mostrando contenedores DEV...
    echo.
    docker ps -a --filter "name=DEV_"
    echo.
    pause
    goto menu

    :cancelar
    cls
    echo Operacion cancelada.
    pause
    goto fin

    :fin
    cls
    echo ==============================================
    echo PROCESO FINALIZADO
    echo ==============================================
    echo.

  • Montar Google Drive como una unidad en Ubuntu sin sincronizar archivos

    Montar Google Drive como una unidad en Ubuntu sin sincronizar archivos

    1. Introducción

    En esta práctica vamos a aprender a montar Google Drive en Ubuntu como si fuera una unidad del sistema, pero sin sincronizar todos los archivos en el disco duro.

    Esto significa que podremos acceder a los archivos de Google Drive desde el explorador de archivos de Ubuntu, o desde la terminal, pero los archivos no se descargarán todos automáticamente. Se irán leyendo bajo demanda cuando los abramos o los copiemos.

    Para conseguirlo usaremos una herramienta llamada rclone.


    2. Objetivos de la práctica

    Al finalizar esta práctica, el alumno será capaz de:

    • Instalar rclone en Ubuntu.
    • Configurar una cuenta de Google Drive en rclone.
    • Montar Google Drive como una carpeta local.
    • Acceder a los archivos de Drive desde Ubuntu sin sincronizarlos.
    • Desmontar la unidad cuando sea necesario.
    • Crear un servicio para montar Google Drive automáticamente al iniciar sesión.

    3. Requisitos previos

    Para realizar esta práctica necesitas:

    • Un equipo con Ubuntu instalado.
    • Conexión a Internet.
    • Una cuenta de Google Drive.
    • Acceso a la terminal.
    • Permisos de administrador en el sistema.

    4. ¿Qué es rclone?

    rclone es una herramienta de línea de comandos que permite trabajar con servicios de almacenamiento en la nube como:

    • Google Drive.
    • OneDrive.
    • Dropbox.
    • Mega.
    • Amazon S3.
    • Nextcloud.
    • WebDAV.

    En esta práctica lo usaremos para montar Google Drive como una unidad, no para sincronizarlo.

    La diferencia es importante:

    OpciónQué hace
    SincronizarDescarga y mantiene copias locales de los archivos
    MontarMuestra los archivos como si estuvieran en local, pero se accede a ellos bajo demanda

    5. Instalación de rclone

    Abrimos una terminal y actualizamos la lista de paquetes:

    sudo apt update

    Instalamos rclone y fuse3:

    sudo apt install rclone fuse3

    fuse3 permite que un usuario pueda montar sistemas de archivos virtuales, como en este caso Google Drive.

    Comprobamos que rclone se ha instalado correctamente:

    rclone version

    Deberíamos ver una salida parecida a esta:

    rclone v1.xx.x
    - os/version: ubuntu
    - os/kernel: linux
    - os/type: linux

    6. Configuración de Google Drive en rclone

    Ahora vamos a configurar la conexión con nuestra cuenta de Google Drive.

    Ejecutamos:

    rclone config

    Aparecerá un menú en la terminal.

    Como todavía no tenemos ninguna conexión configurada, elegimos la opción:

    n

    Esta opción significa:

    New remote

    Es decir, crear una nueva conexión remota.


    6.1. Nombre de la conexión

    Cuando pregunte por el nombre, escribimos:

    gdrive

    Podríamos poner otro nombre, pero para esta práctica usaremos gdrive.

    Este nombre será el identificador que usaremos más adelante para referirnos a nuestro Google Drive.


    6.2. Selección del tipo de almacenamiento

    Después aparecerá una lista con muchos servicios de almacenamiento.

    Buscamos la opción correspondiente a:

    Google Drive

    El número puede cambiar según la versión de rclone, así que no copies el número de otra guía sin mirar la lista.

    Escribe el número que corresponda a Google Drive y pulsa Enter.


    6.3. Client ID y Client Secret

    rclone nos preguntará por:

    client_id
    client_secret

    Para una práctica normal podemos dejarlos vacíos pulsando Enter.

    Esto usará la configuración genérica de rclone.

    Si te pregunta algo mas que no sea scope dale a enter.


    6.4. Scope o permisos de acceso

    Cuando pregunte por el tipo de permisos o scope, elegimos la opción que permita acceso completo a Google Drive.

    Normalmente aparece como:

    drive

    Esto permite leer y escribir archivos en Google Drive desde Ubuntu.


    6.5. Configuración avanzada

    Cuando pregunte si queremos configuración avanzada:

    Edit advanced config?

    Respondemos:

    n

    6.6. Autenticación con Google

    Cuando pregunte:

    Use auto config?

    Si estamos en un Ubuntu con entorno gráfico, respondemos:

    y

    Se abrirá el navegador web para iniciar sesión con nuestra cuenta de Google.

    Aceptamos los permisos solicitados por rclone.

    Cuando el proceso termine, volvemos a la terminal.


    6.7. Guardar configuración

    Al final, rclone mostrará un resumen de la configuración.

    Cuando pregunte si queremos guardar la conexión, respondemos:

    y

    Después salimos del menú de configuración con:

    q

    7. Comprobar que la conexión funciona

    Para comprobar que podemos acceder a Google Drive, ejecutamos:

    rclone lsd gdrive:

    Este comando lista las carpetas principales de Google Drive.

    Si todo ha ido bien, veremos algo parecido a:

              -1 2026-05-25 10:30:00        -1 Documentos
    -1 2026-05-25 10:30:00 -1 Copias
    -1 2026-05-25 10:30:00 -1 Fotos

    Si aparece un error de autenticación, probablemente haya que repetir la configuración con:

    rclone config

    8. Crear la carpeta de montaje

    Ahora vamos a crear una carpeta local donde aparecerá Google Drive.

    Ejecutamos:

    mkdir -p ~/GoogleDrive

    Esta carpeta estará en nuestro directorio personal.

    La ruta completa será algo parecido a:

    /home/usuario/GoogleDrive

    Por ejemplo, si el usuario se llama antonio, la ruta será:

    /home/antonio/GoogleDrive

    9. Montar Google Drive como unidad

    Ahora montamos Google Drive dentro de esa carpeta:

    rclone mount gdrive: ~/GoogleDrive \
    --vfs-cache-mode writes \
    --daemon

    Explicación del comando:

    ParteSignificado
    rclone mountMonta un almacenamiento remoto
    gdrive:Nombre de la conexión configurada
    ~/GoogleDriveCarpeta local donde se montará
    --vfs-cache-mode writesUsa caché para operaciones de escritura
    --daemonEjecuta el montaje en segundo plano

    9.1. Comprobar el montaje

    Podemos comprobarlo desde la terminal:

    ls ~/GoogleDrive

    También podemos abrir el explorador de archivos de Ubuntu y entrar en la carpeta:

    GoogleDrive

    Ahí deberían aparecer los archivos y carpetas de nuestra cuenta de Google Drive.


    10. Importante: esto no sincroniza todos los archivos

    Este punto es clave.

    Con este sistema, Google Drive aparece como una carpeta local, pero no se descargan todos los archivos al ordenador.

    Los archivos se consultan cuando se necesitan.

    Por ejemplo:

    • Si abres un documento, se descargará temporalmente para poder leerlo.
    • Si copias un archivo desde Google Drive a otra carpeta local, entonces sí se descargará.
    • Si copias un archivo desde Ubuntu hacia ~/GoogleDrive, se subirá a Google Drive.
    • Si no abres un archivo, no ocupa espacio real en tu disco como una sincronización completa.

    11. Desmontar Google Drive

    Cuando queramos desmontar la unidad, usamos:

    fusermount3 -u ~/GoogleDrive

    Después de esto, la carpeta ~/GoogleDrive seguirá existiendo, pero ya no mostrará el contenido de Google Drive.

    Para comprobarlo:

    ls ~/GoogleDrive

    Si está desmontada, normalmente aparecerá vacía.


    12. Montaje automático al iniciar sesión

    Hasta ahora hemos montado Google Drive manualmente.

    Si queremos que se monte automáticamente al iniciar sesión en Ubuntu, podemos crear un servicio de usuario con systemd.


    12.1. Crear carpeta para servicios de usuario

    Ejecutamos:

    mkdir -p ~/.config/systemd/user

    12.2. Crear el archivo del servicio

    Creamos el archivo:

    nano ~/.config/systemd/user/rclone-gdrive.service

    Pegamos el siguiente contenido.

    Importante: cambia antonio por el nombre real de tu usuario en Ubuntu.

    [Unit]
    Description=Montar Google Drive con rclone
    After=network-online.target

    [Service]
    Type=simple
    ExecStart=/usr/bin/rclone mount gdrive: /home/antonio/GoogleDrive --vfs-cache-mode writes
    ExecStop=/bin/fusermount3 -u /home/antonio/GoogleDrive
    Restart=on-failure
    RestartSec=10

    [Install]
    WantedBy=default.target

    Guardamos el archivo:

    • Ctrl + O
    • Enter
    • Ctrl + X

    12.3. Activar el servicio

    Recargamos los servicios de usuario:

    systemctl --user daemon-reload

    Activamos el servicio para que arranque automáticamente:

    systemctl --user enable rclone-gdrive

    Iniciamos el servicio:

    systemctl --user start rclone-gdrive

    12.4. Comprobar el estado del servicio

    Ejecutamos:

    systemctl --user status rclone-gdrive

    Si todo está bien, deberíamos ver algo parecido a:

    Active: active (running)

    Para salir de la pantalla de estado, pulsamos:

    q

    13. Detener el montaje automático

    Si queremos parar el servicio temporalmente:

    systemctl --user stop rclone-gdrive

    Si queremos desactivarlo para que no arranque automáticamente:

    systemctl --user disable rclone-gdrive

    14. Posibles errores y soluciones

    Error: la carpeta parece vacía

    Primero comprueba si el montaje está activo:

    systemctl --user status rclone-gdrive

    O prueba a montar manualmente:

    rclone mount gdrive: ~/GoogleDrive --vfs-cache-mode writes --daemon

    Error: transport endpoint is not connected

    A veces puede quedarse un montaje bloqueado.

    Solución:

    fusermount3 -u ~/GoogleDrive

    Si no funciona:

    fusermount3 -uz ~/GoogleDrive

    Después vuelve a montar:

    rclone mount gdrive: ~/GoogleDrive --vfs-cache-mode writes --daemon

    Error: command not found

    Si aparece:

    rclone: command not found

    Significa que rclone no está instalado.

    Instálalo con:

    sudo apt install rclone

    Error: fusermount3 no encontrado

    Instala fuse3:

    sudo apt install fuse3

    Error en el servicio por el nombre de usuario

    Si el servicio no arranca, revisa esta parte:

    ExecStart=/usr/bin/rclone mount gdrive: /home/antonio/GoogleDrive --vfs-cache-mode writes
    ExecStop=/bin/fusermount3 -u /home/antonio/GoogleDrive

    Debes cambiar antonio por tu usuario real.

    Puedes saber tu usuario con:

    whoami

    Y tu ruta personal con:

    echo $HOME

    15. Comandos principales de la práctica

    AcciónComando
    Instalar rclonesudo apt install rclone fuse3
    Configurar Google Driverclone config
    Ver carpetas de Driverclone lsd gdrive:
    Crear carpeta de montajemkdir -p ~/GoogleDrive
    Montar Driverclone mount gdrive: ~/GoogleDrive --vfs-cache-mode writes --daemon
    Desmontar Drivefusermount3 -u ~/GoogleDrive
    Ver estado del serviciosystemctl --user status rclone-gdrive
    Iniciar serviciosystemctl --user start rclone-gdrive
    Parar serviciosystemctl --user stop rclone-gdrive

    16. Ejercicio propuesto para el alumno

    Realiza los siguientes pasos y documenta el proceso:

    1. Instala rclone en Ubuntu.
    2. Configura tu cuenta de Google Drive.
    3. Crea la carpeta ~/GoogleDrive.
    4. Monta Google Drive usando rclone mount.
    5. Comprueba que puedes ver tus archivos desde el explorador.
    6. Crea una carpeta de prueba dentro de ~/GoogleDrive.
    7. Comprueba desde la web de Google Drive que la carpeta se ha creado.
    8. Desmonta Google Drive.
    9. Vuelve a montarlo manualmente.
    10. Configura el montaje automático con systemd.

    17. Preguntas de repaso

    1. ¿Qué diferencia hay entre sincronizar Google Drive y montarlo como unidad?
    2. ¿Para qué sirve rclone?
    3. ¿Qué significa gdrive: en los comandos usados?
    4. ¿Dónde se monta Google Drive en esta práctica?
    5. ¿Qué comando se usa para desmontar la unidad?
    6. ¿Qué ventaja tiene usar systemd en esta práctica?
    7. ¿Se descargan todos los archivos de Google Drive al montar la unidad?
    8. ¿Qué ocurre si copiamos un archivo dentro de ~/GoogleDrive?

    18. Conclusión

    En esta práctica hemos montado Google Drive en Ubuntu como una carpeta local usando rclone.

    La ventaja principal de este método es que podemos trabajar con nuestros archivos de Google Drive desde Ubuntu sin tener que sincronizar todo el contenido en el disco duro.

    Esto resulta muy útil en equipos con poco almacenamiento, máquinas virtuales, portátiles o entornos de laboratorio donde necesitamos acceso a archivos en la nube sin ocupar espacio innecesario.

    Además, al configurar el montaje automático mediante systemd, conseguimos que Google Drive esté disponible cada vez que iniciemos sesión en Ubuntu.

  • Instalación de Ollama en Windows paso a paso

    Instalación de Ollama en Windows paso a paso

    1. Introducción

    En esta práctica vamos a instalar Ollama en un equipo con Windows para poder ejecutar modelos de inteligencia artificial de forma local.

    Ollama permite descargar y ejecutar modelos como Llama, Qwen, Mistral u otros modelos compatibles directamente en nuestro ordenador, sin depender necesariamente de servicios externos.

    Esto es especialmente interesante en clase porque nos permite trabajar conceptos como:

    • Inteligencia artificial local.
    • Modelos de lenguaje.
    • Uso de la terminal.
    • Consumo de CPU, RAM y GPU.
    • Servicios accesibles desde red local.
    • Integración con herramientas como Open WebUI, OpenCode o aplicaciones propias.

    2. Requisitos previos

    Para realizar esta práctica necesitaremos:

    • Un equipo con Windows 10 o Windows 11.
    • Conexión a Internet.
    • Permisos para instalar programas.
    • PowerShell o Terminal de Windows.
    • Espacio suficiente en disco para descargar modelos.

    Según la página oficial de Ollama, la versión para Windows requiere Windows 10 o posterior.


    3. ¿Qué vamos a instalar?

    Vamos a instalar:

    Ollama para Windows

    Una vez instalado, podremos ejecutar comandos como:

    ollama --version
    ollama pull llama3.1:8b
    ollama run llama3.1:8b

    Paso 1. Descargar Ollama para Windows

    Entramos en la página oficial de descarga de Ollama:

    https://ollama.com/download/windows

    En la página oficial aparece la opción de descarga para Windows y también una instalación mediante PowerShell.

    Podemos instalarlo de dos formas:

    Opción A: Instalación con instalador gráfico

    Esta es la opción más sencilla para alumnos que empiezan.

    1. Entramos en la web oficial de Ollama.
    2. Seleccionamos la versión de Windows.
    3. Descargamos el instalador.
    4. Ejecutamos el archivo descargado.
    5. Seguimos el asistente de instalación.

    Cuando termine, Ollama debería quedar instalado en el sistema.


    Opción B: Instalación desde PowerShell

    También podemos instalar Ollama usando PowerShell.

    Abrimos PowerShell y ejecutamos:

    irm https://ollama.com/install.ps1 | iex

    Este comando aparece actualmente en la página oficial de descarga de Ollama para Windows.


    Paso 2. Comprobar que Ollama está instalado

    Abrimos una terminal de PowerShell y ejecutamos:

    ollama --version

    Si todo está correcto, veremos una salida parecida a esta:

    ollama version x.x.x

    La versión puede cambiar según el momento en el que se instale.


    Paso 3. Comprobar que el servicio responde

    Ollama funciona como una aplicación/servicio local que escucha normalmente en el puerto:

    11434

    Podemos comprobarlo con:

    curl http://localhost:11434/api/tags

    Si todavía no tenemos modelos instalados, puede aparecer una lista vacía o una respuesta JSON sin modelos.

    Ejemplo aproximado:

    {
    "models": []
    }

    Paso 4. Descargar un primer modelo

    Ahora vamos a descargar un modelo pequeño o mediano para probar.

    Para empezar podemos usar:

    ollama pull llama3.1:8b

    También podríamos usar un modelo orientado a programación, por ejemplo:

    ollama pull qwen2.5-coder:7b

    La descarga puede tardar varios minutos, dependiendo de la conexión a Internet y del tamaño del modelo.


    Paso 5. Ejecutar un modelo

    Una vez descargado el modelo, podemos ejecutarlo con:

    ollama run llama3.1:8b

    Aparecerá un prompt interactivo donde podremos escribir preguntas.

    Por ejemplo:

    >>> Explícame qué es una dirección IP como si fuera para un alumno de primero de ASIR.

    Ollama responderá usando el modelo cargado en local.

    Para salir del chat podemos escribir:

    /bye

    Paso 6. Ver los modelos instalados

    Para ver qué modelos tenemos descargados:

    ollama list

    La salida será parecida a:

    NAME              ID              SIZE      MODIFIED
    llama3.1:8b xxxxxxxx 4.7 GB ...
    qwen2.5-coder:7b xxxxxxxx 4.7 GB ...

    Paso 7. Ver qué modelos están cargados en memoria

    Este paso es importante, especialmente si el ordenador también se usa para jugar, editar vídeo o realizar tareas pesadas.

    Ejecutamos:

    ollama ps

    Este comando muestra los modelos que están cargados en ese momento.

    Ejemplo:

    NAME              ID              SIZE      PROCESSOR    UNTIL
    llama3.1:8b xxxxxxxx 4.7 GB 100% GPU 4 minutes from now

    Paso 8. Detener un modelo cargado

    Si queremos liberar memoria, podemos detener un modelo con:

    ollama stop llama3.1:8b

    O, si estamos usando otro modelo:

    ollama stop qwen2.5-coder:7b

    Esto es útil para liberar RAM o VRAM de la tarjeta gráfica.


    Paso 9. Borrar un modelo

    Si queremos eliminar un modelo descargado para liberar espacio en disco:

    ollama rm llama3.1:8b

    Después podemos comprobar de nuevo:

    ollama list

    Paso 10. Probar Ollama desde el navegador

    Podemos abrir en el navegador:

    http://localhost:11434

    También podemos probar directamente la API:

    http://localhost:11434/api/tags

    El endpoint /api/tags permite comprobar los modelos disponibles en la instalación local.


    Paso 11. Crear una petición a la API de Ollama

    Ollama no solo sirve para usar modelos desde terminal. También podemos hacer peticiones HTTP a su API local.

    Ejemplo desde PowerShell:

    curl http://localhost:11434/api/generate `
    -Method POST `
    -Body '{"model":"llama3.1:8b","prompt":"Explica qué es Linux en pocas palabras.","stream":false}' `
    -ContentType "application/json"

    Esto nos devolverá una respuesta en formato JSON.


    Paso 12. Configurar Ollama para acceder desde otro equipo de la red

    Por defecto, Ollama suele estar pensado para usarse desde el propio equipo. Si queremos acceder desde otro ordenador de la red local, por ejemplo desde un portátil, podemos configurar la variable de entorno:

    OLLAMA_HOST

    La documentación oficial de Ollama indica que en Windows las variables de entorno se pueden configurar desde las opciones de entorno del usuario o del sistema. Para ello recomienda cerrar primero Ollama desde la barra de tareas, abrir la configuración de variables de entorno, crear o editar la variable correspondiente y volver a iniciar Ollama.

    Configuración recomendada para red local

    Creamos la variable:

    OLLAMA_HOST

    Con el valor:

    0.0.0.0:11434

    También se puede hacer desde PowerShell como administrador:

    setx OLLAMA_HOST "0.0.0.0:11434" /M

    Después debemos cerrar Ollama y volver a abrirlo, o reiniciar el equipo.


    Paso 13. Abrir el puerto en el firewall de Windows

    Si queremos acceder a Ollama desde otro ordenador de la misma red, puede ser necesario abrir el puerto 11434.

    Abrimos PowerShell como administrador y ejecutamos:

    New-NetFirewallRule `
    -DisplayName "Ollama 11434" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 11434 `
    -Action Allow

    Paso 14. Averiguar la IP del equipo Windows

    En el equipo donde está instalado Ollama ejecutamos:

    ipconfig

    Buscamos la dirección IPv4 de la tarjeta de red que estamos usando.

    Ejemplo:

    Dirección IPv4. . . . . . . . . . . . . . : 192.168.1.50

    En este ejemplo, la IP del equipo sería:

    192.168.1.50

    Paso 15. Probar Ollama desde otro ordenador

    Desde otro equipo de la misma red, por ejemplo un portátil, probamos:

    curl http://192.168.1.50:11434/api/tags

    Cambiando 192.168.1.50 por la IP real del equipo Windows.

    Si todo está correcto, veremos la lista de modelos disponibles.


    Paso 16. Conectar Open WebUI u otra herramienta

    Si instalamos una interfaz web como Open WebUI, podremos conectarla a la dirección del servidor Ollama.

    Si Open WebUI está en el mismo equipo:

    http://localhost:11434

    Si Open WebUI está en otro ordenador de la red:

    http://192.168.1.50:11434

    Paso 17. Recomendaciones de modelos para empezar

    Para equipos normales:

    ollama pull llama3.1:8b
    ollama pull qwen2.5-coder:7b

    Para equipos con buena GPU:

    ollama pull qwen2.5-coder:14b
    ollama pull qwen3:14b

    Para programación:

    ollama run qwen2.5-coder:7b

    O, si el equipo tiene más potencia:

    ollama run qwen2.5-coder:14b

    Para uso general:

    ollama run llama3.1:8b

    Paso 18. Buenas prácticas si el equipo también se usa para jugar

    Si el ordenador tiene una tarjeta gráfica potente y también se usa para jugar, conviene tener cuidado.

    Ollama puede usar:

    • RAM.
    • CPU.
    • GPU.
    • VRAM de la tarjeta gráfica.
    • Disco.

    Instalar Ollama no debería reducir el rendimiento de los juegos por sí solo. El problema aparece cuando tenemos un modelo cargado mientras jugamos.

    Antes de jugar podemos comprobar:

    ollama ps

    Si aparece algún modelo cargado, podemos detenerlo:

    ollama stop nombre_del_modelo

    Por ejemplo:

    ollama stop qwen2.5-coder:14b

    También podemos cerrar Ollama desde el icono de la bandeja del sistema.


    Paso 19. Seguridad básica

    No debemos exponer Ollama directamente a Internet.

    Una cosa es usarlo dentro de nuestra red local y otra muy distinta dejarlo accesible públicamente desde fuera.

    Recomendaciones:

    • No abrir el puerto 11434 en el router.
    • No hacer redirección de puertos hacia Ollama.
    • Usarlo solo en red local.
    • Si se necesita acceso remoto, usar VPN o una solución segura.
    • No permitir que cualquier persona de la red use modelos grandes sin control.

    Paso 20. Comandos principales de Ollama

    AcciónComando
    Ver versiónollama --version
    Descargar modeloollama pull nombre_modelo
    Ejecutar modeloollama run nombre_modelo
    Ver modelos instaladosollama list
    Ver modelos cargadosollama ps
    Detener modeloollama stop nombre_modelo
    Borrar modeloollama rm nombre_modelo
    Probar API localcurl http://localhost:11434/api/tags

    Actividad propuesta

    Instalar Ollama en Windows, descargar un modelo, ejecutarlo y comprobar que funciona correctamente desde terminal y desde la API local.

    Tareas

    1. Instalar Ollama en Windows.
    2. Comprobar la versión instalada.
    3. Descargar un modelo.
    4. Ejecutar el modelo desde terminal.
    5. Hacerle al modelo una pregunta técnica.
    6. Listar los modelos instalados.
    7. Comprobar qué modelos están cargados.
    8. Probar la API local con curl.
    9. Documentar el proceso con capturas.
    10. Explicar qué recursos del equipo consume Ollama.

    Cargar modelos de ollama en el disco duro secundario

    Importante:
    Los modelos de Ollama pueden ocupar muchos gigabytes. En equipos con un disco principal pequeño, es recomendable guardar los modelos en un disco secundario usando la variable de entorno OLLAMA_MODELS. Así evitamos llenar la unidad C: y mantenemos el sistema operativo con espacio libre suficiente.

    la forma correcta para Windows, que es mover la carpeta de modelos usando la variable OLLAMA_MODELS. También voy a incluir una alternativa con enlace simbólico, útil si ya tienes modelos descargados.Pensó durante 4s

    Sí. En Windows tienes que cambiar la ubicación de los modelos con la variable de entorno OLLAMA_MODELS. Ollama indica oficialmente que esta variable sirve para elegir dónde se guardan los modelos descargados.

    Por ejemplo, si quieres que los modelos estén en el disco D:, puedes crear esta carpeta:

    D:\Ollama\Models

    Opción recomendada: usar OLLAMA_MODELS

    1. Crea la carpeta en el disco secundario

    En PowerShell:

    mkdir D:\Ollama\Models

    Puedes cambiar D: por la letra real de tu disco.


    2. Cierra Ollama

    Antes de cambiar la ruta:

    1. Ve al icono de Ollama en la bandeja del sistema, junto al reloj.
    2. Clic derecho.
    3. Pulsa Quit o Salir.

    También puedes cerrar el proceso desde PowerShell:

    taskkill /IM ollama.exe /F

    3. Crea la variable de entorno

    Abre PowerShell como administrador y ejecuta:

    setx OLLAMA_MODELS "D:\Ollama\Models" /M

    Esto crea la variable a nivel de sistema.

    También podrías crearla solo para tu usuario:

    setx OLLAMA_MODELS "D:\Ollama\Models"

    Para un PC personal, yo usaría la opción con /M.


    4. Reinicia Ollama

    Después de crear la variable:

    • Cierra todas las terminales.
    • Vuelve a abrir PowerShell.
    • Abre Ollama de nuevo desde el menú de inicio.

    Para ir a lo seguro, reinicia Windows.


    5. Comprueba que la variable existe

    En una nueva ventana de PowerShell:

    echo $env:OLLAMA_MODELS

    Debería aparecer:

    D:\Ollama\Models

    6. Descarga un modelo de prueba

    Por ejemplo:

    ollama pull llama3.1:8b

    Después comprueba que se han creado archivos dentro de:

    D:\Ollama\Models

    Si ya tenías modelos descargados

    Por defecto, Ollama suele guardar los modelos en la carpeta del usuario, dentro de:

    C:\Users\TU_USUARIO\.ollama

    La documentación oficial también indica que %HOMEPATH%\.ollama contiene modelos y configuración.

    Puedes moverlos así:

    1. Cierra Ollama

    taskkill /IM ollama.exe /F

    2. Copia la carpeta antigua al nuevo disco

    Por ejemplo:

    robocopy "$env:USERPROFILE\.ollama\models" "D:\Ollama\Models" /E

    3. Crea la variable OLLAMA_MODELS

    setx OLLAMA_MODELS "D:\Ollama\Models" /M

    4. Reinicia Windows

    Después prueba:

    ollama list

    Si los modelos aparecen correctamente, ya está usando la nueva ubicación.


  • Instalación y uso de OpenCode en Windows con WSL Ubuntu

    Instalación y uso de OpenCode en Windows con WSL Ubuntu

    1. Introducción

    OpenCode es una herramienta de asistencia al desarrollo mediante inteligencia artificial. Permite trabajar con proyectos de programación desde la terminal, hacer preguntas sobre el código, pedir cambios, generar archivos, revisar errores y trabajar con diferentes proveedores de modelos de IA.

    Aunque OpenCode puede instalarse de varias formas, en Windows la opción más recomendable para trabajar de manera seria es usarlo dentro de WSL, es decir, el Subsistema de Windows para Linux. De esta forma trabajaremos con un entorno Linux real dentro de Windows, algo muy útil para programación, servidores, automatización y administración de sistemas.

    OpenCode está disponible como herramienta de terminal, aplicación de escritorio e incluso extensiones para editores como Visual Studio Code. La versión de escritorio está disponible en beta para Windows x64.


    Objetivos de la práctica

    Al finalizar esta práctica, el alumno será capaz de:

    • Instalar WSL en Windows.
    • Instalar Ubuntu dentro de WSL.
    • Instalar OpenCode en el entorno Linux.
    • Abrir un proyecto con Visual Studio Code usando Remote WSL.
    • Ejecutar OpenCode desde la terminal del proyecto.
    • Conectar OpenCode con un proveedor de IA.
    • Comprender la diferencia entre usar OpenCode en terminal, escritorio o navegador.

    Requisitos previos

    Para realizar esta práctica necesitaremos:

    • Un equipo con Windows 10 o Windows 11.
    • Conexión a Internet.
    • Permisos de administrador en Windows.
    • Visual Studio Code instalado.
    • Una cuenta o clave de acceso para algún proveedor de IA compatible, por ejemplo OpenAI, GitHub Copilot, OpenRouter, Anthropic, Google Gemini u otro proveedor compatible.

    OpenCode necesita un proveedor de modelos de lenguaje para funcionar. La herramienta puede ser gratuita, pero el uso del modelo puede depender del proveedor elegido.


    Paso 1. Instalar WSL en Windows

    Abrimos PowerShell como administrador.

    Para ello:

    1. Pulsamos en el menú de inicio.
    2. Escribimos PowerShell.
    3. Hacemos clic derecho.
    4. Seleccionamos Ejecutar como administrador.

    Después ejecutamos:

    wsl --install

    Este comando instalará WSL y, normalmente, también una distribución Ubuntu por defecto.

    Cuando finalice la instalación, reiniciamos el equipo si Windows lo solicita.


    Paso 2. Comprobar que WSL funciona

    Después del reinicio, abrimos una terminal de Ubuntu desde el menú de inicio.

    Buscamos:

    Ubuntu

    Si no lo vemos, probamos lo siguiente:

    Ejecuta:

    wsl --list --online

    Esto te mostrará las distribuciones disponibles.


    Instala Ubuntu manualmente

    Ejecuta:

    wsl --install -d Ubuntu

    Reinicia el ordenador si te lo pide.

    Si al reinicar aun no aparece, vuelve a poner

    wsl --install -d Ubuntu

    Comprueba qué distribuciones tienes instaladas

    Después abre PowerShell normal y ejecuta:

    wsl -l -v

    Deberías ver algo parecido a:

      NAME      STATE           VERSION
    * Ubuntu Stopped 2

    Si aparece Ubuntu, puedes abrirlo con:

    wsl

    o también:

    ubuntu

    La primera vez que se abra, Ubuntu nos pedirá crear un usuario y una contraseña.

    Por ejemplo:

    Enter new UNIX username: alumno
    New password:
    Retype new password:

    La contraseña no se verá mientras la escribimos. Esto es normal en Linux.


    Paso 3. Actualizar Ubuntu

    Dentro de la terminal de Ubuntu ejecutamos:

    sudo apt update
    sudo apt upgrade -y

    Con esto actualizamos la lista de paquetes y los programas instalados.

    Es importante hacer este paso antes de instalar herramientas de desarrollo.


    Paso 4. Instalar herramientas básicas

    Instalamos algunas herramientas útiles:

    sudo apt install -y curl git unzip

    Estas herramientas nos permitirán descargar archivos, trabajar con repositorios y preparar proyectos.


    Paso 5. Instalar OpenCode dentro de WSL

    La documentación oficial de OpenCode recomienda instalarlo en WSL para trabajar desde Windows. Una vez dentro de la terminal de Ubuntu, ejecutamos el instalador oficial:

    curl -fsSL https://opencode.ai/install | bash

    Cuando termine la instalación, cerramos y volvemos a abrir la terminal de Ubuntu.

    Después comprobamos que OpenCode está instalado:

    opencode --version

    Si aparece una versión, la instalación ha funcionado correctamente.


    Paso 6. Crear una carpeta de trabajo

    Vamos a crear una carpeta para nuestros proyectos dentro del entorno Linux.

    mkdir -p ~/proyectos
    cd ~/proyectos

    Ahora podemos crear un proyecto de prueba:

    mkdir prueba-opencode
    cd prueba-opencode

    Creamos un archivo simple:

    nano index.html

    Pegamos este contenido:

    <!DOCTYPE html>
    <html lang="es">
    <head>
    <meta charset="UTF-8">
    <title>Prueba OpenCode</title>
    </head>
    <body>
    <h1>Hola desde OpenCode</h1>
    <p>Este es mi primer proyecto usando OpenCode en WSL.</p>
    </body>
    </html>

    Guardamos con:

    CTRL + O
    Enter
    CTRL + X

    Paso 7. Ejecutar OpenCode en el proyecto

    Desde la carpeta del proyecto ejecutamos:

    opencode

    OpenCode se iniciará en la terminal.

    La primera vez puede solicitar configuración o conexión con un proveedor de IA.

    Dentro de OpenCode podemos usar comandos como:

    /connect

    Este comando permite conectar OpenCode con un proveedor de modelos de IA.

    Dependiendo del proveedor elegido, puede pedir una clave API, iniciar sesión o configurar una cuenta.


    Paso 8. Primeras pruebas con OpenCode

    Una vez abierto OpenCode dentro del proyecto, podemos pedirle tareas sencillas.

    Por ejemplo:

    Explícame qué hace este proyecto.

    También podemos pedirle mejoras:

    Mejora el archivo index.html añadiendo una estructura básica con cabecera, contenido principal y pie de página.

    O podemos pedirle que cree nuevos archivos:

    Crea un archivo styles.css y enlázalo desde index.html.

    OpenCode puede ayudar a escribir, modificar y revisar código, pero el alumno siempre debe revisar los cambios antes de aceptarlos. La IA puede equivocarse, generar código innecesario o modificar partes que no debería.


    Paso 9. Instalar Visual Studio Code

    Si no lo tenemos instalado, descargamos e instalamos Visual Studio Code desde su página oficial.

    Una vez instalado, abrimos Visual Studio Code.


    Paso 10. Instalar la extensión Remote WSL

    En Visual Studio Code:

    1. Vamos a la sección Extensions.
    2. Buscamos:
    WSL
    1. Instalamos la extensión oficial de Microsoft llamada WSL.

    Esta extensión permite abrir carpetas de Linux/WSL directamente desde Visual Studio Code.


    Paso 11. Abrir el proyecto desde WSL en Visual Studio Code

    Volvemos a la terminal de Ubuntu y nos situamos en nuestro proyecto:

    cd ~/proyectos/prueba-opencode

    Ejecutamos:

    code .

    La primera vez puede tardar un poco, porque Visual Studio Code instalará algunos componentes dentro de WSL.

    Cuando se abra Visual Studio Code, veremos que estamos trabajando dentro del entorno WSL.

    Esto es importante: aunque estamos usando una aplicación gráfica de Windows, el proyecto realmente está dentro de Ubuntu.


    Paso 12. Abrir una terminal integrada en Visual Studio Code

    Dentro de Visual Studio Code:

    1. Vamos al menú Terminal.
    2. Pulsamos New Terminal.
    3. Comprobamos que la terminal abierta es de Ubuntu/WSL.

    Podemos probarlo ejecutando:

    pwd

    Debería aparecer una ruta parecida a:

    /home/alumno/proyectos/prueba-opencode

    Ahora podemos lanzar OpenCode directamente desde la terminal integrada:

    opencode

    Esta forma de trabajar es muy cómoda porque tenemos:

    • El editor Visual Studio Code.
    • El proyecto abierto.
    • La terminal Linux.
    • OpenCode trabajando sobre la carpeta real del proyecto.

    Paso 13. Acceder a proyectos de Windows desde WSL

    Aunque es recomendable guardar los proyectos dentro de Linux, también podemos acceder a carpetas de Windows desde WSL.

    Por ejemplo, el disco C: de Windows aparece en WSL como:

    /mnt/c/

    Ejemplo:

    cd /mnt/c/Users/TuUsuario/Desktop

    El disco D: aparecería como:

    /mnt/d/

    Y así sucesivamente.

    La documentación oficial de OpenCode indica que desde WSL podemos navegar a proyectos de Windows usando rutas como /mnt/c/Users/YourName/project y ejecutar allí opencode.

    Aun así, para proyectos de programación es mejor trabajar dentro de:

    /home/usuario/proyectos

    Suele dar menos problemas de permisos, rendimiento y compatibilidad.


    Paso 14. Usar la versión web de OpenCode desde WSL

    OpenCode también puede ejecutarse como interfaz web en el navegador. La documentación oficial recomienda que, en Windows, se ejecute desde WSL para mantener buen acceso al sistema de archivos y a la terminal.

    Desde la carpeta del proyecto podemos ejecutar:

    opencode web --hostname 0.0.0.0

    OpenCode mostrará una dirección local en la terminal.

    Después podremos abrirla desde el navegador de Windows.

    Normalmente será algo parecido a:

    http://localhost:PUERTO

    donde PUERTO será el número que indique OpenCode.


    Paso 15. Usar la aplicación de escritorio de OpenCode

    OpenCode también tiene una aplicación de escritorio en beta para Windows x64.

    La idea sería:

    1. Instalar OpenCode Desktop para Windows.
    2. Ejecutar el servidor de OpenCode dentro de WSL.
    3. Conectar la aplicación de escritorio al servidor local.

    Desde WSL podemos lanzar el servidor con:

    opencode serve --hostname 0.0.0.0 --port 4096

    Después, desde la aplicación de escritorio, nos conectaríamos a:

    http://localhost:4096

    Si localhost no funciona, podemos obtener la IP de WSL con:

    hostname -I

    Y conectarnos usando una dirección parecida a:

    http://IP-DE-WSL:4096

    La documentación oficial advierte que, si usamos --hostname 0.0.0.0, conviene proteger el servidor con contraseña mediante la variable OPENCODE_SERVER_PASSWORD.

    Ejemplo:

    OPENCODE_SERVER_PASSWORD=clave-segura opencode serve --hostname 0.0.0.0 --port 4096

    Paso 16. Recomendación para clase

    Para esta práctica vamos a trabajar principalmente de esta forma:

    Windows + WSL Ubuntu + Visual Studio Code + OpenCode en terminal

    Es decir:

    1. Usamos Windows como sistema principal.
    2. Usamos Ubuntu mediante WSL como entorno de desarrollo.
    3. Abrimos los proyectos con Visual Studio Code usando Remote WSL.
    4. Ejecutamos OpenCode desde la terminal del proyecto.

    Esta forma de trabajo es muy parecida a un entorno profesional real, porque muchos servidores, herramientas de desarrollo y sistemas de despliegue funcionan sobre Linux.


    Paso 17. Comandos resumen

    Instalar WSL

    wsl --install

    Actualizar Ubuntu

    sudo apt update
    sudo apt upgrade -y

    Instalar herramientas básicas

    sudo apt install -y curl git unzip

    Instalar OpenCode

    curl -fsSL https://opencode.ai/install | bash

    Comprobar versión

    opencode --version

    Crear proyecto

    mkdir -p ~/proyectos/prueba-opencode
    cd ~/proyectos/prueba-opencode

    Abrir Visual Studio Code desde WSL

    code .

    Ejecutar OpenCode

    opencode

    Ejecutar OpenCode Web

    opencode web --hostname 0.0.0.0

    Ejecutar servidor para escritorio

    opencode serve --hostname 0.0.0.0 --port 4096

    Problemas frecuentes

    El comando opencode no se reconoce

    Cerramos y volvemos a abrir la terminal de Ubuntu.

    También podemos probar:

    source ~/.bashrc

    Después:

    opencode --version

    El comando code . no funciona

    Puede deberse a que Visual Studio Code no está instalado correctamente o no está disponible en el PATH.

    Solución:

    1. Abrir Visual Studio Code en Windows.
    2. Instalar la extensión WSL.
    3. Volver a abrir Ubuntu.
    4. Probar de nuevo:
    code .

    OpenCode no puede conectarse al proveedor de IA

    Revisamos:

    • Que tenemos conexión a Internet.
    • Que la clave API es correcta.
    • Que hemos usado el comando /connect.
    • Que el proveedor elegido está disponible.
    • Que la cuenta tiene saldo, suscripción o permisos suficientes.

    Estoy en PowerShell y no en Ubuntu

    OpenCode para esta práctica debe ejecutarse dentro de Ubuntu/WSL.

    Si estamos en PowerShell, veremos algo parecido a:

    PS C:\Users\Alumno>

    Si estamos en Ubuntu/WSL, veremos algo parecido a:

    alumno@equipo:~$

    Para entrar en Ubuntu, abrimos la aplicación Ubuntu desde el menú de inicio.


    Actividad propuesta para el alumno

    Crea un pequeño proyecto web con estos archivos:

    index.html
    styles.css
    script.js

    El proyecto debe tener:

    • Una página principal con título.
    • Un párrafo explicando qué es OpenCode.
    • Un botón creado con HTML.
    • Estilos básicos en CSS.
    • Un pequeño mensaje en JavaScript al pulsar el botón.

    Después abre OpenCode desde la carpeta del proyecto y pídele:

    Revisa este proyecto y propón mejoras sencillas para un alumno que está empezando.

    A continuación, el alumno deberá entregar:

    • Captura de WSL funcionando.
    • Captura de opencode --version.
    • Captura de Visual Studio Code abierto con Remote WSL.
    • Captura de OpenCode ejecutándose en la terminal del proyecto.
    • Breve explicación de qué ventajas tiene trabajar con WSL en Windows.

    Conclusión

    OpenCode puede utilizarse directamente en Windows, pero para un entorno de clase y de desarrollo técnico es más recomendable utilizarlo dentro de WSL con Ubuntu.

    De esta manera conseguimos un entorno más parecido al que encontraremos en servidores reales, con mejor integración con herramientas Linux y con una forma de trabajo muy útil para programación, administración de sistemas, ciberseguridad y automatización.

    La combinación recomendada para el curso será:

    Windows + WSL Ubuntu + Visual Studio Code Remote WSL + OpenCode
  • Práctica guiada: Instalación de Cypht en Ubuntu Server con Docker

    Práctica guiada: Instalación de Cypht en Ubuntu Server con Docker

    1. Introducción

    En esta práctica vamos a instalar Cypht en una máquina Ubuntu Server.

    Cypht es una aplicación web que permite consultar varias cuentas de correo desde una única interfaz. A diferencia de otros clientes webmail más clásicos, Cypht está pensado para actuar como un agregador de cuentas de correo, por lo que resulta especialmente útil cuando queremos gestionar varias direcciones desde el navegador.

    Durante la práctica utilizaremos Docker y Docker Compose, ya que esto nos permite instalar Cypht junto con su base de datos de una forma más limpia, controlada y fácil de mantener.


    2. Objetivos de la práctica

    Al finalizar esta práctica, el alumno será capaz de:

    • Crear una máquina virtual Ubuntu Server.
    • Instalar Docker en Ubuntu Server.
    • Usar Docker Compose para desplegar varios servicios.
    • Instalar Cypht junto con MariaDB.
    • Acceder a Cypht desde un navegador web.
    • Comprender el funcionamiento básico de un servicio web desplegado con contenedores.
    • Solucionar errores habituales relacionados con permisos de Docker.

    3. Escenario de la práctica

    Vamos a crear el siguiente entorno:

    Navegador del alumno
    |
    v
    http://IP_DEL_SERVIDOR:8085
    |
    v
    Ubuntu Server
    |
    +-- Contenedor Cypht
    |
    +-- Contenedor MariaDB

    Cypht será la aplicación web y MariaDB almacenará la configuración y los datos necesarios.


    4. Requisitos previos

    Para realizar esta práctica necesitamos:

    • Una máquina virtual con Ubuntu Server 24.04 o similar.
    • Acceso a Internet desde la máquina virtual.
    • Un usuario con permisos de sudo.
    • Al menos:
      • 2 CPU
      • 4 GB de RAM recomendados
      • 25 GB de disco como mínimo
    • Conocimientos básicos de terminal Linux.

    5. Configuración recomendada de la máquina virtual

    Si se trabaja con Proxmox, VirtualBox, VMware o similar, se recomienda crear la máquina con estos valores:

    RecursoValor recomendado
    Sistema operativoUbuntu Server 24.04
    CPU2 cores
    RAM4 GB
    Disco25 GB mínimo
    RedNAT o adaptador puente
    AccesoConsola o SSH

    Importante:
    Con 1 CPU y 2 GB de RAM la instalación puede funcionar, pero el sistema irá justo. Para trabajar cómodamente con Docker, Cypht y MariaDB, se recomienda usar 2 CPU y 4 GB de RAM.


    Parte 1: Preparación del sistema

    Paso 1. Actualizar el sistema

    sudo apt update

    Entramos en la máquina Ubuntu Server y actualizamos los repositorios:

    Después actualizamos los paquetes instalados:

    sudo apt upgrade -y

    Paso 2. Instalar herramientas necesarias

    Instalamos algunos paquetes que necesitaremos para añadir el repositorio oficial de Docker:

    sudo apt install -y ca-certificates curl gnupg

    Parte 2: Instalación de Docker

    Paso 3. Crear el directorio para las claves de Docker

    Ejecutamos:

    sudo install -m 0755 -d /etc/apt/keyrings

    Este directorio se usará para guardar la clave GPG del repositorio oficial de Docker.


    Paso 4. Descargar la clave GPG de Docker

    Ejecutamos:

    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
    sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

    Después damos permisos de lectura a la clave:

    sudo chmod a+r /etc/apt/keyrings/docker.gpg

    Paso 5. Añadir el repositorio oficial de Docker

    Ejecutamos el siguiente comando completo:

    echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
    https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

    Actualizamos de nuevo los repositorios:

    sudo apt update

    Paso 6. Instalar Docker y Docker Compose

    Instalamos Docker:

    sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

    Comprobamos que Docker se ha instalado correctamente:

    docker --version

    Y comprobamos Docker Compose:

    docker compose version

    Si los comandos muestran una versión, la instalación ha sido correcta.


    Paso 7. Comprobar el estado del servicio Docker

    Ejecutamos:

    sudo systemctl status docker

    Si aparece como active (running), Docker está funcionando.

    Podemos salir de esa pantalla pulsando:

    q

    Si Docker no estuviera activo, lo arrancamos con:

    sudo systemctl enable --now docker

    Parte 3: Preparación de Cypht

    Paso 8. Crear la carpeta de trabajo

    Crearemos la instalación en /opt/cypht.

    sudo mkdir -p /opt/cypht

    Cambiamos el propietario de la carpeta para poder trabajar cómodamente con nuestro usuario:

    sudo chown -R $USER:$USER /opt/cypht

    Entramos en la carpeta:

    cd /opt/cypht

    Paso 9. Crear el archivo docker-compose.yml

    Creamos el archivo:

    nano docker-compose.yml

    Dentro pegamos el siguiente contenido:

    services:
    db:
    image: mariadb:10
    container_name: cypht-db
    restart: unless-stopped
    volumes:
    - ./data/mysql:/var/lib/mysql
    environment:
    MYSQL_ROOT_PASSWORD: Cambia_Esta_Clave_Root
    MYSQL_DATABASE: cypht
    MYSQL_USER: cypht
    MYSQL_PASSWORD: Cambia_Esta_Clave_Cypht
    healthcheck:
    test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-ucypht", "-pCambia_Esta_Clave_Cypht"]
    interval: 10s
    timeout: 5s
    retries: 5

    cypht:
    image: cypht/cypht:2.8.0
    container_name: cypht
    restart: unless-stopped
    depends_on:
    db:
    condition: service_healthy
    ports:
    - "8085:80"
    environment:
    AUTH_USERNAME: admin
    AUTH_PASSWORD: Cambia_Esta_Clave_Admin

    DB_CONNECTION_TYPE: host
    DB_DRIVER: mysql
    DB_HOST: db
    DB_NAME: cypht
    DB_USER: cypht
    DB_PASS: Cambia_Esta_Clave_Cypht

    SESSION_TYPE: DB
    USER_CONFIG_TYPE: DB
    volumes:
    - ./data/log/nginx:/var/log/nginx
    - ./data/log/php:/var/log/php
    - ./data/log/supervisord:/var/log/supervisord
    - ./data/fonts:/usr/local/share/cypht/site/fonts

    Guardamos el archivo en nano:

    Ctrl + O
    Enter
    Ctrl + X

    Paso 10. Cambiar las contraseñas

    Antes de arrancar los contenedores, debemos modificar las siguientes claves:

    Cambia_Esta_Clave_Root
    Cambia_Esta_Clave_Cypht
    Cambia_Esta_Clave_Admin

    Podemos editar el archivo de nuevo:

    nano docker-compose.yml

    Por ejemplo:

    MYSQL_ROOT_PASSWORD: Root_1234_segura
    MYSQL_PASSWORD: Cypht_1234_segura
    AUTH_PASSWORD: Admin_1234_segura
    DB_PASS: Cypht_1234_segura

    Importante:
    La contraseña MYSQL_PASSWORD y la contraseña DB_PASS deben coincidir, porque una define la contraseña del usuario de la base de datos y la otra es la contraseña que usará Cypht para conectarse a esa base de datos.


    Parte 4: Arranque de Cypht

    Paso 11. Levantar los contenedores

    Desde la carpeta /opt/cypht, ejecutamos:

    sudo docker compose up -d

    La opción -d significa que los contenedores se ejecutarán en segundo plano.


    Paso 12. Comprobar que los contenedores están funcionando

    Ejecutamos:

    sudo docker ps

    Deberíamos ver dos contenedores:

    • cypht
    • cypht-db

    Ejemplo de salida esperada:

    CONTAINER ID   IMAGE              PORTS                  NAMES
    xxxxxxxxxxxx cypht/cypht:2.8.0 0.0.0.0:8085->80/tcp cypht
    xxxxxxxxxxxx mariadb:10 3306/tcp cypht-db

    Paso 13. Ver los logs si algo falla

    Si algún contenedor no aparece o hay problemas, revisamos los logs:

    sudo docker compose logs -f

    Para salir de los logs:

    Ctrl + C

    También podemos ver solo los logs de Cypht:

    sudo docker compose logs -f cypht

    O solo los de MariaDB:

    sudo docker compose logs -f db

    Parte 5: Acceso desde el navegador

    Paso 14. Obtener la IP del servidor

    Ejecutamos:

    ip a

    Buscamos la dirección IP de la tarjeta de red principal. Suele aparecer en interfaces como:

    ens18
    ens33
    eth0
    enp0s3

    Ejemplo:

    inet 192.168.1.80/24

    En este caso, la IP sería:

    192.168.1.80

    Paso 15. Entrar en Cypht desde el navegador

    Desde el ordenador anfitrión o desde otro equipo de la misma red, abrimos:

    http://IP_DEL_SERVIDOR:8085

    Por ejemplo:

    http://192.168.1.80:8085

    El usuario será:

    admin

    La contraseña será la que hayamos puesto en:

    AUTH_PASSWORD

    Parte 6: Apertura del puerto en el firewall

    Paso 16. Comprobar si UFW está activo

    Ejecutamos:

    sudo ufw status

    Si aparece como inactive, no hace falta abrir nada.

    Si aparece como active, abrimos el puerto 8085:

    sudo ufw allow 8085/tcp

    Comprobamos de nuevo:

    sudo ufw status

    Parte 7: Añadir cuentas de correo en Cypht

    Paso 17. Datos necesarios para configurar una cuenta

    Para añadir una cuenta de correo en Cypht necesitamos conocer los datos del servidor de correo.

    Normalmente necesitaremos:

    DatoEjemplo
    Servidor IMAPmail.midominio.com
    Puerto IMAP993
    Seguridad IMAPSSL/TLS
    Usuariousuario@midominio.com
    ContraseñaContraseña del correo
    Servidor SMTPmail.midominio.com
    Puerto SMTP587
    Seguridad SMTPSTARTTLS

    Paso 18. Añadir una cuenta IMAP

    Dentro de Cypht:

    1. Entramos con el usuario admin.
    2. Accedemos a la configuración.
    3. Buscamos la sección de cuentas o servidores IMAP.
    4. Añadimos los datos de la cuenta.
    5. Guardamos la configuración.

    Ejemplo de configuración IMAP:

    Servidor IMAP: mail.midominio.com
    Puerto: 993
    Seguridad: SSL/TLS
    Usuario: usuario@midominio.com
    Contraseña: ********

    Paso 19. Añadir una cuenta SMTP

    Para poder enviar correos también debemos configurar SMTP.

    Ejemplo:

    Servidor SMTP: mail.midominio.com
    Puerto: 587
    Seguridad: STARTTLS
    Usuario: usuario@midominio.com
    Contraseña: ********

    Nota:
    En algunos proveedores de correo puede ser necesario activar el acceso por aplicaciones externas o generar una contraseña específica de aplicación.


    Parte 8: Comandos básicos de administración

    Ver contenedores activos

    sudo docker ps

    Ver todos los contenedores, incluso los detenidos

    sudo docker ps -a

    Parar Cypht

    cd /opt/cypht
    sudo docker compose down

    Arrancar Cypht de nuevo

    cd /opt/cypht
    sudo docker compose up -d

    Reiniciar los contenedores

    cd /opt/cypht
    sudo docker compose restart

    Ver logs

    cd /opt/cypht
    sudo docker compose logs -f

    Actualizar imágenes

    cd /opt/cypht
    sudo docker compose pull
    sudo docker compose up -d

    Parte 9: Error habitual de permisos con Docker

    Problema

    Puede aparecer este error:

    unable to get image 'mariadb:10': permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

    Este error significa que el usuario actual no tiene permisos para comunicarse con Docker.


    Solución rápida

    Ejecutar el comando con sudo:

    sudo docker compose up -d

    Solución permanente

    Añadimos nuestro usuario al grupo docker:

    sudo usermod -aG docker $USER

    Después reiniciamos la máquina:

    sudo reboot

    Cuando vuelva a arrancar, comprobamos:

    docker ps

    Si ya no aparece el error, podremos usar Docker sin sudo.

    Importante:
    Añadir un usuario al grupo docker le da mucho poder sobre el sistema. En un servidor real, esto debe hacerse solo con usuarios de confianza.


    Parte 10: Comprobaciones finales

    Al terminar la práctica, debemos comprobar:

    ComprobaciónResultado esperado
    Docker está instaladodocker --version muestra una versión
    Docker Compose funcionadocker compose version muestra una versión
    Los contenedores están activossudo docker ps muestra cypht y cypht-db
    Cypht responde en navegadorSe puede acceder a http://IP:8085
    El usuario admin funcionaPodemos iniciar sesión
    El puerto está abiertoEl navegador conecta correctamente
    Se puede añadir una cuenta IMAPLa cuenta aparece en Cypht
  • 3. ¿Qué es una Red Virtual?

    3. ¿Qué es una Red Virtual?

    Muchas aplicaciones y servicios precisan de una infraestructura de red formada por varios equipos conectados entre sí. Esto puede suceder tanto cuando trabajamos en producción como para pruebas de calidad o en el ámbito académico. A veces no nos resulta interesante o no compensa económicamente hacerlo con hardware y cableado real. Es por eso por lo que disponemos de la posibilidad de crear redes complejas de forma virtual, donde administraremos diferentes equipos virtuales desde un solo equipo anfitrión.

    En este apartado vamos a aprender a crear redes virtuales, ya sea para instalar servidores aislados, entornos de prueba y escenarios profesionales de forma más flexible, económica y segura.

    ¿Qué es una Red Virtual?

    En una red virtual no solo tenemos virtualizados los equipos con sistemas operativos, sino que además virtualizamos todos los elementos de la infraestructura como tarjetas de red, cables, switches y routers.

    En otras palabras, una red virtual reproduce una red real, pero lo hace dentro de un entorno virtualizado.

    Por ejemplo, vamos a imaginar que tenemos que montar un pequeño laboratorio para simular la red de una empresa, en esta red queremos configurar un servidor, comprobar que los clientes pueden acceder a las aplicaciones y servicios, detectar errores y vulnerabilidades.

    Al hacerlo mediante una red virtual podremos trabajar con un caso de uso muy próximo a la realidad, pero en un entorno más accesible y seguro para el aprendizaje.

    VLANs y Redes Virtuales

    Aunque no son exactamente lo mismo, las VLAN están muy relacionadas con la virtualización de redes. Una VLAN permite organizar la red física en varias redes independientes. En entornos virtuales podemos integrar máquinas virtuales en redes segmentadas reales o crear nuevas redes.

    Vamos a hacer una comparativa entre crear una VLAN física frente a una en Red virtual

    Ventajas

    VentajaDescripción
    FlexibilidadPermiten levantar sistemas y redes en poco tiempo.
    Ahorro de costesReducen la necesidad de hardware físico.
    EscalabilidadEs fácil ampliar el número de máquinas o segmentos de red.
    AislamientoSe pueden crear entornos seguros y separados del resto.
    ReutilizaciónUn mismo host puede albergar múltiples laboratorios o servicios. Duplicarlos, clonarlos…
    Rapidez de despliegueLos cambios se aplican mucho más rápido que en infraestructuras físicas y no tenemos que desplazarnos.

    Desventajas

    DesventajasDescripción
    Dependencia del hostSi el equipo anfitrión falla, pueden caer varias máquinas y redes a la vez.
    Posibles cuellos de botellaTodos los sistemas virtuales comparten recursos de la máquina anfitrión.
    Riesgo de mala segmentaciónUna mala configuración puede mezclar redes o exponer servicios sin querer.
    Falsa sensación de aislamientoSi no se diseña bien, una red supuestamente privada, puede terminar conectada al exterior.

    Tipos de Conexiones en Redes Virtuales

    Cuando utilizamos hipervisores como, VirtualBox, VMware, Hyper-V, Proxmox, KVM/QEMU, etc. al crear las máquinas virtuales disponemos de una o varias interfaces de red virtuales, que se comportan como tarjetas de red físicas y también Switch y routers para que interactúen entre sí.

    De tal modo que podemos simular cualquier topología de red que deseemos implementar. Existen varios tipos de red al utilizar hipervisores, las cuatro más comunes son:

    • NAT: Esta opción permite que una máquina virtual pueda acceder a internet utilizando el equipo anfitrión como router. Como ya hemos utilizado anteriormente, sirve para aislar un solo sistema de nuestra red manteniendo un acceso a internet.
    • Red NAT: Mantiene las restricciones del caso anterior NAT, pero nos permite simular más de un dispositivo pudiendo crear infraestructuras de Red complejas con acceso a internet, pero que no tengan comunicación con la red principal. Muy útiles para realizar pruebas de implantaciones que precisen de varios equipos para realizar pruebas de seguridad o calidad.
    • Adaptador puente o Bridged: Las máquinas virtuales se integran en la red física como equipos reales, son totalmente visibles al resto de la red. Conectarlas en este modo resulta útil cuando queremos ampliar algún servicio en nuestra red sin tener que implementar nuevo hardware a nuestra red.
    • Red Interna: La opción de Red Interna actúa de forma muy similar a las redes NAT donde podemos crear nuevas redes, pero en este caso sin acceso a internet. Este tipo es muy útil para laboratorios de ciberseguridad, dado que tiene un aislamiento absoluto.
    • Host-only: Esta opción es la menos versátil, pues solo permite comunicación creando un canal privado con el host o equipo anfitrión.
    Caso de Uso Para entender todo esto mucho mejor, vamos a realizar un caso de uso paso a paso. Desde el departamento de desarrollo nos han pedido que creemos una subred con tres equipos aislados del resto de la red de la empresa, pero con conexión a internet. La red contendrá dos dispositivos clientes y un servidor web Ubuntu Server con Apache2 y conexión vía SSH, para que los desarrolladores puedan realizar pruebas de funcionamiento y en encontrar posibles errores del proyecto que están realizado antes de subirlo a producción. Nos solicitan que los equipos clientes tengan diferentes sistemas operativos, uno con Ubuntu Desktop y otro con Windows.

    Para resolver la petición del departamento de desarrolladores, vamos a crear una red virtual que permita la comunicación entre tres máquinas, manteniéndolas aisladas de la red principal de la empresa, pero con acceso a Internet. Para ello utilizaremos un hipervisor como VirtualBox, aunque se podría realizar en otras plataformas de virtualización como VMWare.

    Diseño de la topología

    El primer paso será definir el tipo de red que queremos implantar. En este caso, la opción más adecuada es utilizar una Red NAT dentro de VirtualBox. Este tipo de red cumple con los requerimientos solicitados permitiendo que varias máquinas virtuales compartan una misma subred privada, puedan comunicarse entre sí y, además, tengan salida a Internet a través del equipo anfitrión.

    EquipoDirección IPMáscaraPuerta de enlace
    Ubuntu Desktop10.0.2.10255.255.255.010.0.2.1
    Windows10.0.2.11255.255.255.010.0.2.1
    Ubuntu Server10.0.2.12255.255.255.010.0.2.1

    Dentro de VirtualBox, debemos acceder al apartado de herramientas de red y crear una Red NAT nueva para las tres máquinas virtuales. Por ejemplo, podemos crear una red con estas características:

    • Nombre de la red: RedDesarrollo
    • Rango de red: 10.0.2.0/24
    Panel de configuración de Red NAT en VirtualBox

    Es importante que todas estén conectadas a la misma red virtual; de lo contrario, no podrán comunicarse entre sí.

    Partiendo de tres máquinas ya creadas y procederemos a configurar la red de cada una de ellas.

    Seleccionamos la máquina Ubuntu Desktop y en la configuración de VirtualBox. En el campo conectado a, elegimos la opción Red NAT y en el nombre de la red seleccionamos RedDesarrollo. Guardamos los cambios y pasamos a la siguiente máquina.

    Panel de configuración de adaptador de red en VirtualBox

    Repetimos el mismo procedimiento con la máquina Windows y la de Ubuntu Server poniendo en todas el tipo de Red NAT y nombre de la red RedDesarrollo.

    Ahora ya tenemos los equipos en una única red, el siguiente paso es realizar la configuración de las direcciones IPs según la tabla de la topología y realizar las pruebas para ver que todo funciona.

    Si la red NAT está funcionando correctamente, cada máquina debería obtener una dirección IP perteneciente a la misma subred.

    Por ejemplo, en los sistemas Linux podemos utilizar en la terminal el comando:

    ip a

    Y comprobamos que los equipos pertenecen a la red de redDesarrollo al tener una IP con la dirección 10.0.2.X.

    Captura de terminal Linux mostrando la IP asignada al dispositivo.

    El último paso que debemos realizar antes de entregar el despliegue sería ver si las máquinas tienen conexión entre sí y acceso a internet. Para ello desde la terminal de las diferentes máquinas realizaremos un “ping” a los dispositivos y a una IP de un servicio de internet.

    Captura de terminal Linux con resultados de la conexión

    Conclusión

    Gracias a las redes virtuales es posible segmentar servicios, aislar entornos, conectar servidores, automatizar despliegues y administrar infraestructuras complejas de forma rápida y segura. Por ello, comprender cómo se implantan y configuran no solo resulta útil para el aprendizaje, sino que constituye también una competencia esencial para trabajar en administración de sistemas, virtualización, cloud y redes empresariales modernas, para organizar entornos mucho más grandes en plataformas como Proxmox, centros de datos virtualizados o servicios en la nube como AWS.

  • 2. Sistemas Operativos de Red y Protocolos TCP/IP

    2. Sistemas Operativos de Red y Protocolos TCP/IP

    🎧 Resumen en audio del tema
    Escucha este breve audio para repasar las ideas principales de los fundamentos de redes informáticas antes de continuar o al finalizar la lectura.


    Cuando hablamos de redes informáticas, muchas veces pensamos solo en cables, routers, switches o conexión a Internet. Sin embargo, una red no funciona de verdad solo por estar físicamente conectada. Para que varios equipos puedan compartir recursos, trabajar de forma organizada y mantener la seguridad, hace falta una capa de software que controle todo ese entorno.

    Ahí es donde entran en juego los Sistemas Operativos de Red (SOR) y la familia de protocolos TCP/IP.

    Un sistema operativo de red permite administrar usuarios, equipos, permisos, recursos compartidos y servicios. Por su parte, TCP/IP proporciona el lenguaje común que utilizan los dispositivos para comunicarse, tanto dentro de una red local como a través de Internet.

    En este tema vamos a estudiar los fundamentos de ambos conceptos, viendo cómo se gestionan usuarios y accesos en entornos profesionales, cómo funcionan las redes en sistemas Microsoft y por qué TCP/IP es la base de prácticamente todas las comunicaciones actuales.


    1. El Sistema Operativo de Red (SOR)

    Un Sistema Operativo de Red es un sistema diseñado para permitir la comunicación, administración y uso compartido de recursos entre varios equipos conectados en red.

    Su misión principal es coordinar el acceso a los recursos y garantizar que los usuarios puedan trabajar de manera simultánea, ordenada y segura.

    ¿Por qué es necesario un SOR?

    Imagina una red con 20 ordenadores en un aula, oficina o empresa. Si cada equipo gestionara sus propios usuarios, sus propias contraseñas, sus propias carpetas compartidas y sus propios permisos de forma independiente, el resultado sería un auténtico caos:

    • los usuarios tendrían múltiples cuentas distintas,
    • sería difícil controlar quién accede a qué,
    • la administración sería lenta y repetitiva,
    • la seguridad sería mucho más débil.

    Un sistema operativo de red evita ese desorden, centralizando o coordinando la gestión del entorno.


    2. Tipos de sistemas operativos

    Podemos distinguir dos grandes grupos:

    2.1. Sistemas operativos de escritorio

    Son los diseñados para el uso cotidiano de un único usuario sobre un equipo concreto.

    Ejemplos:

    • Windows 10
    • Windows 11
    • Ubuntu Desktop
    • Linux Mint
    • Fedora Workstation

    Están orientados a tareas como navegación web, ofimática, reproducción multimedia o programación local.

    2.2. Sistemas operativos de servidor

    Están preparados para funcionar de manera estable durante largos periodos de tiempo, gestionando servicios, usuarios, permisos y recursos compartidos.

    Ejemplos:

    • Windows Server
    • Ubuntu Server
    • Debian Server
    • Red Hat Enterprise Linux
    • AlmaLinux

    Estos sistemas suelen utilizarse para ofrecer servicios como:

    • autenticación de usuarios,
    • almacenamiento de archivos,
    • servidores web,
    • bases de datos,
    • impresión en red,
    • copias de seguridad,
    • control de dominios.

    3. Arquitectura cliente-servidor

    En una red profesional, lo habitual es trabajar con una arquitectura cliente-servidor.

    ¿Qué significa esto?

    • Cliente: equipo o programa que solicita un recurso o servicio.
    • Servidor: equipo o programa que ofrece ese recurso o servicio.

    Por ejemplo:

    • un navegador web es cliente cuando solicita una página,
    • un servidor web entrega esa página,
    • un ordenador de aula puede actuar como cliente,
    • un servidor central puede almacenar usuarios y carpetas compartidas.

    Ventajas de este modelo

    • centraliza la administración,
    • facilita el control de usuarios y permisos,
    • mejora la seguridad,
    • permite escalar mejor la red,
    • simplifica el mantenimiento.

    Ejemplo real

    En un instituto, los alumnos pueden iniciar sesión en distintos ordenadores usando la misma cuenta de red. Eso es posible porque existe un servidor que centraliza la autenticación, los permisos y, en muchos casos, sus carpetas personales.


    4. Gestión de usuarios, derechos y accesos

    Una red profesional no puede funcionar correctamente si no está bien definida la gestión de identidades y permisos.

    No basta con que un usuario “entre” al sistema. También hay que controlar qué puede hacer, dónde puede hacerlo y hasta qué punto.


    5. Usuario vs. persona

    Es importante no confundir ambos conceptos.

    Persona

    Es el individuo real: un alumno, un profesor, un técnico, un empleado.

    Usuario

    Es la identidad digital con la que esa persona accede al sistema.

    Una misma persona puede tener:

    • una cuenta corporativa,
    • una cuenta de administrador,
    • una cuenta de pruebas,
    • o incluso no tener ninguna cuenta en un sistema concreto.

    Idea clave

    Las cuentas de usuario no deben compartirse.
    Cada acción realizada en un sistema debe poder asociarse a una identidad concreta. Esto permite:

    • mantener la trazabilidad,
    • exigir responsabilidad,
    • investigar incidencias,
    • reforzar la seguridad.

    6. Usuarios locales y usuarios de red

    Usuarios locales

    Son cuentas que existen únicamente en un equipo concreto.

    Ejemplo: un usuario creado en un PC con Windows o en una máquina Linux local.

    Características:

    • solo sirven en ese equipo,
    • no se comparten automáticamente con otros dispositivos,
    • son útiles en entornos pequeños o aislados.

    Usuarios de red

    Son cuentas almacenadas y gestionadas desde un servidor central.

    Características:

    • permiten iniciar sesión desde distintos equipos de la red,
    • centralizan la autenticación,
    • facilitan la administración,
    • son la base de los entornos profesionales.

    Comparativa rápida

    Tipo de usuarioDónde se almacenaDónde puede usarseAdministración
    LocalEn un único equipoSolo en ese equipoIndividual
    De redEn un servidor centralEn varios equipos de la redCentralizada

    7. Grupos de usuarios

    En redes medianas o grandes, asignar permisos usuario por usuario es una mala idea. Es lento, propenso a errores y difícil de mantener.

    Por eso se usan los grupos.

    ¿Qué es un grupo?

    Es una agrupación lógica de usuarios con características o necesidades similares.

    Ejemplos:

    • Alumnos
    • Profesores
    • Administración
    • Soporte
    • Dirección

    Ventajas de usar grupos

    • simplifican la gestión,
    • permiten aplicar permisos de forma masiva,
    • facilitan altas y bajas,
    • reducen errores administrativos.

    Ejemplo

    En lugar de dar permiso manual a 30 alumnos sobre una carpeta, se crea el grupo Alumnos y se asigna el permiso una sola vez a ese grupo.

    Cuando llega un nuevo alumno, basta con añadirlo al grupo.


    8. Derechos y permisos

    Aunque a veces se usan como sinónimos, no son exactamente lo mismo.

    Derechos

    Son capacidades del usuario sobre el sistema.

    Ejemplos:

    • iniciar sesión,
    • apagar el equipo,
    • administrar el sistema,
    • instalar software,
    • acceder por escritorio remoto.

    Permisos

    Son autorizaciones sobre un recurso concreto.

    Ejemplos:

    • leer un archivo,
    • modificar una carpeta,
    • ejecutar un programa,
    • borrar un documento,
    • controlar totalmente un recurso.

    Permisos más habituales

    PermisoQué permite
    LecturaVer el contenido
    EscrituraCrear o modificar
    EjecuciónEjecutar archivos o programas
    ModificaciónCambiar y borrar contenido
    Control totalGestión completa del recurso

    Herencia de permisos

    Muchos sistemas permiten que una carpeta herede permisos de su carpeta superior. Esto facilita la administración, pero también puede provocar errores si no se revisa bien.

    Ejemplo:

    • Carpeta principal: Documentos_Profesorado
    • Subcarpeta: Exámenes

    Si la subcarpeta hereda permisos, podría estar accesible para más usuarios de los deseados si la carpeta principal estaba mal configurada.


    9. Autenticación y autorización

    Son dos conceptos básicos y diferentes.

    Autenticación

    Responde a la pregunta: ¿Quién eres?

    Se verifica la identidad del usuario mediante:

    • nombre de usuario y contraseña,
    • PIN,
    • huella dactilar,
    • tarjeta inteligente,
    • doble factor de autenticación.

    Autorización

    Responde a la pregunta: ¿Qué puedes hacer?

    Una vez que el usuario ya ha demostrado quién es, el sistema decide:

    • a qué carpetas puede entrar,
    • qué programas puede usar,
    • si puede imprimir,
    • si puede instalar software,
    • si puede administrar el equipo.

    Ejemplo sencillo

    Un alumno inicia sesión correctamente en la red del centro:

    • La autenticación ha sido correcta.
    • Pero si intenta entrar en la carpeta de profesores y el sistema se lo impide, ahí entra en juego la autorización.

    10. Principio de mínimo privilegio

    Uno de los principios más importantes en administración y seguridad es el principio de mínimo privilegio.

    ¿Qué significa?

    Cada usuario debe tener únicamente los permisos imprescindibles para realizar su trabajo. Ni más, ni menos.

    ¿Por qué es tan importante?

    Porque reduce:

    • errores accidentales,
    • borrados no intencionados,
    • accesos indebidos,
    • impacto de un malware,
    • abuso de privilegios.

    Ejemplo

    Un alumno no necesita privilegios de administrador en los equipos del aula.
    Un profesor tampoco debería tener acceso total al servidor si no es necesario.
    Un técnico puede tener más permisos, pero solo en los sistemas que debe gestionar.

    Dar permisos de más parece cómodo al principio, pero suele acabar generando problemas.


    11. Redes en sistemas Microsoft

    Los entornos Microsoft han sido históricamente muy usados en empresas, centros educativos y administraciones públicas.

    Windows utiliza TCP/IP de forma nativa para comunicarse en red y ofrece mecanismos específicos para compartir recursos, autenticar usuarios y administrar equipos.


    12. Protocolos clave en entornos Microsoft

    12.1. SMB (Server Message Block)

    Es el protocolo utilizado para compartir:

    • archivos,
    • carpetas,
    • impresoras,
    • recursos de red.

    Cuando en Windows accedes a una carpeta compartida como:

    \\SERVIDOR\DOCUMENTOS

    normalmente estás usando SMB.

    12.2. Kerberos

    Es un protocolo de autenticación muy utilizado en dominios Windows.

    Su objetivo es verificar la identidad de los usuarios de forma segura, evitando enviar la contraseña constantemente por la red.

    Kerberos funciona mediante tickets y es una pieza esencial en Active Directory.

    12.3. DNS

    Es el sistema que traduce nombres a direcciones IP.

    Ejemplo:

    • Nombre: servidor-aula.local
    • IP: 192.168.1.20

    Hoy es fundamental en redes Microsoft, ya que muchos servicios de dominio dependen de una resolución de nombres correcta.

    12.4. NetBIOS

    Fue muy importante en redes Windows antiguas para identificar equipos y compartir recursos por nombre.

    Actualmente su uso es mucho menor, y en redes modernas ha sido desplazado en gran medida por DNS y otros mecanismos más actuales.


    13. Grupo de trabajo y dominio

    En Windows existen dos formas clásicas de organizar una red: grupo de trabajo y dominio.

    13.1. Grupo de trabajo

    Es un modelo simple en el que no existe un servidor central de autenticación.

    Cada equipo:

    • mantiene sus propias cuentas locales,
    • comparte sus propios recursos,
    • administra sus propios permisos.

    Ventajas

    • sencillo de montar,
    • útil en redes pequeñas,
    • no requiere servidor central.

    Inconvenientes

    • poca seguridad,
    • mala escalabilidad,
    • administración repetitiva,
    • poca trazabilidad.

    13.2. Dominio

    Es el modelo profesional. En él existe un servidor central, normalmente con Windows Server y Active Directory, que gestiona:

    • usuarios,
    • grupos,
    • políticas,
    • equipos,
    • permisos,
    • recursos compartidos.

    Ventajas

    • administración centralizada,
    • mejor seguridad,
    • más control,
    • mayor escalabilidad,
    • aplicación uniforme de políticas.

    Inconvenientes

    • mayor complejidad,
    • requiere servidor y configuración específica.

    Comparativa

    CaracterísticaGrupo de trabajoDominio
    Gestión de usuariosLocal en cada equipoCentralizada
    SeguridadLimitadaAlta
    EscalabilidadBajaAlta
    AdministraciónDesordenada en redes grandesMucho más eficiente
    Uso recomendadoRedes pequeñasEmpresas, centros educativos, organizaciones

    14. La familia de protocolos TCP/IP

    Si el sistema operativo de red organiza el entorno, TCP/IP hace posible la comunicación.

    La familia TCP/IP es el conjunto de protocolos que permite que los datos viajen entre dispositivos, tanto en redes locales como en Internet.

    Es el estándar real y práctico utilizado hoy en día.

    TCP/IP frente al modelo OSI

    Aunque muchas veces se estudia el modelo OSI de 7 capas por motivos didácticos, en la práctica TCP/IP suele representarse en 4 capas:

    1. Aplicación
    2. Transporte
    3. Internet
    4. Acceso a red

    15. Capa de Aplicación

    Es la capa más cercana al usuario y a los programas que utiliza.

    Aquí trabajan los protocolos que permiten servicios concretos.

    Protocolos destacados

    HTTP y HTTPS

    Permiten acceder a páginas web.

    • HTTP transmite información sin cifrar.
    • HTTPS añade cifrado mediante TLS/SSL, protegiendo contraseñas, formularios y datos sensibles.

    DNS

    Convierte nombres de dominio en direcciones IP.

    Ejemplo:

    • www.google.com → una IP concreta

    Sin DNS, tendríamos que recordar direcciones IP numéricas para visitar cualquier servicio.

    DHCP

    Asigna automáticamente parámetros de red a los equipos.

    Por ejemplo:

    • dirección IP,
    • máscara de subred,
    • puerta de enlace,
    • servidores DNS.

    Gracias a DHCP, un usuario puede conectar su portátil a una red y obtener configuración automáticamente sin tener que escribirla a mano.


    16. Capa de Transporte

    Se encarga de transportar los datos entre aplicaciones de origen y destino.

    También utiliza los puertos, que permiten distinguir qué aplicación debe recibir la información.

    Ejemplos:

    • puerto 80 → HTTP
    • puerto 443 → HTTPS
    • puerto 53 → DNS
    • puerto 25 → SMTP

    Protocolos principales

    TCP (Transmission Control Protocol)

    Es un protocolo orientado a conexión y fiable.

    Se asegura de que:

    • los datos lleguen,
    • lleguen completos,
    • lleguen en orden,
    • se retransmitan si algo falla.

    Se utiliza en servicios donde la integridad importa mucho, como:

    • navegación web,
    • transferencia de archivos,
    • correo electrónico,
    • acceso remoto seguro.

    UDP (User Datagram Protocol)

    Es mucho más ligero y rápido que TCP, pero no garantiza:

    • entrega,
    • orden,
    • retransmisión.

    Se usa cuando la velocidad importa más que la perfección.

    Ejemplos:

    • streaming,
    • videollamadas,
    • juegos online,
    • ciertos servicios de DNS.

    Comparativa TCP vs UDP

    CaracterísticaTCPUDP
    FiabilidadAltaBaja
    Control de entregaNo
    Orden de llegadaNo
    VelocidadMenorMayor
    Uso típicoWeb, archivos, correoStreaming, voz, juegos

    17. Capa de Internet

    Es la encargada del direccionamiento lógico y del encaminamiento de los paquetes hacia su destino.

    Aquí se decide cómo llegar desde un origen hasta una máquina situada en otra red.

    Protocolos principales

    IP (Internet Protocol)

    Es el protocolo fundamental del direccionamiento.

    Cada equipo conectado a una red necesita una dirección IP para poder identificarse y comunicarse.

    Ejemplo de IP privada:

    192.168.1.34

    IP no garantiza por sí sola que los datos lleguen correctamente. Esa fiabilidad, cuando se necesita, la aporta TCP.

    ICMP (Internet Control Message Protocol)

    Se utiliza para diagnóstico y control.

    Un ejemplo muy conocido es el comando:

    ping

    Cuando hacemos ping a una dirección o a un nombre de dominio, normalmente se están enviando mensajes ICMP para comprobar si existe conectividad.

    Ejemplo de uso

    Si un equipo no puede acceder a Internet, una de las primeras pruebas suele ser:

    • hacer ping a su puerta de enlace,
    • hacer ping a una IP externa,
    • hacer ping a un nombre de dominio.

    Con eso se puede empezar a distinguir si el problema es de conectividad o de resolución DNS.


    18. Capa de Acceso a Red

    Es la capa donde el software se encuentra con el hardware.

    Aquí se trabaja con:

    • tarjetas de red,
    • direcciones MAC,
    • tramas,
    • medios físicos,
    • señales eléctricas, ópticas o inalámbricas.

    Tecnologías habituales

    • Ethernet
    • Wi-Fi

    Dirección MAC

    Cada interfaz de red tiene asociada una dirección física o MAC.

    Esta dirección se utiliza en la comunicación dentro de la red local.

    Mientras que la IP identifica lógicamente al equipo en una red, la MAC identifica físicamente la interfaz en el nivel de acceso a red.


    19. El viaje de los datos: ejemplo completo

    Vamos a ver qué ocurre cuando un usuario abre una página web.

    Situación

    Un alumno escribe en el navegador:

    https://www.ejemplo.com

    Paso 1: Capa de Aplicación

    El navegador necesita acceder al sitio web.

    • Si no conoce la IP del servidor, utiliza DNS para resolver el nombre.
    • Después prepara la comunicación usando HTTPS.

    Paso 2: Capa de Transporte

    Se utiliza normalmente TCP porque interesa que los datos lleguen correctamente.

    El navegador se comunica con el puerto 443, que corresponde a HTTPS.

    Paso 3: Capa de Internet

    Los datos se encapsulan en paquetes IP.

    La dirección IP de origen será la del ordenador del alumno y la IP de destino será la del servidor web.

    Paso 4: Capa de Acceso a Red

    Los paquetes se convierten en tramas y se envían físicamente por la red mediante Ethernet o Wi-Fi.

    Resultado

    El servidor recibe la petición, responde, y el proceso inverso permite que la página llegue al navegador del usuario.


    20. Relación entre administración de red y TCP/IP

    Estos dos bloques no deben estudiarse por separado como si no tuvieran relación.

    En realidad, están totalmente conectados.

    • El sistema operativo de red organiza usuarios, equipos, permisos y recursos.
    • TCP/IP permite que todos esos elementos puedan comunicarse.

    Por ejemplo:

    • un usuario inicia sesión contra un servidor,
    • una carpeta compartida se accede por red,
    • una impresora se usa remotamente,
    • un controlador de dominio resuelve nombres y autentica identidades,
    • un servidor DHCP asigna IP a los clientes.

    Todo eso se apoya sobre TCP/IP.


    21. Ejemplos prácticos del día a día

    Ejemplo 1: Inicio de sesión en un aula

    Un alumno enciende un ordenador del aula e introduce su usuario y contraseña.

    • El sistema autentica su identidad.
    • Se aplican sus permisos.
    • Puede acceder a sus recursos de red.

    Ejemplo 2: Carpeta compartida de profesores

    Solo el grupo de profesores debe poder acceder a una carpeta con exámenes.

    • Se crea un grupo llamado Profesores.
    • Se asignan permisos a ese grupo.
    • Los alumnos no tienen acceso.

    Ejemplo 3: Asignación automática de red

    Un portátil se conecta al Wi-Fi del centro.

    • DHCP le entrega una IP.
    • DNS le permite resolver nombres.
    • TCP/IP hace posible toda la comunicación.

    Ejemplo 4: Diagnóstico básico

    Un usuario dice que “Internet no funciona”.

    El técnico puede comprobar:

    • si tiene IP,
    • si responde la puerta de enlace,
    • si funciona DNS,
    • si hay conectividad con el exterior.

    22. Errores habituales que conviene evitar

    En administración de red hay varios errores muy frecuentes:

    Compartir cuentas de usuario

    Rompe la trazabilidad y reduce la seguridad.

    Asignar permisos uno a uno

    Hace la gestión lenta y propensa a errores. Es mejor usar grupos.

    Dar privilegios excesivos

    Aumenta el riesgo de accidentes y abusos.

    No revisar herencias de permisos

    Puede dejar recursos accesibles a usuarios no autorizados.

    Pensar que “tener red” es solo tener Internet

    Una red bien administrada implica mucho más: usuarios, recursos, permisos, autenticación y organización.

    No diferenciar autenticación de autorización

    Un usuario puede estar autenticado correctamente y aun así no tener permiso para acceder a un recurso.


    Un sistema operativo de red es la base organizativa que permite que una red funcione de manera controlada, segura y eficiente. Gracias a él es posible gestionar usuarios, grupos, permisos, servicios y equipos desde una perspectiva global.

    En entornos profesionales, el modelo cliente-servidor y la administración centralizada son esenciales para evitar el desorden y reforzar la seguridad. En ese contexto, conceptos como autenticación, autorización, grupos de usuarios y mínimo privilegio son fundamentales.

    Por otro lado, la familia de protocolos TCP/IP constituye la base de la comunicación moderna. Sus capas permiten que los datos viajen desde una aplicación concreta hasta el medio físico, pasando por el transporte, el direccionamiento y el acceso a red.

    Entender estos fundamentos no es opcional para cualquier administrador de sistemas o técnico de redes: es la base sobre la que se construyen servicios más avanzados como dominios, servidores web, compartición de archivos, monitorización, seguridad y administración centralizada.


    Ideas clave

    Un sistema operativo de red no solo conecta equipos: organiza, controla y protege los recursos compartidos.

    Una persona y un usuario no son lo mismo: el usuario es su identidad digital.

    En redes profesionales, los permisos deben gestionarse mediante grupos, no usuario por usuario.

    Autenticación es demostrar quién eres; autorización es determinar qué puedes hacer.

    El principio de mínimo privilegio reduce riesgos y mejora la seguridad.

    En entornos Microsoft, SMB, Kerberos y DNS son tecnologías fundamentales.

    TCP/IP es el conjunto de protocolos que hace posible la comunicación en redes e Internet.

    TCP prioriza la fiabilidad; UDP prioriza la rapidez.

    IP direcciona los paquetes y ICMP ayuda a diagnosticar problemas de conectividad.

  • 1. Fundamentos de Redes Informáticas

    1. Fundamentos de Redes Informáticas

    🎧 Resumen en audio del tema
    Escucha este breve audio para repasar las ideas principales de los fundamentos de redes informáticas antes de continuar o al finalizar la lectura.


    Vivimos en una sociedad permanentemente conectada. Cada vez que enviamos un mensaje desde el teléfono móvil, vemos un vídeo en streaming o accedemos a una página web, estamos utilizando una red informática.

    Las redes surgieron para resolver una necesidad muy concreta: permitir que los ordenadores dejaran de trabajar de forma aislada y pudieran compartir información, recursos y servicios de manera rápida, eficiente y económica.

    Pero, ¿qué es exactamente una red? ¿Cómo consiguen comunicarse entre sí nuestros dispositivos en cuestión de milisegundos, incluso estando a miles de kilómetros de distancia?

    En este tema vamos a estudiar los conceptos básicos de redes informáticas: los tipos de redes según su alcance, los dispositivos que las forman, las topologías más habituales, los protocolos que hacen posible la comunicación y el modelo OSI, que nos ayuda a entender cómo viajan los datos de un equipo a otro.


    Objetivos del tema

    Al finalizar este tema, el alumno será capaz de:

    • Comprender qué es una red informática y por qué es importante.
    • Diferenciar los principales tipos de redes según su alcance.
    • Identificar los elementos básicos que forman una red local.
    • Entender las topologías más utilizadas en redes.
    • Reconocer los protocolos fundamentales de comunicación.
    • Interpretar el modelo OSI y relacionarlo con dispositivos y servicios reales.

    1. ¿Qué es una red informática?

    Una red informática es un conjunto de dispositivos conectados entre sí que pueden intercambiar información y compartir recursos.

    Estos dispositivos pueden ser ordenadores, móviles, impresoras, servidores, tablets, cámaras IP, televisores inteligentes y muchos otros equipos.

    Gracias a una red, es posible:

    • Compartir archivos.
    • Acceder a impresoras comunes.
    • Navegar por Internet.
    • Enviar correos electrónicos.
    • Utilizar aplicaciones en línea.
    • Conectarse a servidores y bases de datos.

    Ejemplo cotidiano

    Cuando conectas tu portátil al Wi-Fi de casa para ver una página web, están interviniendo varios elementos de red: tu tarjeta de red, el router, el proveedor de Internet, servidores intermedios y el servidor final que aloja esa web.


    2. Clasificación de las redes según su alcance

    Las redes pueden clasificarse según la distancia o el área geográfica que abarcan. De menor a mayor alcance, encontramos los siguientes tipos:

    2.1 BAN (Body Area Network)

    La BAN es una red de alcance muy reducido, normalmente de centímetros o pocos metros. Se utiliza para conectar dispositivos que se llevan encima del cuerpo o incluso integrados en él.

    Ejemplos:

    • Relojes inteligentes.
    • Pulseras de actividad.
    • Sensores médicos.
    • Dispositivos de monitorización corporal.

    2.2 PAN (Personal Area Network)

    La PAN conecta dispositivos personales en un radio pequeño, normalmente de unos 10 metros.

    Suele utilizar tecnologías de bajo consumo, como Bluetooth.

    Ejemplos:

    • Móvil conectado a auriculares inalámbricos.
    • Tablet enlazada con un teclado Bluetooth.
    • Teléfono móvil conectado a un smartwatch.

    2.3 LAN (Local Area Network)

    La LAN es una red de área local. Conecta dispositivos dentro de un espacio limitado, como:

    • Un aula.
    • Una oficina.
    • Un laboratorio.
    • Un edificio pequeño.

    Se caracteriza por ofrecer:

    • Alta velocidad.
    • Baja latencia.
    • Control privado.
    • Facilidad para compartir recursos.

    Ejemplos:

    • La red de ordenadores de un aula de informática.
    • La red de una empresa en una sola planta.
    • La red interna de un laboratorio.

    2.4 HAN (Home Area Network)

    La HAN puede considerarse un caso particular de red local, centrada en el entorno doméstico.

    Conecta los dispositivos de una vivienda.

    Ejemplos:

    • Ordenadores.
    • Móviles.
    • Smart TV.
    • Consolas.
    • Impresoras.
    • Cámaras IP.
    • Asistentes inteligentes.

    2.5 CAN (Campus Area Network)

    La CAN conecta varias redes LAN dentro de un recinto más amplio.

    Ejemplos:

    • Una universidad con varios edificios.
    • Un instituto con distintas sedes.
    • Un hospital con varias áreas conectadas.

    2.6 MAN (Metropolitan Area Network)

    La MAN conecta diferentes redes dentro de una misma ciudad o área metropolitana.

    Normalmente utiliza infraestructuras de alta capacidad, como fibra óptica.

    Ejemplo:

    • La red que conecta distintas sedes de una administración pública dentro de una ciudad.

    2.7 WAN (Wide Area Network)

    La WAN es una red de gran extensión geográfica. Permite conectar redes situadas en diferentes ciudades, países o incluso continentes.

    Para ello se apoya en infraestructuras de operadores de telecomunicaciones.

    Ejemplos:

    • La red corporativa de una empresa con oficinas en varias ciudades.
    • Redes bancarias distribuidas por diferentes países.

    2.8 GAN (Global Area Network)

    La GAN es una red de alcance global que interconecta redes WAN a escala mundial.

    Internet es el mayor ejemplo de este tipo de red.

    Ejemplos:

    • Internet.
    • Redes globales que utilizan satélites y cables submarinos.

    3. Elementos clave de una red local

    Para construir una red no basta con conectar ordenadores sin más. Es necesario utilizar varios componentes, y cada uno cumple una función específica.

    3.1 Equipos finales o hosts

    Son los dispositivos que generan o reciben la información.

    Ejemplos:

    • Ordenadores.
    • Portátiles.
    • Tablets.
    • Móviles.
    • Impresoras.
    • Cámaras IP.
    • Smart TV.
    • Servidores.

    Un servidor es un equipo preparado para ofrecer servicios a otros dispositivos de la red, como páginas web, archivos compartidos, correo electrónico o bases de datos.


    3.2 Switch (conmutador)

    El switch conecta varios dispositivos dentro de una red local cableada.

    Su función principal es enviar la información únicamente al equipo destinatario, utilizando para ello la dirección física o MAC.

    Idea clave:

    El switch organiza el tráfico dentro de la red local.


    3.3 Router (enrutador)

    El router conecta redes diferentes entre sí.

    En una red doméstica o de oficina, el router suele unir:

    • La red local.
    • Internet.

    Trabaja principalmente con direcciones IP y se encarga de decidir qué ruta debe seguir la información.

    Idea clave:

    El router es la puerta de salida desde la red local hacia otras redes.


    3.4 Módem / ONT

    Este dispositivo adapta la señal para que pueda viajar por la infraestructura del proveedor de Internet.

    Dependiendo del tipo de conexión, puede tratarse de:

    • Un módem.
    • Una ONT en conexiones de fibra óptica.

    Función:

    Transformar la señal de la red interna a un formato adecuado para el medio del operador.


    3.5 Medios de transmisión

    Son los caminos por los que viajan los datos.

    Pueden ser:

    Cableados

    • Cable de par trenzado.
    • Cable coaxial.
    • Fibra óptica.

    Inalámbricos

    • Wi-Fi.
    • Bluetooth.
    • Ondas de radio.

    4. Topologías de red: la arquitectura de la conexión

    La topología es la forma en la que se organizan físicamente o lógicamente los dispositivos de una red.

    4.1 Topología en bus

    Todos los equipos comparten un único cable central.

    Ventajas:

    • Sencilla.
    • Económica.

    Inconvenientes:

    • Si el cable principal falla, toda la red deja de funcionar.
    • Genera muchas colisiones.
    • Está obsoleta en entornos modernos.

    4.2 Topología en anillo

    Los dispositivos forman un círculo y la información circula en una dirección determinada.

    Ventajas:

    • Flujo ordenado de la información.

    Inconvenientes:

    • Si un equipo falla o se rompe el enlace, se interrumpe la comunicación.
    • Poco flexible.

    4.3 Topología en estrella

    Es la más utilizada actualmente.

    Todos los dispositivos están conectados a un nodo central, normalmente un switch o router.

    Ventajas:

    • Fácil de administrar.
    • Si falla un cable, solo se desconecta un equipo.
    • Permite ampliar la red con facilidad.

    Inconveniente:

    • Si falla el dispositivo central, la red puede quedar afectada.

    4.4 Topología en malla

    Cada dispositivo está conectado a varios nodos, de forma que existen rutas alternativas.

    Ventajas:

    • Alta redundancia.
    • Gran tolerancia a fallos.
    • Muy útil en redes críticas.

    Inconvenientes:

    • Mayor coste.
    • Configuración más compleja.

    5. El lenguaje de la red: protocolos de comunicación

    Conectar dispositivos no es suficiente. Todos deben seguir unas normas comunes para entenderse. Esas normas reciben el nombre de protocolos.

    La familia más importante hoy en día es TCP/IP, base del funcionamiento de Internet.

    5.1 IP (Internet Protocol)

    El protocolo IP identifica a cada dispositivo dentro de la red mediante una dirección IP.

    Podemos imaginarla como una dirección postal que permite saber:

    • De dónde sale la información.
    • A dónde debe llegar.

    5.2 TCP y UDP

    Ambos son protocolos de transporte, pero funcionan de forma diferente.

    TCP

    • Divide la información en partes.
    • Verifica que todo llegue correctamente.
    • Reordena los datos si es necesario.
    • Garantiza fiabilidad.

    Usos habituales:

    • Navegación web.
    • Correo electrónico.
    • Transferencia de archivos.

    UDP

    • Envía datos sin comprobar si han llegado.
    • Es más rápido.
    • Tiene menos sobrecarga.

    Usos habituales:

    • Videollamadas.
    • Streaming en directo.
    • Videojuegos online.

    5.3 DNS

    El DNS traduce nombres de dominio comprensibles para las personas a direcciones IP comprensibles para las máquinas.

    Ejemplo:

    • www.ejemplo.com142.250.190.14

    Idea clave:

    El DNS actúa como una agenda o guía telefónica de Internet.


    5.4 DHCP

    El DHCP asigna automáticamente una dirección IP a los dispositivos cuando se conectan a la red.

    Gracias a ello, el usuario no tiene que configurar manualmente la IP de cada equipo.


    5.5 HTTP y HTTPS

    Son los protocolos utilizados para la navegación web.

    HTTP

    Permite intercambiar páginas web y otros recursos entre cliente y servidor.

    HTTPS

    Es la versión segura de HTTP. Añade cifrado para proteger la información intercambiada.

    Ejemplo:

    Cuando introduces contraseñas o datos bancarios en una web, lo correcto es que esa web utilice HTTPS.


    6. El modelo OSI: entendiendo cómo viajan los datos

    El modelo OSI (Open Systems Interconnection) es un modelo teórico que divide la comunicación de red en 7 capas.

    Su objetivo es facilitar el estudio, diseño y resolución de problemas de red.

    6.1 Capa 1: Física

    Se encarga de transmitir bits a través del medio físico.

    Ejemplos:

    • Cables.
    • Señales eléctricas.
    • Luz en fibra óptica.
    • Ondas Wi-Fi.

    6.2 Capa 2: Enlace de datos

    Agrupa bits en tramas, detecta errores locales y utiliza direcciones MAC.

    Dispositivos relacionados:

    • Switches.

    6.3 Capa 3: Red

    Se encarga del direccionamiento lógico y del enrutamiento.

    Elementos clave:

    • Direcciones IP.
    • Routers.

    6.4 Capa 4: Transporte

    Garantiza la entrega de la información entre origen y destino.

    Protocolos principales:

    • TCP.
    • UDP.

    6.5 Capa 5: Sesión

    Controla el inicio, mantenimiento y cierre de la comunicación entre dos equipos.


    6.6 Capa 6: Presentación

    Se encarga de traducir, comprimir y cifrar los datos.

    Ejemplos:

    • Codificación.
    • Compresión.
    • Cifrado.

    6.7 Capa 7: Aplicación

    Es la capa más cercana al usuario. Aquí trabajan las aplicaciones que utilizamos a diario.

    Ejemplos:

    • Navegadores web.
    • Clientes de correo.
    • Aplicaciones de mensajería.
    • Servicios web.

    7. Encapsulación: el viaje de los datos

    Cuando un usuario envía un mensaje o solicita una página web, la información no viaja “tal cual”.

    Pasa por un proceso llamado encapsulación:

    1. Los datos se generan en la capa de aplicación.
    2. Van descendiendo por las capas del modelo.
    3. Cada capa añade su propia información de control.
    4. Finalmente, los bits viajan por el medio físico.

    En el equipo receptor ocurre lo contrario:

    1. La información entra por la capa física.
    2. Va subiendo capa a capa.
    3. Cada nivel interpreta y elimina su parte de control.
    4. La aplicación final muestra el contenido al usuario.

    8. Relación entre dispositivos, protocolos y capas

    Para entender mejor una red, conviene relacionar los conceptos vistos:

    • Switch → trabaja principalmente en la capa 2.
    • Router → trabaja principalmente en la capa 3.
    • TCP y UDP → pertenecen a la capa 4.
    • HTTP, HTTPS, DNS, DHCP → se usan en capas superiores, cercanas a la aplicación.
    • Cable, fibra, Wi-Fi → están relacionados con la capa 1.

    9. Ejemplo real de comunicación en una red

    Imagina que un alumno abre una página web desde el portátil del aula:

    1. Escribe la dirección de la web en el navegador.
    2. El equipo consulta al DNS para saber qué IP corresponde a ese nombre.
    3. El portátil envía la petición a través del switch de la red local.
    4. El router dirige la petición hacia Internet.
    5. La información atraviesa varias redes hasta llegar al servidor web.
    6. El servidor responde.
    7. Los datos regresan al portátil.
    8. El navegador interpreta la respuesta y muestra la página.

    En este proceso intervienen dispositivos, protocolos, medios físicos y varias capas del modelo OSI.


    Tabla comparativa: Modelo OSI vs Modelo TCP/IP

    Modelo OSIFunción principalModelo TCP/IPFunción principal
    7. AplicaciónProporciona servicios de red a las aplicaciones del usuarioAplicaciónReúne las funciones de aplicación, presentación y sesión
    6. PresentaciónTraduce, comprime y cifra los datosAplicaciónGestiona el formato de los datos y servicios de alto nivel
    5. SesiónEstablece, mantiene y cierra sesiones de comunicaciónAplicaciónControla la comunicación entre aplicaciones
    4. TransporteGarantiza la entrega de datos extremo a extremoTransporteGestiona la comunicación extremo a extremo mediante TCP o UDP
    3. RedSe encarga del direccionamiento lógico y del enrutamientoInternetGestiona direcciones IP y el envío de paquetes entre redes
    2. Enlace de datosControla acceso al medio, tramas y direcciones MACAcceso a la redManeja la transmisión local de datos sobre el medio físico
    1. FísicaTransmite bits por cables, radio o fibraAcceso a la redIncluye los medios físicos y el acceso al medio

    Resumen rápido

    AspectoModelo OSIModelo TCP/IP
    Número de capas7 capas4 capas
    OrigenModelo teórico de referenciaModelo práctico usado en Internet
    Nivel de detalleMás detalladoMás simplificado
    Uso realMuy usado para enseñar y diagnosticarBase real de las comunicaciones en red
    Capas superioresAplicación, Presentación y Sesión separadasSe agrupan en Aplicación
    Capas inferioresEnlace y Física separadasSe agrupan en Acceso a la red

    Relación entre ambos modelos

    OSITCP/IP
    Aplicación + Presentación + SesiónAplicación
    TransporteTransporte
    RedInternet
    Enlace de datos + FísicaAcceso a la red

    10. Resumen del tema

    Una red informática permite conectar dispositivos para compartir información y recursos.

    Según su alcance, las redes pueden ser BAN, PAN, LAN, HAN, CAN, MAN, WAN o GAN.

    Dentro de una red local encontramos elementos fundamentales como:

    • Hosts.
    • Switches.
    • Routers.
    • Módems / ONT.
    • Medios de transmisión.

    Las redes también se pueden organizar según distintas topologías, siendo la estrella la más habitual hoy en día.

    Para comunicarse, los dispositivos utilizan protocolos como:

    • IP
    • TCP
    • UDP
    • DNS
    • DHCP
    • HTTP
    • HTTPS

    Además, el modelo OSI permite entender de forma ordenada cómo viajan los datos desde una aplicación hasta el medio físico y viceversa.