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:
Analizar las necesidades de una infraestructura con varias sedes.
Crear subredes de distinto tamaño mediante VLSM.
Calcular direcciones de red, broadcast, rangos utilizables y máscaras.
Organizar departamentos mediante redes o VLAN independientes.
Configurar direccionamiento estático y dinámico.
Permitir la comunicación entre redes mediante routing.
Aplicar reglas básicas de segmentación y control de acceso.
Verificar el funcionamiento mediante pruebas reproducibles.
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 departamento
Dispositivos actuales
Crecimiento mínimo previsto
Sensores, puertas y dispositivos IoT
850
20 %
Wi-Fi de visitantes
420
20 %
Personal administrativo
190
20 %
Laboratorio de Energía
110
20 %
Videovigilancia y seguridad física
75
20 %
Investigadores
60
20 %
Centro de Operaciones
42
20 %
Servidores internos
26
20 %
Telefonía IP
24
20 %
Administración de red
12
20 %
6.2. Estación de Campo Starcourt
Red o departamento
Dispositivos actuales
Crecimiento mínimo previsto
Personal de operaciones
48
20 %
Sensores y cámaras
30
20 %
Invitados
18
20 %
Administración de red
6
20 %
6.3. Búnker NINA
Red o departamento
Dispositivos actuales
Crecimiento mínimo previsto
Laboratorio restringido
28
20 %
Seguridad
14
20 %
Servidores locales
6
20 %
Administración de red
5
20 %
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
Calculad la capacidad necesaria sumando el crecimiento del 20 % y redondeando siempre hacia arriba.
Recordad incluir las direcciones que vayan a consumir puertas de enlace, servidores u otros dispositivos de infraestructura.
Ordenad las redes desde la que necesita más direcciones hasta la que necesita menos.
Asignad a cada red el bloque más pequeño que cubra su necesidad.
No pueden existir subredes solapadas.
No debe desperdiciarse un bloque excesivamente grande sin una justificación técnica.
La primera dirección utilizable de cada LAN se asignará, salvo justificación, a su puerta de enlace.
Los servidores, routers, switches gestionables e impresoras usarán direcciones estáticas.
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:
Sede
Red/VLAN
Necesidad con crecimiento
Prefijo
Máscara decimal
Dirección de red
Primer host
Último host
Broadcast
Gateway
Hawkins
IoT
También se añadirá una segunda tabla para los dispositivos configurados:
Dispositivo
Interfaz
Dirección IP
Máscara/prefijo
Gateway
DNS
Asignación
SRV-DNS-01
Fa0
Está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:
La red de visitantes solo puede acceder al DNS necesario, al portal web y a Internet.
Los visitantes no pueden iniciar conexiones hacia las redes internas.
La red IoT no puede acceder a Administración de red ni a los equipos de investigadores.
Solo Administración de red puede gestionar routers y switches mediante SSH.
Telnet deberá permanecer deshabilitado.
El laboratorio NINA no será accesible desde redes de invitados.
Seguridad podrá consultar las cámaras y sensores de las tres sedes.
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:
Identificad las sedes, departamentos, servidores y enlaces.
Dibujad un primer esquema lógico.
Decidid qué servicios serán centrales y cuáles serán locales.
Anotad las restricciones de seguridad.
Fase 2. Cálculo VLSM
Calculad el número de hosts con crecimiento.
Ordenad las redes de mayor a menor.
Determinad el prefijo mínimo de cada una.
Asignad los bloques dentro de 172.20.0.0/16.
Calculad red, primer host, último host y broadcast.
Comprobad que no existen solapamientos.
Reservad espacio para futuras ampliaciones.
Fase 3. Construcción de la topología
Colocad routers, switches, servidores y clientes.
Cablead correctamente los dispositivos.
Asignad nombres a todos los equipos.
Cread VLAN y configurad puertos.
Configurad puertas de enlace.
Fase 4. Direccionamiento y routing
Configurad interfaces y subinterfaces.
Asignad direcciones estáticas a infraestructura.
Configurad rutas estáticas u OSPF.
Fase 5. Pruebas y documentación
Ejecutad el plan de pruebas.
Corregid los fallos encontrados.
Capturad evidencias relevantes.
Completad el README.md.
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:
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
Portada: título, integrantes, curso y fecha.
Resumen ejecutivo del proyecto.
Descripción de las tres sedes.
Requisitos detectados.
Diagrama lógico de red.
Explicación paso a paso del cálculo VLSM.
Tabla completa de direccionamiento.
Tabla de VLAN.
Inventario y función de los dispositivos.
Explicación del routing seleccionado.
Reglas de seguridad y ACL aplicadas.
Configuración de NAT/PAT.
Plan de pruebas y resultados.
Problemas encontrados y soluciones.
Conclusiones y posibles mejoras.
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.
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:
Montaje del servidor web con Ubuntu.
Ampliación UFW
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.
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:
Elemento
Configuración utilizada
Sistema operativo
Ubuntu 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:
Escríbelo en un bloque de código.
Explica qué hace.
Describe las opciones o parámetros utilizados.
Indica el resultado esperado.
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:
Prueba
Comando o acción
Resultado esperado
Resultado obtenido
Estado
Estado de Apache
systemctl status apache2
Servicio activo
…
Superada/No superada
Acceso web
Abrir http://IP_SERVIDOR
Carga la web propia
…
…
Prueba de PHP
Abrir la URL de prueba
PHP 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:
Objetivo del paso. Qué se pretende conseguir.
Comando o configuración. Escrito con el lenguaje correcto en un bloque de código.
Explicación. Qué hace y por qué es necesario.
Archivo afectado. Ruta completa y fragmento modificado, si corresponde.
Comprobación. Comando, petición, acceso desde navegador o prueba equivalente.
Resultado. Qué ocurrió realmente en tu servidor.
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:
Cabecera
Valor aplicado
Riesgo que ayuda a reducir
Mé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íntoma
Posible causa
Comprobación
Solución
Apache no arranca
Error 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:
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
Criterio
Peso
Parte 1: instalación, configuración y pruebas
20 %
Parte 2: realización, explicación y pruebas
15 %
Parte 3: .htaccess, seguridad y pruebas
25 %
Ampliaciones técnicas y capacidad de análisis
15 %
Calidad del README.md y uso de Markdown
15 %
Organización, evidencias, referencias y entrega
10 %
Total
100 %
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
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.
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
Instalar o activar WSL 2.
Instalar Docker Desktop para Windows.
Reiniciar el equipo si lo solicita.
Abrir Docker Desktop.
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.
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
Descargar Docker Desktop para Mac.
Elegir la versión correcta:
Mac Intel.
Mac Apple Silicon.
Instalar la aplicación.
Abrir Docker Desktop.
Esperar a que Docker arranque completamente.
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.
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>"; }
$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:
Campo
Tipo
Extra
id
INT
AUTO_INCREMENT, PRIMARY KEY
nombre
VARCHAR(100)
email
VARCHAR(150)
fecha_alta
DATETIME
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 );
¿Qué diferencia hay entre instalar Apache, PHP y MySQL directamente en el sistema y hacerlo con Docker?
¿Qué ventaja tiene que todos los servicios estén definidos en un archivo docker-compose.yml?
¿Por qué PHP se conecta a MySQL usando el host mysql y no localhost?
¿Qué es un volumen en Docker?
¿Dónde se guardan los datos de MySQL en este proyecto?
¿Qué pasaría si ejecutamos docker compose down -v?
¿Para qué sirve phpMyAdmin?
¿Para qué sirve Mailpit?
¿Por qué no deberíamos usar contraseñas como root o devpass en producción?
¿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ón
Comando
¿Borra contenedores?
¿Borra datos MySQL?
¿Borra imágenes?
Parar
docker compose stop
No
No
No
Eliminar contenedores
docker compose down
Sí
No
No
Eliminar con volúmenes
docker compose down -v
Sí
Sí
No
Destruir completo
docker compose down -v --rmi local
Sí
Sí
Sí
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.
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 ;;
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
: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.
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ón
Qué hace
Sincronizar
Descarga y mantiene copias locales de los archivos
Montar
Muestra 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.
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ón
Comando
Instalar rclone
sudo apt install rclone fuse3
Configurar Google Drive
rclone config
Ver carpetas de Drive
rclone lsd gdrive:
Crear carpeta de montaje
mkdir -p ~/GoogleDrive
Montar Drive
rclone mount gdrive: ~/GoogleDrive --vfs-cache-mode writes --daemon
Desmontar Drive
fusermount3 -u ~/GoogleDrive
Ver estado del servicio
systemctl --user status rclone-gdrive
Iniciar servicio
systemctl --user start rclone-gdrive
Parar servicio
systemctl --user stop rclone-gdrive
16. Ejercicio propuesto para el alumno
Realiza los siguientes pasos y documenta el proceso:
Instala rclone en Ubuntu.
Configura tu cuenta de Google Drive.
Crea la carpeta ~/GoogleDrive.
Monta Google Drive usando rclone mount.
Comprueba que puedes ver tus archivos desde el explorador.
Crea una carpeta de prueba dentro de ~/GoogleDrive.
Comprueba desde la web de Google Drive que la carpeta se ha creado.
Desmonta Google Drive.
Vuelve a montarlo manualmente.
Configura el montaje automático con systemd.
17. Preguntas de repaso
¿Qué diferencia hay entre sincronizar Google Drive y montarlo como unidad?
¿Para qué sirve rclone?
¿Qué significa gdrive: en los comandos usados?
¿Dónde se monta Google Drive en esta práctica?
¿Qué comando se usa para desmontar la unidad?
¿Qué ventaja tiene usar systemd en esta práctica?
¿Se descargan todos los archivos de Google Drive al montar la unidad?
¿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.
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.
Entramos en la web oficial de Ollama.
Seleccionamos la versión de Windows.
Descargamos el instalador.
Ejecutamos el archivo descargado.
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:
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ón
Comando
Ver versión
ollama --version
Descargar modelo
ollama pull nombre_modelo
Ejecutar modelo
ollama run nombre_modelo
Ver modelos instalados
ollama list
Ver modelos cargados
ollama ps
Detener modelo
ollama stop nombre_modelo
Borrar modelo
ollama rm nombre_modelo
Probar API local
curl 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
Instalar Ollama en Windows.
Comprobar la versión instalada.
Descargar un modelo.
Ejecutar el modelo desde terminal.
Hacerle al modelo una pregunta técnica.
Listar los modelos instalados.
Comprobar qué modelos están cargados.
Probar la API local con curl.
Documentar el proceso con capturas.
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:
Ve al icono de Ollama en la bandeja del sistema, junto al reloj.
Clic derecho.
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.
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:
Pulsamos en el menú de inicio.
Escribimos PowerShell.
Hacemos clic derecho.
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:
Vamos a la sección Extensions.
Buscamos:
WSL
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:
Vamos al menú Terminal.
Pulsamos New Terminal.
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:
Instalar OpenCode Desktop para Windows.
Ejecutar el servidor de OpenCode dentro de WSL.
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.
Para esta práctica vamos a trabajar principalmente de esta forma:
Windows + WSL Ubuntu + Visual Studio Code + OpenCode en terminal
Es decir:
Usamos Windows como sistema principal.
Usamos Ubuntu mediante WSL como entorno de desarrollo.
Abrimos los proyectos con Visual Studio Code usando Remote WSL.
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:
Abrir Visual Studio Code en Windows.
Instalar la extensión WSL.
Volver a abrir Ubuntu.
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
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:
Recurso
Valor recomendado
Sistema operativo
Ubuntu Server 24.04
CPU
2 cores
RAM
4 GB
Disco
25 GB mínimo
Red
NAT o adaptador puente
Acceso
Consola 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.
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
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.
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
Ventaja
Descripción
Flexibilidad
Permiten levantar sistemas y redes en poco tiempo.
Ahorro de costes
Reducen la necesidad de hardware físico.
Escalabilidad
Es fácil ampliar el número de máquinas o segmentos de red.
Aislamiento
Se pueden crear entornos seguros y separados del resto.
Reutilización
Un mismo host puede albergar múltiples laboratorios o servicios. Duplicarlos, clonarlos…
Rapidez de despliegue
Los cambios se aplican mucho más rápido que en infraestructuras físicas y no tenemos que desplazarnos.
Desventajas
Desventajas
Descripción
Dependencia del host
Si el equipo anfitrión falla, pueden caer varias máquinas y redes a la vez.
Posibles cuellos de botella
Todos los sistemas virtuales comparten recursos de la máquina anfitrión.
Riesgo de mala segmentación
Una mala configuración puede mezclar redes o exponer servicios sin querer.
Falsa sensación de aislamiento
Si 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.
Equipo
Dirección IP
Máscara
Puerta de enlace
Ubuntu Desktop
10.0.2.10
255.255.255.0
10.0.2.1
Windows
10.0.2.11
255.255.255.0
10.0.2.1
Ubuntu Server
10.0.2.12
255.255.255.0
10.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.
🎧 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 usuario
Dónde se almacena
Dónde puede usarse
Administración
Local
En un único equipo
Solo en ese equipo
Individual
De red
En un servidor central
En varios equipos de la red
Centralizada
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
Permiso
Qué permite
Lectura
Ver el contenido
Escritura
Crear o modificar
Ejecución
Ejecutar archivos o programas
Modificación
Cambiar y borrar contenido
Control total
Gestió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ística
Grupo de trabajo
Dominio
Gestión de usuarios
Local en cada equipo
Centralizada
Seguridad
Limitada
Alta
Escalabilidad
Baja
Alta
Administración
Desordenada en redes grandes
Mucho más eficiente
Uso recomendado
Redes pequeñas
Empresas, 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:
Aplicación
Transporte
Internet
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ística
TCP
UDP
Fiabilidad
Alta
Baja
Control de entrega
Sí
No
Orden de llegada
Sí
No
Velocidad
Menor
Mayor
Uso típico
Web, archivos, correo
Streaming, 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.
🎧 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.com → 142.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:
Los datos se generan en la capa de aplicación.
Van descendiendo por las capas del modelo.
Cada capa añade su propia información de control.
Finalmente, los bits viajan por el medio físico.
En el equipo receptor ocurre lo contrario:
La información entra por la capa física.
Va subiendo capa a capa.
Cada nivel interpreta y elimina su parte de control.
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:
Escribe la dirección de la web en el navegador.
El equipo consulta al DNS para saber qué IP corresponde a ese nombre.
El portátil envía la petición a través del switch de la red local.
El router dirige la petición hacia Internet.
La información atraviesa varias redes hasta llegar al servidor web.
El servidor responde.
Los datos regresan al portátil.
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 OSI
Función principal
Modelo TCP/IP
Función principal
7. Aplicación
Proporciona servicios de red a las aplicaciones del usuario
Aplicación
Reúne las funciones de aplicación, presentación y sesión
6. Presentación
Traduce, comprime y cifra los datos
Aplicación
Gestiona el formato de los datos y servicios de alto nivel
5. Sesión
Establece, mantiene y cierra sesiones de comunicación
Aplicación
Controla la comunicación entre aplicaciones
4. Transporte
Garantiza la entrega de datos extremo a extremo
Transporte
Gestiona la comunicación extremo a extremo mediante TCP o UDP
3. Red
Se encarga del direccionamiento lógico y del enrutamiento
Internet
Gestiona direcciones IP y el envío de paquetes entre redes
2. Enlace de datos
Controla acceso al medio, tramas y direcciones MAC
Acceso a la red
Maneja la transmisión local de datos sobre el medio físico
1. Física
Transmite bits por cables, radio o fibra
Acceso a la red
Incluye los medios físicos y el acceso al medio
Resumen rápido
Aspecto
Modelo OSI
Modelo TCP/IP
Número de capas
7 capas
4 capas
Origen
Modelo teórico de referencia
Modelo práctico usado en Internet
Nivel de detalle
Más detallado
Más simplificado
Uso real
Muy usado para enseñar y diagnosticar
Base real de las comunicaciones en red
Capas superiores
Aplicación, Presentación y Sesión separadas
Se agrupan en Aplicación
Capas inferiores
Enlace y Física separadas
Se agrupan en Acceso a la red
Relación entre ambos modelos
OSI
TCP/IP
Aplicación + Presentación + Sesión
Aplicación
Transporte
Transporte
Red
Internet
Enlace de datos + Física
Acceso 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.