Componentes necesarios para el acceso de usuarios externos
Última modificación del tema: 2012-10-17
La mayoría de los componentes perimetrales se implementan en una red perimetral (también denominada red perimetral o subred filtrada). Los siguientes componentes conforman la topología perimetral de una red perimetral. A menos que se indique lo contrario, los componentes forman parte de las tres arquitecturas de referencia y se encuentran en la red perimetral. Los componentes perimetrales engloban los siguientes:
Servidor(es) perimetral(es)
Proxy inverso
Equilibrio de carga para topologías perimetrales escaladas (equilibrio de carga de DNS o un equilibrador de carga de hardware)
Firewall
Director (en redes internas)
Servidor perimetral
El servidor perimetral controla el tráfico que atraviesa el firewall y la utilización por parte de los usuarios externos de la implementación interna. El servidor perimetral ejecuta los siguientes servicios:
Servicio perimetral de acceso El servicio perimetral de acceso proporciona un único punto de conexión de confianza para el tráfico SIP (protocolo de inicio de sesión) saliente y entrante.
Servicio perimetral de conferencia web El servicio perimetral de conferencia web permite a los usuarios externos unirse a reuniones hospedadas en la implementación interna del Microsoft Lync Server 2010.
Servicio perimetral A/V El servicio perimetral A/V hace que los usuarios externos puedan disfrutar de audio, vídeo, uso compartido de aplicaciones y transferencia de archivos. Los usuarios pueden agregar audio y vídeo a las reuniones con participantes externos y compartir audio y vídeo directamente con un usuario externo en sesiones punto a punto. De igual modo, este servicio permite el uso compartido de escritorio y la transferencia de archivos.
Los usuarios externos autorizados pueden tener acceso a los servidores perimetrales para conectarse a la implementación interna de Lync Server, si bien no podrán tener acceso a ningún otro elemento de la red a través de estos servidores.
Nota
Los servidores perimetrales se implementan para proporcionar conexiones a clientes de Lync y a otros servidores perimetrales (como, por ejemplo, en los escenarios de federación). Estos servidores no están diseñados para permitir conexiones desde otros tipos de servidores o clientes de extremos. El servidor de puerta de enlace XMPP puede implementarse para permitir conexiones con socios XMPP configurados. El servidor perimetral y la puerta de enlace XMPP solo admite conexiones de extremos procedentes de estos clientes y de estos tipos de federación
Proxy inverso
Un servidor proxy inverso es un componente de infraestructura necesario para la mayoría de los escenarios que se habilitan como parte de Microsoft Lync Server 2010. La mayoría de las implementaciones usan el proxy inverso instalado y configurado para su organización. Normalmente, son necesarias nuevas reglas de publicación aunque no suelen ser necesarios cambios en las reglas del servidor proxy existente. Los certificados nuevos o actualizados son los que suelen usarse para controlar las nuevas reglas de publicación. Entre los tipos de servidores proxy inversos se incluyen los siguientes:
Microsoft Internet and Acceleration Server (ISA) 2006 con Service Pack 1
Para el ejemplo que se muestra en Implementación de servidores perimetrales se usa una configuración básica de Microsoft Threat Management Gateway 2010. El proceso de configuración de la publicación de Lync Server 2010 en Microsoft Threat Management Gateway 2010 y en Microsoft Internet and Acceleration Server (ISA) 2006 con Service Pack 1 es muy similar. Para obtener más detalles, vea Configurar las reglas de publicación web para un solo grupo de servidores interno en la documentación relacionada con la Implementación.
Microsoft Threat Management Gateway (TMG) 2010.
Para obtener más detalles acerca de la configuración de Microsoft Threat Management Gateway (TMG) 2010 como servidor proxy inverso para su implementación de Lync Server 2010, vea Configurar las reglas de publicación web para un solo grupo de servidores interno en la documentación relacionada con la Implementación.
Servidores proxy inversos de terceros que admitan la configuración para publicar contenido HTTP y HTTPS interno.
Firewalls de terceros que admitan la posibilidad de publicar contenido HTTP y HTTPS interno.
También pueden usarse otros dispositivos como, por ejemplo, equilibradores de cargas de hardware y dispositivos de motor de contenido HTTP.
Para obtener información sobre la configuración de dispositivos de terceros, servidores y dispositivos, consulte la documentación del proveedor sobre configuración para la publicación.
.gif "important") Importante: |
|---|
| No se puede usar una combinación de Servidor perimetral y de un servidor proxy inverso como opción de configuración válida. Servidor perimetral debe permanecer como rol de un único propósito para la administración del protocolo de inicio, las conferencias web y las características de audio/vídeo (al igual que el resto de tipos de medios) de su implementación. |
El proxy inverso se requiere para:
Dejar que los usuarios se conecten a reuniones o conferencias de acceso telefónico usando direcciones URL sencillas
Dejar que los usuarios descarguen el contenido de las reuniones
Dejar que los usuarios externos expandan grupos de distribución
Dejar que los usuarios obtengan un certificado individual de usuario para la autenticación basada en certificados
Dejar que los usuarios remotos descarguen archivos del servidor de libreta de direcciones o envíen consultas al servicio de consulta web de la libreta de direcciones
Dejar que los usuarios remotos obtengan actualizaciones de software de dispositivo y de cliente
Para habilitar dispositivos móviles para detectar automáticamente servidores front-end que ofrecen servicios de movilidad
Para habilitar notificaciones de inserción para dispositivos móviles desde los servicios de notificación de inserción de Office 365 o Apple
Nota
Los usuarios externos no precisan de una conexión VPN a la organización para poder participar en las comunicaciones basadas en Lync Server. Los usuarios externos que se conecten a la red interna de la organización a través de una VPN omiten el proxy inverso.
Firewall
La topología perimetral se puede implementar con únicamente un firewall externo o con un firewall interno y otro externo. Las arquitecturas de referencia incluyen dos firewall. El uso de dos firewall es el método que se recomienda, en tanto garantiza el enrutamiento estricto desde un perímetro de red al otro, además de proteger la implementación interna detrás de dos niveles de firewall.
Director
En Lync Server 2010, un director es un rol de servidor independiente en Lync Server 2010 que no contiene cuentas de usuario o proporciona servicios de presencia o conferencia; en su lugar, actúa como servidor del próximo salto interno al que un servidor perimetral enruta el tráfico SIP dirigido a los servidores internos. El director autentica las solicitudes internas y las redirige al servidor o grupo de servidores principal del usuario.
Si la organización va a habilitar el acceso externo, se recomienda implementar un director. Al autenticar el tráfico SIP entrante procedente de usuarios remotos, el director libera a los servidores Standard Edition y servidores front-end de grupos de servidores front-end de Enterprise Edition de la sobrecarga de llevar a cabo la autenticación de usuarios remotos. También ayuda a aislar a estos servidores del tráfico malicioso, como los ataques de denegación de servicio (DoS). Si la red se inunda de tráfico externo no válido en un ataque de estas características, este tráfico termina en el director y los usuarios internos no verán perjudicado el rendimiento. Si desea más información sobre el uso de directores, consulte Director.
Equilibradores de carga de hardware
La topología perimetral consolidada escalada de Lync Server 2010 se optimiza con el equilibrio de carga de DNS que se aplica a las nuevas implementaciones que se federan principalmente con otras organizaciones por medio de Lync Server 2010. En caso de que se necesite una gran disponibilidad en cualquiera de los siguientes escenarios, se deberá usar un equilibrador de carga de hardware en grupos de servidores perimetrales:
Federación con organizaciones que ejecutan Office Communications Server 2007 R2 o Office Communications Server 2007
Mensajería unificada de Exchange para usuarios remotos
Conectividad con usuarios de mensajería instantánea pública
Para saber si su equilibrador de carga de hardware admite las características que necesita Lync Server 2010, consulte "Lync Server 2010 Load Balancer Partners" en inglés (Socios de equilibradores de carga" en https://go.microsoft.com/fwlink/?linkid=202452&clcid=0xC0A.
Consideraciones generales relacionadas con el equilibrador de cargas de hardware para un proxy inverso
La traducción de direcciones de red de destino (DNAT), que usa la dirección IP de destino entrante de la IP virtual (VIP) del equilibrador de cargas, se convierte a la dirección IP de destino del servidor. Es posible que el proveedor del equilibrador de cargas recomiende la traducción de direcciones de red de origen (SNAT). Preste la debida atención al tipo de NAT que va a usar y tenga en cuenta que la NAT es única para el equilibrador de cargas de hardware (HLB) y establece una relación entre la VIP del HLB y los servidores hospedados. No ocurre lo mismo que con la NAT administrada en el firewall del servidor perimetral.
Use la afinidad de origen (también conocida como afinidad TCP; consulte la documentación del proveedor). Todo el tráfico de una única sesión debe asociarse al mismo destino (es decir, el servidor). En caso de que existan varias sesiones de un único origen, las sesiones podrán asociarse a distintos servidores de destino mediante la afinidad de origen para proporcionar el estado de la sesión.
Salvo que otra especificación indique lo contrario (necesidades de rendimiento, definiciones de prueba, estándares o documentación del proveedor), el tiempo de espera de inactividad de TCP debe establecerse en 30 minutos (1800 segundos).
.gif "warning") Advertencia: |
|---|
| La combinación de equilibrio de carga de DNS en una interfaz y equilibrio de carga de hardware en otra no es factible, sino que uno u otro deberán usarse en ambas interfaces. |
Nota
Si usa un equilibrador de carga de hardware, el equilibrador de carga que se haya implementado para las conexiones con la red interna deberá configurarse de modo que solo equilibre la carga del tráfico al servicio perimetral de acceso y el servicio perimetral A/V. No puede equilibrar la carga del tráfico al servicio perimetral de conferencia web interno.
Nota
Lync Server 2010 no admite NAT de retorno de servidor directo.
Requisitos de equilibrador de carga de hardware para servidores perimetrales que ejecutan el servicio perimetral A/V
A continuación, se muestran los requisitos del equilibrador de carga de hardware para un servidor perimetral A/V:
Inhabilitar la aplicación del algoritmo de Nagle TCP para los puertos 443 internos y externos. La aplicación del algoritmo de Nagle es la combinación de varios paquetes pequeños en un único paquete más grande para obtener una transmisión más eficiente.
Inhabilitar la aplicación del algoritmo de Nagle TCP para el intervalo de puertos externos de 50.000 a 59.999.
No usar NAT en el firewall interno o externo.
La interfaz interna del servidor perimetral y la interfaz externa del servidor perimetral deben estar en redes diferentes, y debe inhabilitarse el enrutamiento entre ellas.
La interfaz interna del servidor perimetral A/V debe usar públicamente direcciones IP enrutables y ninguna NAT o traducción de puerto en ninguna de las direcciones IP externas del servidor perimetral.
Requisitos del equilibrador de carga de hardware para servicios web
A continuación se muestran los requisitos del equilibrador de carga de hardware para servicios web de grupo de directores y de servidores front-end:
Para las IP virtuales (VIP) de servicios web externos, configure la persistencia basada en cookies por puerto para los puertos 4443, 8080 en el equilibrador de carga de hardware. Para Lync Server 2010, la persistencia basada en cookies significa que se envían siempre varias conexiones de un único cliente a un servidor para mantener el estado de la sesión. Para configurar la persistencia basada en cookies, el equilibrador de carga debe descifrar y volver a cifrar el tráfico SSL. Por consiguiente, todos los certificados asignados al FQDN del servicio web externo deberán asignarse también a la VIP del puerto 4443 del equilibrador de carga de hardware.
Para VIPS de servicios web internos, configure la persistencia Source_addr (puerto interno 80, 443) en el equilibrador de carga de hardware. Para Lync Server 2010, la persistencia Source_addr significa que se envían siempre varias conexiones de una única dirección IP a un servidor para mantener el estado de la sesión.
Use un tiempo de espera de inactividad TCP de 1.800 segundos.
En el firewall entre el proxy inverso y el equilibrador de carga de hardware del grupo de servidores del próximo salto, cree una regla que permita el tráfico https: en el puerto 4443, del proxy inverso al equilibrador de carga de hardware. El equilibrador de carga de hardware debe configurarse de modo que escuche los puertos 80, 443 y 4443.