Compartir por

Requisitos previos para Microsoft Tunnel en Intune

  • Artigo

Para poder instalar la puerta de enlace de VPN de Microsoft Tunnel para Microsoft Intune, revise y configure los requisitos previos. Los requisitos previos incluyen el uso de un servidor Linux que ejecuta contenedores para hospedar el software del servidor de túnel. Planee también configurar la red, los firewalls y los servidores proxy para admitir las comunicaciones para Microsoft Tunnel.

En un nivel alto, Microsoft Tunnel requiere lo siguiente:

  • Una suscripción de Azure.

  • Una suscripción Microsoft Intune plan 1.

    Nota:

    Este requisito previo es para Microsoft Tunnel y no incluye Microsoft Tunnel for Mobile Application Management, que es un complemento de Intune que requiere una suscripción Microsoft Intune plan 2.

  • Un servidor Linux que ejecuta contenedores. El servidor puede ser local o en la nube y admite uno de los siguientes tipos de contenedor:

    • Podman para Red Hat Enterprise Linux (RHEL). Consulte los requisitos del servidor Linux .
    • Docker para todas las demás distribuciones de Linux.

  • Un certificado de Seguridad de la capa de transporte (TLS) para que el servidor Linux proteja las conexiones de los dispositivos al servidor de puerta de enlace de Tunnel.

  • Dispositivos que ejecuten Android o iOS/iPad.

Después de configurar los requisitos previos, se recomienda ejecutar la herramienta de preparación para ayudar a validar que el entorno está bien configurado para una instalación correcta.

En las secciones siguientes se detallan los requisitos previos para Microsoft Tunnel y se proporcionan instrucciones sobre el uso de la herramienta de preparación.

Nota:

El túnel y el acceso seguro global (GSA) no se pueden usar simultáneamente en el mismo dispositivo.

Servidor Linux

Configure una máquina virtual basada en Linux o un servidor físico en el que instalar la puerta de enlace de Microsoft Tunnel.

Nota:

Solo se admitirán los sistemas operativos y las versiones de contenedor que aparezcan en la tabla siguiente. No se admitirán las versiones que no aparezcan en la lista. Solo después de realizar pruebas y de verificar la compatibilidad, se agregarán versiones más recientes a esta lista. Mantenga el sistema operativo actualizado también con las actualizaciones de seguridad.

  • Distribuciones de Linux compatibles : en la tabla siguiente se especifican las versiones de Linux que se admiten para el servidor de Tunnel y el contenedor que requieren:

    Versión de distribución Requisitos del contenedor Consideraciones
    CentOS 7.4+ Docker CE El soporte técnico finaliza en junio de 2024. No se admite CentOS 8+
    Red Hat (RHEL) 7.4 y versiones posteriores Docker CE El soporte técnico finaliza en junio de 2024
    Red Hat (RHEL) 8.6 El soporte técnico finaliza en junio de 2024 Podman 4.0 (valor predeterminado)
    Podman 3.0    		 Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.0. Si actualiza y cambia los contenedores de v3 a v4.0, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 8.7 Podman 4.2 (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 8.8 Podman 4.4.1 Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 8.9 Podman 4.4.1 Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 8.10 Podman 4.9.4-rhel (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 9.0 El soporte técnico finaliza en junio de 2024 Podman 4.4.1 (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.

    El soporte técnico finaliza en febrero de 2024.
    Red Hat (RHEL) 9.1 Podman 4.4.1 (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 9.2 Podman 4.4.1 (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 9.3 Podman 4.6.1. (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (valor predeterminado) Esta versión de RHEL no carga automáticamente el módulo ip_tables en el kernel de Linux. Cuando use esta versión, planee cargar manualmente el ip_tables antes de instalar Tunnel.

    Los contenedores creados por Podman v3 y versiones anteriores no se pueden usar con Podman v4.2 y versiones posteriores. Si actualiza y cambia los contenedores, planee crear nuevos contenedores y desinstalar y reinstalar Microsoft Tunnel.
    Ubuntu 20.04 Docker CE
    Ubuntu 22.04 Docker CE

    Importante

    En abril de 2023, Ubuntu finalizará la compatibilidad con Ubuntu 18.04. Con el fin de la compatibilidad con Ubuntu, Intune también finalizará la compatibilidad con Ubuntu 18.04 para su uso con Microsoft Tunnel. Para más información, vea https://wiki.ubuntu.com/Releases.

  • Tamaño del servidor Linux: use las siguientes instrucciones para satisfacer el uso esperado:

    N.º de dispositivos N.º de CPU GB de memoria N.º de servidores N.º de sitios Espacio en disco (GB)
    1,000 4 4 1 1 30
    2,000 4 4 1 1 30
    5,000 8 8 2 1 30
    10,000 8 8 3 1 30
    20,000 8 8 4 1 30
    40,000 8 8 8 1 30

    La compatibilidad escala linealmente. Mientras que cada instancia de Microsoft Tunnel admite hasta 64 000 conexiones simultáneas, los dispositivos individuales pueden abrir varias conexiones.

  • CPU: procesador AMD/Intel de 64 bits.

  • Instalación de Docker CE o Podman: en función de la versión de Linux que use para el servidor tunnel, instale una de las siguientes opciones en el servidor:

    • Docker versión 19.03 CE o posterior.
    • Podman, versión 3.0 o 4.0, según la versión de RHEL.

    Microsoft Tunnel requiere Docker o Podman en el servidor Linux para proporcionar soporte a los contenedores. Los contenedores proporcionan un entorno de ejecución coherente, seguimiento de mantenimiento, corrección proactiva y una experiencia de actualización limpia.

    Para obtener información sobre la instalación y la configuración de Docker o Podman, consulte:

    • Instale Docker Engine en CentOS o Red Hat Enterprise Linux 7.

      Nota:

      El vínculo anterior lo dirigirá a las instrucciones de instalación y descarga de CentOS. Use las mismas instrucciones para RHEL 7.4 La versión instalada en RHEL 7.4 de forma predeterminada es demasiado antigua para admitir la puerta de enlace de Microsoft Tunnel.

    • Instale Docker Engine en Ubuntu.

    • Instale Podman en Red Hat Enterprise Linux 8.4 y versiones posteriores (desplácese hacia abajo hasta RHEL8).

      Estas versiones de RHEL no admiten Docker. En su lugar, estas versiones usan Podman y Podman forma parte de un módulo denominado "container-tools". En este contexto, un módulo es un conjunto de paquetes RPM que representan un componente y normalmente se instalan juntos. Un módulo típico contiene paquetes con una aplicación, paquetes con bibliotecas de dependencias específicas de la aplicación, paquetes con documentación para la aplicación y paquetes con utilidades auxiliares. Para obtener más información, consulte Introducción a los módulos en la documentación de Red Hat.

      Nota:

      Rootless Podman: Microsoft Tunnel admite el uso de un contenedor podman sin raíz.

      El uso de Podman sin raíz requiere requisitos previos adicionales para los detallados en este artículo y el uso de una línea de comandos modificada al iniciar el script de instalación de Tunnel. Para obtener información sobre los requisitos previos adicionales y la línea de comandos de instalación, consulte Uso de un contenedor podman sin raíz en el artículo Configurar Microsoft Tunnel para Intune.

  • Certificado de seguridad de la capa de transporte (TLS): el servidor Linux requiere un certificado TLS de confianza para proteger la conexión entre los dispositivos y el servidor de puerta de enlace de Tunnel. Durante la instalación de tunnel gateway, agregue al servidor el certificado TLS y la cadena de certificados de confianza completa.

    • El nombre alternativo del firmante (SAN) del certificado TLS que se usa para proteger el punto de conexión de la puerta de enlace de Tunnel debe coincidir con la dirección IP o el FQDN del servidor de puerta de enlace de Tunnel.

    • El certificado TLS no puede tener una fecha de expiración superior a dos años. Si la fecha es superior a dos años, no se acepta en dispositivos iOS.

    • La compatibilidad con caracteres comodín es limitada. Por ejemplo, se admite *.contoso.com , pero no se admite cont*.com .

    • Durante la instalación del servidor de puerta de enlace de Tunnel, debe copiar toda la cadena de certificados de confianza en el servidor Linux. El script de instalación proporciona la ubicación donde debe copiar los archivos de certificado y le pide que lo haga.

    • Si usa un certificado TLS que no es de confianza pública, debe insertar toda la cadena de confianza en los dispositivos mediante un perfil de certificado de confianza Intune.

    • El certificado TLS puede estar en formato PEM o pfx.

    • Para admitir la comprobación de estado de revocación de certificados TLS , asegúrese de que el servidor puede acceder a la dirección del protocolo de estado de certificado en línea (OCSP) o de la lista de revocación de certificados (CRL) definida por el certificado TLS.

    • Configure el certificado de clientes de Tunnel con una clave de 2048 bits o mayor. Se recomiendan claves más grandes para ayudar a la implementación a mantenerse en compatibilidad con los requisitos SSL/TLS futuros y en constante evolución de varias soluciones de biblioteca SSL/TLS.

      Sugerencia

      Revise periódicamente los requisitos de la biblioteca SSL/TLS elegida para asegurarse de que la infraestructura y los certificados siguen siendo compatibles y en cumplimiento con los cambios recientes de esa biblioteca, y vuelva a emitir certificados de cliente de Tunnel cuando sea necesario para mantenerse al día con los requisitos en constante evolución de las soluciones.

  • Versión de TLS: de manera predeterminada, las conexiones entre los servidores y clientes de Microsoft Tunnel usan TLS 1.3. Cuando TLS 1.3 no está disponible, la conexión puede revertirse para usar TLS 1.2.

Red puente predeterminada

Tanto Podman como los contenedores Docker usan una red puente para reenviar el tráfico a través del host de Linux. Cuando la red de puente de contenedores entra en conflicto con una red corporativa, Tunnel Gateway no puede enrutar correctamente el tráfico a esa red corporativa.

Las redes puente predeterminadas son:

  • Docker: 172.17.0.0/16
  • Podman: 10.88.0.0/16

Para evitar conflictos, puede volver a configurar tanto Podman como Docker de forma que usen una red puente que usted especifique.

Importante

El servidor de Puerta de enlace de Tunnel debe instalarse para poder cambiar la configuración de la red puente.

Cambio de la red puente predeterminada usada por Docker

Docker usa el archivo /etc/docker/daemon.json para configurar una nueva dirección IP de puente predeterminada. En el archivo, la dirección IP del puente debe especificarse en notación CIDR (enrutamiento entre dominios sin clases), una forma compacta de representar una dirección IP junto con su máscara de subred asociada y el prefijo de enrutamiento.

Importante

La dirección IP que se usa en los pasos siguientes es un ejemplo. Asegúrese de que la dirección IP que usa no entra en conflicto con la red corporativa.

  1. Use el siguiente comando para detener el contenedor de puerta de enlace de MS Tunnel: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. A continuación, ejecute el siguiente comando para quitar el dispositivo de puente de Docker existente: sudo ip link del docker0

  3. Si el archivo /etc/docker/daemon.json está presente en el servidor, use un editor de archivos como vi o nano para modificar el archivo. Ejecute el editor de archivos con permisos raíz o sudo:

    • Cuando la entrada "bip": está presente con una dirección IP, modifíquela agregando una nueva dirección IP en la notación CIDR.
    • Cuando la entrada "bip": no está presente, debe agregar el valor "bip": y la nueva dirección IP en la notación CIDR.

    En el ejemplo siguiente se muestra la estructura de un archivo daemon.json con un "bip" actualizado: entrada que usa una dirección IP modificada de "192.168.128.1/24".

    Ejemplo de daemon.json:

    {
"bip": "192.168.128.1/24"
}

  4. Si el archivo /etc/docker/daemon.json no está presente en el servidor, ejecute un comando similar al siguiente ejemplo para crear el archivo y definir la dirección IP del puente que desea usar.

    Ejemplo: sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.json

  5. Use el siguiente comando para iniciar el contenedor de puerta de enlace de MS Tunnel: sudo mst-cli agent start ; sudo mst-cli server start

Para obtener más información, consulte Usar redes puente en la documentación de Docker.

Cambio de la red puente predeterminada usada por Podman

Podman usa el archivo /etc/cni/net.d como 87-podman-bridge.conflist para configurar una nueva dirección IP de puente predeterminada.

  1. Use el siguiente comando para detener el contenedor de puerta de enlace de MS Tunnel: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. A continuación, ejecute el siguiente comando para quitar el dispositivo de puente Podman existente: sudo ip link del cni-podman0

  3. Con permisos raíz y un editor de archivos como vi o nano, modifique /etc/cni/net.d como 87-podman-bridge.conflist para actualizar los valores predeterminados de "subnet:" y "gateway:" reemplazando los valores predeterminados de Podman por las direcciones de puerta de enlace y subred deseadas. La dirección subnet debe especificarse en notación CIDR.

    Los valores predeterminados de Podman son:

    • subred: 10.88.0.0/16
    • puerta de enlace: 10.88.0.1

  4. Use el siguiente comando para reiniciar los contenedores de puerta de enlace de MS Tunnel: sudo mst-cli agent start ; sudo mst-cli server start

Para obtener más información, consulte Configurar redes de contenedor con Podman en la documentación de Red Hat.

Auditoría del sistema Linux

La auditoría del sistema Linux puede ayudar a identificar información relevante para la seguridad o infracciones de seguridad en un servidor Linux que hospeda Microsoft Tunnel. La auditoría del sistema Linux se recomienda para Microsoft Tunnel, pero no es necesaria. Para usar la auditoría del sistema, un servidor Linux debe tener instalado el paquete auditado en /etc/audit/auditd.conf.

Los detalles sobre cómo implementar la auditoría dependen de la plataforma Linux que use:

  • Red Hat: las versiones de Red Had Enterprise Linux 7 y versiones posteriores instalan el paquete auditado de forma predeterminada. Sin embargo, si el paquete no está instalado, puede usar la siguiente línea de comandos en el servidor Linux para instalarlo: sudo dnf install audit audispd-plugins

    Normalmente, el paquete auditado está disponible en el repositorio predeterminado de cada versión de REHL.

    Para obtener más información sobre el uso de la auditoría del sistema en RHEL, consulte Configuración de la auditoría del sistema Linux con auditada en el blog de Red Hat.

  • Ubuntu: para usar la auditoría del sistema con Ubuntu, debe instalar manualmente el paquete auditado . Para ello, use la siguiente línea de comandos en el servidor Linux: sudo apt install auditd audispd-plugins

    Normalmente, el paquete auditado está disponible en el repositorio predeterminado de cada versión de Ubuntu.

    Para obtener más información sobre el uso de la auditoría del sistema en Ubuntu, consulte Configuración e instalación de auditados en Ubuntu, un artículo que está disponible en el sitio web de dev.to que se publicó originalmente en kubefront.com.

Red

  • Habilitar el reenvío de paquetes para IPv4: cada servidor Linux que hospeda el software del servidor de Tunnel debe tener habilitado el reenvío de IP para IPv4. Para comprobar el estado del reenvío de IP, en el servidor ejecute uno de los siguientes comandos genéricos como root o sudo. Ambos comandos devuelven un valor de 0 para deshabilitado y un valor de 1 para habilitado:

    • sysctl net.ipv4.ip_forward
    • cat /proc/sys/net/ipv4/ip_forward

    Si no está habilitado, puede habilitar temporalmente el reenvío de IP ejecutando uno de los siguientes comandos genéricos como root o sudo en el servidor. Estos comandos pueden cambiar la configuración del reenvío de IP hasta que se reinicie el servidor. Después de un reinicio, el servidor devuelve el comportamiento del reenvío de IP a su estado anterior. Para ambos comandos, use un valor de 1 para habilitar el reenvío. Un valor de 0 deshabilita el reenvío. En los ejemplos de comandos siguientes, se usa un valor de 1 para habilitar el reenvío:

    • sysctl -w net.ipv4.ip_forward=1
    • echo 1 > /proc/sys/net/ipv4/ip_forward

    Para convertir el reenvío de IP en permanente, en cada servidor Linux, edite el archivo /etc/sysctl.conf y quite el hashtag inicial (#) de #net.ipv4.ip_forward=1 para habilitar el reenvío de paquetes. Después de la edición, la entrada debe aparecer como sigue:

    # Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

    Para que este cambio suba efecto, debe reiniciar el servidor o ejecutar sysctl -p.

    Si la entrada esperada no está presente en el archivo sysctl.conf, consulte la documentación de la distribución que usa para saber cómo habilitar el reenvío de IP. Normalmente, puede editar sysctl.conf para agregar la línea que falta al final del archivo para habilitar permanentemente el reenvío de IP.

  • Configurar varias NIC por servidor(opcional): se recomienda usar dos controladores de interfaz de red (NIC) por servidor Linux para mejorar el rendimiento, aunque el uso de dos es opcional.

    • NIC 1: esta NIC controla el tráfico procedente de los dispositivos administrados y debe estar en una red pública con la dirección IP pública.  Esta dirección IP es la dirección que se configura en la configuración del sitio. La dirección puede representar un solo servidor o un equilibrador de carga.

    • NIC 2: esta NIC controla el tráfico a los recursos locales y debe estar en la red interna privada sin segmentación de red.

  • Asegurarse de que las máquinas virtuales Linux basadas en la nube pueden acceder a la red local: si ejecuta Linux como una máquina virtual en una nube, asegúrese de que el servidor puede acceder a la red local. Por ejemplo, si la máquina virtual se ejecuta en Azure, puede usar Azure ExpressRoute o algo similar para proporcionar acceso. ExpressRoute no es necesario cuando ejecuta el servidor en una máquina virtual local.

  • Equilibradores de carga(opcional): si decide agregar un equilibrador de carga, consulte la documentación de los proveedores para obtener detalles de configuración. Tenga en cuenta el tráfico de red y los puertos de firewall específicos de Intune y de Microsoft Tunnel.

    El servidor tunnel responde a las solicitudes GET con una página estática. Los equilibradores de carga usan la respuesta como sondeo como una manera de comprobar la vida del servidor tunnel. La respuesta es estática y no contiene información confidencial.

  • Compatibilidad con VPN por aplicación y dominio de nivel superior : Microsoft Tunnel no admite el uso de VPN por aplicación con el uso interno de dominios locales de nivel superior.

Firewall

De forma predeterminada, Microsoft Tunnel y el servidor usan los puertos siguientes:

Puertos de entrada:

  • TCP 443: necesario para Microsoft Tunnel.
  • UDP 443: necesario para Microsoft Tunnel.
  • TCP 22: opcional. Se usa para SSH/SCP en el servidor Linux.

Puertos de salida:

  • TCP 443: necesario para acceder a los servicios de Intune. Requerido por Docker o Podman para extraer imágenes.

Al crear una configuración de servidor para el túnel, puede especificar un puerto diferente del valor predeterminado de 443. Si especifica otro puerto, configure los firewalls para que admitan la configuración.

Más requisitos:

Para acceder al servicio de token de seguridad y a Azure Storage para los registros, proporcione acceso a los siguientes FQDN:

  • Servicio de token de seguridad: *.sts.windows.net
  • Almacenamiento de Azure para registros de túneles: *.blob.core.windows.net
  • Otras direcciones URL de punto de conexión de almacenamiento: *.blob.storage.azure.net
  • Microsoft Intune:*.manage.microsoft.com
  • Autenticación de Microsoft: login.microsoftonline.com
  • Microsoft Graph: graph.microsoft.com
  • Configure las reglas de firewall para admitir las configuraciones detalladas en configuración de reglas de firewall de cliente de Registro de artefactos Microsoft (MAR).

Proxy

Puede usar un servidor proxy con Microsoft Tunnel.

Nota:

Las configuraciones de servidor proxy no se admiten con versiones de Android anteriores a la versión 10. Para obtener más información, consulte VpnService.Builder en la documentación para desarrolladores de Android.

Nota:

Asegúrese de que las aplicaciones lob de Android admiten proxy directo o configuración automática de proxy (PAC) tanto para MDM como para MAM.

Nota:

Problema conocido: los usuarios que intentan iniciar sesión en Edge con sus cuentas personales o corporativas pueden tener problemas cuando se configura una configuración automática de proxy (PAC). En este escenario, es posible que se produzca un error en el proceso de inicio de sesión, lo que impide que el usuario acceda a los recursos internos.

Soluciones alternativas: Para resolver este problema, Microsoft Tunnel ofrece la tunelización dividida como una opción. La tunelización dividida permite a los usuarios incluir solo las rutas que requieren un proxy, al tiempo que se excluyen los servidores de inicio de sesión y las rutas de autenticación del enrutamiento a través del túnel. Esta solución alternativa garantiza que el proceso de inicio de sesión no se vea afectado por la configuración de PAC, lo que permite al usuario acceder a los recursos internos y navegar por Internet.

El proxy directo también es una opción sin tunelización dividida para que el inicio de sesión funcione en Edge mediante cuentas corporativas. Esto implica configurar Microsoft Tunnel para usar un proxy directo en lugar de una dirección URL de PAC.

Si no se requiere ningún inicio de sesión de usuario en Edge, pac es compatible con la exploración normal y el acceso a los recursos internos.

Las consideraciones siguientes le ayudarán a configurar correctamente el servidor Linux y su entorno:

Configurar un proxy saliente para Docker

  • Si usa un proxy interno, es posible que necesite configurar el host de Linux de modo que use el servidor proxy mediante variables de entorno. Para usar las variables, edite el archivo /etc/environment en el servidor Linux y agregue las líneas siguientes:

    http_proxy=[address]
    https_proxy=[address]

  • No se admiten los servidores proxy autenticados.

  • El proxy no puede realizar la interrupción y la inspección porque el servidor Linux usa la autenticación mutua TLS al conectarse a Intune.

  • Configure Docker para que use el proxy para extraer imágenes. Para ello, edite el archivo /etc/systemd/system/docker.service.d/http-proxy.conf en el servidor Linux y agregue las siguientes líneas:

    [Service]
Environment="HTTP_PROXY=http://your.proxy:8080/"
Environment="HTTPS_PROXY=https://your.proxy:8080/"
Environment="NO_PROXY=127.0.0.1,localhost"

    Nota:

    Microsoft Tunnel no admite Microsoft Entra proxy de aplicación ni soluciones de proxy similares.

Configurar un proxy saliente para Podman

Los detalles siguientes pueden ayudarle a configurar un proxy interno cuando se usa Podman:

  • No se admiten los servidores proxy autenticados.

  • El proxy no puede realizar la interrupción y la inspección porque el servidor Linux usa la autenticación mutua TLS al conectarse a Intune.

  • Podman lee la información de proxy HTTP almacenada en /etc/profile.d/http_proxy.sh. Si este archivo no existe en el servidor, creelo. Edite http_proxy.sh para añadir las dos líneas siguientes. En las líneas siguientes, 10.10.10.1:3128 es una entrada dirección:puerto de ejemplo. Al añadir estas líneas, reemplace 10.10.10.1:3128 por los valores de la dirección IP:puerto del proxy:

    export HTTP_PROXY=http://10.10.10.1:3128
    export HTTPS_PROXY=http://10.10.10.1:3128

    Si tiene acceso al portal de clientes de Red Hat, puede ver el artículo de knowledge base asociado a esta solución. Consulte Configuración de variables de proxy HTTP para Podman en el portal de clientes de Red Hat.

  • Al agregar esas dos líneas a http_proxy.sh antes de instalar Microsoft Tunnel Gateway mediante la ejecución de mstunnel-setup, el script configura automáticamente las variables de entorno del proxy de puerta de enlace de Tunnel en /etc/mstunnel/env.sh.

    Para configurar un proxy una vez completada la configuración de puerta de enlace de Microsoft Tunnel, realice las siguientes acciones:

    1. Modifique o cree el archivo /etc/profile.d/http_proxy.sh y añada las dos líneas del punto de viñeta anterior.

    2. Edite /etc/mstunnel/env.sh y añada las dos líneas siguientes al final del archivo. Al igual que las líneas anteriores, reemplace el valor address:port de ejemplo de 10.10.10.1:3128 por los valores de la dirección IP del proxy :port:

      HTTP_PROXY=http://10.10.10.1:3128
      HTTPS_PROXY=http://10.10.10.1:3128

    3. Reinicie el servidor de puerta de enlace de Tunnel: ejecutemst-cli server restart

    Tenga en cuenta que RHEL usa SELinux. Dado que un proxy que no se ejecuta en un puerto SELinux para http_port_t puede requerir una configuración adicional, compruebe el uso de puertos administrados de SELinux para http. Para ver las configuraciones, ejecute el siguiente comando: sudo semanage port -l | grep "http_port_t"

    Ejemplo de los resultados del comando de comprobación de puerto. En este ejemplo, el proxy usa 3128 y no aparece:

    Captura de pantalla que muestra los resultados de la comprobación del puerto.

    • Si el proxy se ejecuta en uno de los puertos SELinux para http_port_t, puede continuar con el proceso de instalación de la puerta de enlace de Tunnel.

    • Si el proxy no se ejecuta en un puerto SELinux para http_port_t como en el ejemplo anterior, debe realizar configuraciones adicionales.

      Si el puerto proxy no aparece parahttp_port_t, compruebe si otro servicio usa el puerto proxy. Use el comando semanage para comprobar primero el puerto que usa el proxy y, después, si es necesario, para cambiarlo. Para comprobar el puerto que usa el proxy, ejecute: sudo semanage port -l | grep "your proxy port"

      Ejemplo de los resultados de la comprobación de un servicio que puede usar el puerto:

      Captura de pantalla que muestra los resultados de la comprobación del servicio.

      • En el ejemplo, el puerto que esperamos (3128) lo usa squid, que resulta ser un servicio proxy de OSS. Las directivas de SELinux de proxy de Squid forman parte de muchas distribuciones comunes. Dado que squid usa el puerto 3128 (nuestro puerto de ejemplo), debemos modificar los puertos http_port_t y añadir el puerto 3128 para que se permita a través de SELinux para el proxy usado por Tunnel. Para modificar el uso de puertos, ejecute el siguiente comando: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

        Ejemplo del comando para modificar el puerto:

        Captura de pantalla que muestra un ejemplo del comando de modificación de puertos.

        Después de ejecutar el comando para cambiar el puerto, ejecute el siguiente comando para comprobar si otro servicio usa el puerto: sudo semanage port -l | grep "your proxy port"

        Ejemplo del comando para comprobar el puerto después de modificarlo:

        Captura de pantalla de comprobación del puerto después de la modificación.

        En este ejemplo, el puerto 3128 ahora está asociado con http_port-t y squid_port_t. Se espera ese resultado. Si el puerto proxy no aparece al ejecutar el comandosudo semanage port -l | grep "su_puerto_proxy", ejecute el comando para modificar el puerto de nuevo, pero cambie -m en el comando semanage por -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Configuración de Podman para usar el proxy para descargar actualizaciones de imágenes

Puede configurar Podman para que use el proxy para descargar (extraer) imágenes actualizadas para Podman:

  1. En el servidor de túnel, use un símbolo del sistema para ejecutar el siguiente comando para abrir un editor para el archivo de invalidación del servicio Microsoft Tunnel:

    systemctl edit --force mstunnel_monitor

  2. Agregue las tres líneas siguientes al archivo. Reemplace cada instancia de [address] por el DN o la dirección del proxy y, a continuación, guarde el archivo:

    [Service]
Environment="http_proxy=[address]"
Environment="https_proxy=[address]"

  3. A continuación, ejecute lo siguiente en el símbolo del sistema:

    systemctl restart mstunnel_monitor

  4. Por último, ejecute lo siguiente en el símbolo del sistema para confirmar que la configuración se ha realizado correctamente:

    systemctl show mstunnel_monitor | grep http_proxy

    Si la configuración se realiza correctamente, los resultados son similares a la siguiente información:

    Environment="http_proxy=address:port"
Environment="https_proxy=address:port"

Actualizar el servidor proxy en uso por el servidor de túnel

Para cambiar la configuración del servidor proxy que usa el host Linux del servidor de túnel, use el siguiente procedimiento:

  1. En el servidor de túnel, edite /etc/mstunnel/env.sh y especifique el nuevo servidor proxy.

  2. Ejecute mst-cli install.

    Este comando vuelve a generar los contenedores con los detalles del nuevo servidor proxy. Durante este proceso, se le pedirá que compruebe el contenido de /etc/mstunnel/env.sh y que asegúrese de que el certificado está instalado. El certificado debería estar ya presente en la configuración anterior del servidor proxy.

    Para confirmar ambos y completar la configuración, escriba sí.

Plataformas

Para que los dispositivos sean compatibles con Microsoft Tunnel, se deben inscribir en Intune. Solo se admiten las siguientes plataformas de dispositivos:

  • iOS/iPadOS

  • Android Enterprise:

    • Totalmente administrado
    • Perfil de trabajo de propiedad corporativa
    • Perfil de trabajo de propiedad personal

    Nota:

    Los dispositivos Android Enterprise dedicados no son compatibles con Microsoft Tunnel.

Todas las plataformas admiten la siguiente funcionalidad:

  • Microsoft Entra autenticación al túnel mediante el nombre de usuario y la contraseña.
  • Autenticación de Servicios de federación de Active Directory (AD FS) a Tunnel mediante el nombre de usuario y la contraseña.
  • Compatibilidad por aplicación.
  • Túnel de dispositivo completo manual a través de una aplicación de Tunnel, donde el usuario inicia la VPN y selecciona Conectar.
  • Tunelización dividida. Aun así, en iOS, las reglas de tunelización dividida se omiten cuando el perfil de VPN usa VPN por aplicación.

La compatibilidad con un proxy está limitada a las plataformas siguientes:

  • Android 10 y versiones posteriores
  • iOS/iPadOS

Permisos

Para administrar Microsoft Tunnel, los usuarios deben tener los permisos que se incluyen en el grupo de permisos de la puerta de enlace de Microsoft Tunnel en Intune. De forma predeterminada, los administradores de Intune y Microsoft Entra tienen estos permisos. También se pueden agregar a los roles personalizados que se hayan creado para el inquilino de Intune.

Al configurar un rol, en la página Permisos, expanda Puerta de enlace de Microsoft Tunnel y, después, seleccione los permisos que quiere conceder.

Captura de pantalla de los permisos de puerta de enlace de túnel en el centro de administración de Microsoft Intune.

El grupo de permisos de la puerta de enlace de Microsoft Tunnel concede los permisos siguientes:

  • Crear: permite configurar servidores y sitiosde la puerta de enlace de Microsoft Tunnel. Las configuraciones de servidor incluyen valores para los intervalos de direcciones IP, los servidores DNS, los puertos y las reglas de tunelización dividida. Los sitios son agrupaciones lógicas de varios servidores que admiten Microsoft Tunnel.

  • Actualizar (modificar): permite actualizar configuraciones de servidor y sitios de puerta de enlace de Microsoft Tunnel. Las configuraciones de servidor incluyen valores para los intervalos de direcciones IP, los servidores DNS, los puertos y las reglas de tunelización dividida. Los sitios son agrupaciones lógicas de varios servidores que admiten Microsoft Tunnel.

  • Eliminar: permite eliminar configuraciones de servidor y sitios de puerta de enlace de Microsoft Tunnel. Las configuraciones de servidor incluyen valores para los intervalos de direcciones IP, los servidores DNS, los puertos y las reglas de tunelización dividida. Los sitios son agrupaciones lógicas de varios servidores que admiten Microsoft Tunnel.

  • Leer: permite visualizar configuraciones de servidor y sitios de puerta de enlace de Microsoft Tunnel. Las configuraciones de servidor incluyen valores para los intervalos de direcciones IP, los servidores DNS, los puertos y las reglas de tunelización dividida. Los sitios son agrupaciones lógicas de varios servidores que admiten Microsoft Tunnel.

Ejecución de la herramienta de preparación

Antes de iniciar la instalación de un servidor, se recomienda que descargue y ejecute la versión más reciente de la herramienta mst-readiness. La herramienta es un script que se ejecuta en el servidor Linux y realiza las acciones siguientes:

  • Valida que la cuenta de Microsoft Entra que usa para instalar Microsoft Tunnel tiene los roles necesarios para completar la inscripción.

  • Confirma que la configuración de red permite a Microsoft Tunnel acceder a los puntos de conexión necesarios de Microsoft.

  • Compruebe la presencia del módulo ip_tables en el servidor Linux. Esta comprobación se agregó al script el 11 de febrero de 2022, cuando se añadió la compatibilidad con RHEL 8.5. RHEL 8.5 posterior no carga el módulo ip_tables de forma predeterminada. Si faltan después de instalar el servidor Linux, debe cargar manualmente el módulo ip_tables.

Importante

La herramienta de preparación no valida los puertos de entrada, lo que es un error de configuración habitual. Una vez que se ejecute la herramienta de preparación, revise los requisitos previos del firewall y valide manualmente el tráfico entrante de paso por el firewall.

La herramienta mst-readiness tiene una dependencia en jq, un procesador JSON de línea de comandos. Antes de ejecutar la herramienta de preparación, asegúrese de que jq esté instalado. Para obtener información sobre cómo obtener e instalar jq, consulte la documentación de la versión de Linux que use.

Para usar la herramienta de preparación:

  1. Obtenga la versión más reciente de la herramienta de preparación mediante uno de los métodos siguientes:

    • Descargue la herramienta directamente mediante un explorador web. Vaya a https://aka.ms/microsofttunnelready para descargar un archivo denominado mst-readiness.

    • Inicie sesión en Microsoft Intune centro> de administración >de inquilinosPuerta de enlace de Microsoft Tunnel, seleccione la pestaña Servidores, seleccione Crear para abrir el panel Crear un servidor y, a continuación, seleccione Descargar herramienta de preparación.

    • Use un comando de Linux para obtener la herramienta de preparación directamente. Por ejemplo, puede usar wget o curl para abrir el vínculo https://aka.ms/microsofttunnelready.

      Por ejemplo, para usar wget y registrar los detalles en mst-readiness durante la descarga, ejecute wget --output-document=mst-readiness https://aka.ms/microsofttunnelready.

    El script se puede ejecutar desde cualquier servidor Linux que se encuentra en la misma red que el servidor que tiene previsto instalar, lo que permite a los administradores de red usar el script para solucionar problemas de red de forma independiente.

  2. Para validar la configuración de Red y Linux, ejecute el script con los siguientes comandos. Estos comandos establecen los permisos de ejecución para el script, validan que Tunnel pueda conectarse a los puntos de conexión correctos y, a continuación, compruebe la presencia de utilidades que tunnel usa:

    • sudo ./mst-readiness

    • sudo ./mst-readiness network - Este comando ejecuta las siguientes acciones y, a continuación, notifica el éxito o el error de ambos:

      • Intenta conectarse a los puntos de conexión de Microsoft que usará el túnel.
      • Comprueba que los puertos necesarios están abiertos en el firewall.

    • sudo ./mst-readiness utils - Este comando valida que las utilidades que usa Tunnel como Docker o Podman y ip_tables están disponibles.

  3. Para validar que la cuenta que usará para instalar Microsoft Tunnel tiene los roles y permisos necesarios para completar la inscripción, ejecute el script con la siguiente línea de comandos: ./mst-readiness account

    El script le pide que use una máquina diferente con un explorador web, que se usa para autenticarse para Microsoft Entra ID y para Intune. La herramienta notifica si se ha realizado correctamente o un error.

Para obtener más información sobre esta herramienta, consulte Referencia de mst-cli en el artículo de referencia de Microsoft Tunnel.

Cargar manualmente ip_tables

Aunque la mayoría de las distribuciones de Linux cargan automáticamente el módulo ip_tables, es posible que algunas distribuciones no lo hagan. Por ejemplo, RHEL 8.5 no carga el ip_tables de forma predeterminada.

Para comprobar la presencia de este módulo, ejecute la versión más reciente de la herramienta mst-readiness en el servidor Linux. La comprobación de ip_tables se agregó al script de las herramientas de preparación el 11 de febrero de 2022.

Si el módulo no está presente, la herramienta se detiene en la comprobación del módulo ip_tables. En este escenario, puede ejecutar los siguientes comandos para cargar manualmente el módulo.

Cargar manualmente el módulo ip_tables

En el contexto de sudo, ejecute los siguientes comandos en el servidor Linux:

  1. Valide la presencia de ip_tables en el servidor: lsmod |grep ip_tables

  2. Si ip_tables no está presente, ejecute el siguiente para cargar el módulo en el kernel inmediatamente, sin reiniciarlo: /sbin/modprobe ip_tables

  3. Vuelva a ejecutar la validación para confirmar que las tablas están cargadas: lsmod |grep ip_tables

Importante

Al actualizar el servidor de Tunnel, es posible que un módulo de ip_tables cargado manualmente no persista. Esto puede requerir que vuelva a cargar el módulo una vez completada la actualización. Una vez completada la actualización del servidor, revise el servidor para comprobar si está el módulo ip_tables.

Si las tablas no están presentes, use los pasos anteriores para volver a cargar el módulo, con el paso adicional de reiniciar el servidor una vez cargado el módulo.

Configurar Linux para cargar ip_tables en el arranque

En el contexto de sudo, ejecute el siguiente comando en el servidor Linux para crear un archivo de configuración que cargue el ip_tables en el kernel durante el tiempo de arranque: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Carga manual del módulo de tun

Microsoft Tunnel requiere el módulo tun , pero algunas distribuciones de Linux no cargan el módulo tun de forma predeterminada.

Para validar el presente del módulo tun en el servidor, ejecute: lsmod |grep tun

  1. Si tun no está presente, ejecute lo siguiente para cargar el módulo en el kernel inmediatamente, sin reiniciar: /sbin/modprobe tun

  2. Vuelva a ejecutar la validación para confirmar que el módulo tun ya está cargado: lsmod |grep tun

Importante

Al actualizar el servidor tunnel, es posible que un módulo de tun cargado manualmente no persista. Esto puede requerir que vuelva a cargar el módulo una vez completada la actualización. Una vez completada la actualización del servidor, revise el servidor para comprobar la presencia del módulo de tun .

Si no está presente, use los pasos anteriores para volver a cargar el módulo, con el paso adicional para reiniciar el servidor después de cargar el módulo.

Configuración de Linux para cargar tun en el arranque

En el contexto de sudo, ejecute el siguiente comando en el servidor Linux para crear un archivo de configuración que cargue tun en el kernel durante el tiempo de arranque: echo tun > /etc/modules-load.d/mstunnel_tun.conf

Siguientes pasos

Configurar Microsoft Tunnel