# Redes en Docker Desktop


Esta página explica cómo Docker Desktop enruta el tráfico de red y la E/S de archivos entre los contenedores, la VM y el host, y cómo este comportamiento es visible para los firewalls y las herramientas de protección de endpoints.

## Descripción general

Docker Desktop ejecuta Docker Engine dentro de una máquina virtual (VM) ligera de Linux. Dependiendo de la configuración de tu sistema y sistema operativo, Docker Desktop enruta las operaciones de red y archivos entre la VM de Docker y el host utilizando diferentes componentes de backend.

### Componentes del backend y sus responsabilidades

El backend actúa como:

- Proxy de red: Traduce el tráfico entre el host y la VM de Linux.
   - En Windows y Mac, el proceso `com.docker.backend` se encarga de esto.
   - En Linux, el proceso `qemu` realiza esta función.
- Servidor de archivos: Gestiona el acceso a archivos de los contenedores al sistema de archivos del host.
   - Al usar gRPC FUSE, el backend realiza la compartición de archivos.
   - Al usar `virtiofs`, `osxfs` o `krun`, el acceso a archivos es gestionado por esos demonios respectivos en lugar de por el proceso de backend.
- Plano de control: Gestiona las llamadas a la API de Docker, el reenvío de puertos y la configuración del proxy.

La siguiente tabla resume las configuraciones típicas con más detalle:

| Plataforma | Configuración | Red gestionada por | Compartición de archivos gestionada por | Notas |
| --- | --- | --- | --- | --- |
| Windows | Hyper-V | `com.docker.backend.exe` | `com.docker.backend.exe` | Configuración más simple con visibilidad completa para herramientas de EDR y firewall |
| Windows (WSL 2) | WSL 2 | `com.docker.backend.exe` | Kernel de WSL 2 (sin visibilidad desde el host) | Recomendado únicamente cuando se necesita la integración con WSL 2 |
| Mac | Virtualization framework + gRPC FUSE | `com.docker.backend` | `com.docker.backend` | Recomendado por su rendimiento y visibilidad |
| Mac | Virtualization framework + `virtiofs` | `com.docker.backend` | Virtualization framework de Apple | Mayor rendimiento pero sin visibilidad del acceso a archivos desde el host |
| Mac | Virtualization framework + `osxfs` | `com.docker.backend` | `osxfs` | Configuración heredada, no recomendada |
| Mac | DockerVMM + `virtiofs` | `com.docker.backend` | `krun` | En fase Beta |
| Linux | VM nativa de Linux | `qemu` | `virtiofsd` | Sin proceso `com.docker.backend` en Linux |


## Cómo se conectan los contenedores a internet

Cada contenedor de Linux en Docker Desktop se ejecuta dentro de una pequeña red virtual gestionada por Docker; además, cada contenedor se conecta a una red gestionada por Docker y recibe su propia dirección IP interna. Puedes ver y gestionar estas redes con `docker network ls`, `docker network create` y `docker network inspect`. Se gestionan a través del archivo [`daemon.json`](/engine/daemon/).

Cuando un contenedor inicia una solicitud de red, por ejemplo con `apt-get update` o `docker pull`:

- La interfaz `eth0` del contenedor se conecta a un puente virtual (`docker0`) dentro de la VM.
- El tráfico de salida del contenedor se envía a través de la Traducción de Direcciones de Red (NAT) utilizando un adaptador virtual (normalmente con una IP interna como `192.168.65.3`). Puedes ver o cambiar esto en los [ajustes de Docker Desktop](/desktop/settings-and-maintenance/settings/#network).
- El tráfico se transfiere al sistema host a través de un canal de memoria compartida en lugar de una interfaz de red virtual tradicional. Este enfoque garantiza una comunicación confiable y evita conflictos con los adaptadores de red de nivel de host o las configuraciones de firewall.
- En el host, el proceso de backend de Docker Desktop recibe el tráfico y crea conexiones TCP/IP estándar utilizando las mismas API de red que otras aplicaciones.

Todo el tráfico de red de salida de los contenedores se origina en el proceso `com.docker.backend`. Los firewalls, las VPN y las herramientas de seguridad, como Crowdstrike, ven el tráfico proveniente de este proceso y no de una VM o de una fuente desconocida, por lo que el software de seguridad de firewall y de endpoint puede aplicar reglas directamente a `com.docker.backend`.

## Cómo funcionan los puertos expuestos

Al publicar un puerto de contenedor utilizando la bandera `-p` o `--publish`, Docker Desktop hace que ese puerto sea accesible desde tu sistema host o red local.

Por ejemplo, con `docker run -p 80:80 nginx`:

- El proceso de backend de Docker Desktop escucha en el puerto del host especificado, en este caso, el puerto `80`.
- Cuando una aplicación, como un navegador web, se conecta a ese puerto, Docker Desktop reenvía la conexión a la VM de Linux donde el contenedor se está ejecutando a través de un canal de memoria compartida.
- Dentro de la VM, la conexión se enruta a la dirección IP interna y al puerto del contenedor, por ejemplo `172.17.0.2:80`.
- El contenedor responde a través de la misma ruta, por lo que puedes acceder a él desde tu host como a cualquier otro servicio local.

De forma predeterminada, `docker run -p` escucha en todas las interfaces de red (`0.0.0.0`), pero puedes restringirlo a una dirección específica, como `127.0.0.1` (`localhost`) o a un adaptador de red particular. Este comportamiento se puede modificar para enlazar con `localhost` de manera predeterminada en los [ajustes de red de Docker Desktop](/desktop/settings-and-maintenance/settings/#network)

Los firewalls del host pueden permitir o denegar las conexiones entrantes filtrando por `com.docker.backend`.

## Usar Docker Desktop con un proxy

Docker Desktop puede usar los ajustes de proxy predeterminados de tu sistema o los ajustes personalizados que configures en la [configuración del proxy de Docker Desktop](/desktop/settings-and-maintenance/settings/#proxies). Todo el tráfico del proxy pasa a través de `com.docker.backend.exe`.

Cuando se habilita un proxy:

- El proceso de backend reenvía las solicitudes de red, por ejemplo `docker pull`, a través de un proxy interno en `http.docker.internal:3128`.
- Luego, el proxy interno se conecta directamente a internet o a través de tu proxy ascendente (upstream), dependiendo de tu configuración, añadiendo autenticación si es necesario.
- A continuación, Docker Desktop descarga las imágenes o los datos solicitados a través del proxy como de costumbre.

Ten en cuenta que:
- El proxy respeta la configuración del proxy del sistema o la configuración manual.
- En Windows, se admite la autenticación Basic, NTLM y Kerberos.
- En Mac, NTLM/Kerberos no se admiten de forma nativa. Como solución alternativa, ejecuta un proxy local en `localhost`.
- Los plugins de la CLI y otras herramientas que utilicen directamente la API de Docker deben configurarse por separado mediante las variables de entorno `HTTP_PROXY`, `HTTPS_PROXY` y `NO_PROXY`.
  
## Firewalls y visibilidad del endpoint

Para restringir la red de la VM o de los contenedores, aplica reglas a `com.docker.backend.exe` (Windows), `com.docker.backend` (Mac) o `qemu` (Linux), ya que toda la red de la VM se canaliza a través de estos procesos.

Utiliza el Firewall de Windows Defender o los firewalls de endpoints empresariales para el control. Esto te permite inspeccionar y restringir el tráfico a nivel de host sin modificar el motor de Docker.

Crowdstrike y herramientas similares pueden observar todo el tráfico y el acceso a archivos que pasa a través del proceso de backend.

| Acción | ¿Visible para el EDR del host? | Razón |
|---------|----------------------|---------|
| El contenedor lee archivos del host | Sí | El acceso es gestionado por `com.docker.backend` |
| El contenedor escribe archivos en el host | Sí | El mismo proceso realiza la escritura |
| El contenedor accede a sus propias capas del sistema de archivos | No | Existe únicamente dentro de la VM |